On Fri, 2 Jun 2000 kuznet@ms2.inr.ac.ru wrote:
> I repeat, this change cannot affect behaviour visible on wire.
> It wakes up socket write rather than transmit.
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 in `Mission to
Mars' - von Daniken should be proud.
Regarding the correspondance on netdev - yes, I'm quite aware (now
but once was lost) that transmit is ack-driven but let's think about
the dump and the bursts. We get incoming acks in a steady flow - why
then (when approaching window limit) sender stops sending packets to the
wire until always a certain point? Burst was able to be so steep only
because our emulator had no flow control. It ate all the packets and
delayed each of them so that receiver saw a steady stream of 9600 bps -
which is why the incoming acks were a steady stream too. What's so
different about tcp_snd_test() and __tcp_data_snd_check() that this
happens? Of course, it might be all our fault so you need only to ignore
this for now. I'll report if we find something concrete that's
attributable to the TCP/IP stack.
There was another error in my mail too, 2*130 is indeed over 200 but that
was irrelevant. However the conclusion seemed correct, delayed acks timing
out. Could you explain me why the window of 3100 seems to allow 2 packets
in flight but sender always waits for the next ack? I must have missed
something but in our tests too, the sender never quite reaches the window
limit (but this was of course with a bigger window size).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:16 EST