Yes, a brain fart (maybe this saying has been worn out?-). My only excuse was that I had to catch a movie and was in a hurry. Just a note to everyone, haven't seen a more corny ending in a while than
[ BTW you have problems with your mail at helsinki.fi ] No, tcpdump shows that sender always has full window. Receiver always ACKs _previous_ packet. RTT=0.9sec, window is 2 packets or ~3K, bandwidt
For what it is worth, ping while under load looks (downloading linux kernel, as always) like this: root@bug:~# ping 192.168.55.100 PING 192.168.55.100 (192.168.55.100): 56 data bytes 64 bytes from 1
Yes, it looks that way and I got the acks mixed up. The application in question was ttcp. And your guess is quite close to truth. I should've known what was the cause since we've been hit with the ex
Assuming 84 bytes altogether, this is quite close to 19200 bps. I get about 90-100 ms for RTT. See, http://arstechnica.com/reviews/2q00/networking/networking-1.html
I think, it is possible. Only I have no idea, how to make this. 8) I see no problems in tcpdump, it looks perfect. No, it is impossible. Sender cannot do anything with receiver's window. Seems, the
The analysis is correct, I think. It is not hackish, it is rather buggish. 8) You cannot mangle truesize, eben with good intention. Try better to tune tcp_min_write_space(). I want to think it is tu
Yes, that was just to test the theory. To me it seems this would be trying to fix the symptom rather than the cause. There seems to be a certain assumption in place here that the default socket buffe
It is really OK. 65535 is very big sndbuf, when you talk to sane OSes (i.e. windows 8)). But we cannot talk to Linuxes 8), because they used to advertise non realistic windows. Also, the fact that t
used - As in past tense? Remember that truesize is not the whole story. The cloned skbs show up in wmem_alloc too which is why we got bitten by the burstiness. I see the heuristics are on the conserv
TCP calculates _maximal_ window possible with current mss and device. If the window converged to 8K, it cannot be larger for this connection. If it were >8K, it would prune. It is law of nature, rat
Yes, I understood although the truesize/len ratio might suggest that a bit larger window was possible. Maybe I forgot my own argument. See below. For that particular test case 8kB is enough I agree.
What value did you expect? Could you send me some tcpdumps showing window evolution? It is interesting. I tried to prove that it is never the case in real life. When power is large, mtu cannot be sm
Yes, a brain fart (maybe this saying has been worn out?-). My only excuse was that I had to catch a movie and was in a hurry. Just a note to everyone, haven't seen a more corny ending in a while than
Hello! [ BTW you have problems with your mail at helsinki.fi ] No, tcpdump shows that sender always has full window. Receiver always ACKs _previous_ packet. RTT=0.9sec, window is 2 packets or ~3K, ba
Hi! For what it is worth, ping while under load looks (downloading linux kernel, as always) like this: root@bug:~# ping 192.168.55.100 PING 192.168.55.100 (192.168.55.100): 56 data bytes 64 bytes fro
Yes, it looks that way and I got the acks mixed up. The application in question was ttcp. And your guess is quite close to truth. I should've known what was the cause since we've been hit with the ex
Assuming 84 bytes altogether, this is quite close to 19200 bps. I get about 90-100 ms for RTT. See, http://arstechnica.com/reviews/2q00/networking/networking-1.html
Hello! I think, it is possible. Only I have no idea, how to make this. 8) I see no problems in tcpdump, it looks perfect. No, it is impossible. Sender cannot do anything with receiver's window. Seems