On Tuesday 21 March 2006 18:33, Patrick Klos wrote: > > If the Linux machine has just recently been booted, the transfer takes around > 8 or 9 milliseconds. If the Linux machine has been up for a while (but still > primarily idle), the transfer starts to take anywhere from 32 to 70 milli- > seconds. Both the Windows machine and the Linux machine are for all practical > purposes idle and dedicated to this test process. It seems the Linux TCP > stack is getting into a state where it decides to slow down the pace of the > transfer to the Windows machine?!?
The congestion window is cached. ip route flush To flush it > > When the transfer is fast, the time between frame sends is usually about > 8 to 40 microseconds (with some variation). > > When the transfer is slow, the time between frame sends starts off at a high > 130 microseconds, then tapers down to 1/2 and/or 1/4 of that in a pattern > that looks too consistant to be random. Here's the basic pattern: > > (time between packet sends in microseconds) > 130, 130, 130, 130, 130, 130, 130, 130, 68, 32, 32, 32, 32, 32 Looks like slow start to me. > [ it's this pattern I'm hoping someone recognizes! :o) ] > > After a group of packets are sent, the pattern starts again with a large > number then tapers down again and again until the entire transfer is done. Maybe you lost some packets. Or the ACK clock got out of sync. You can check the various statistics output by netstat -s -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
