My internet provider sometimes looses packets. Nothing much can be
done about that. However in recovering from the lost pakcets, I see
Linux do delayed acks about 500ms after recieving a retransmitted
packet. Those however are "in the loop", as the other side is in
slow-start again.
Suggestion: don't do delayed ack, if you have data past the segment
we're recieving now.
Let me try to reproduce here what I saw:
[transfer was already running]
0 r -> l 0:1000 (1000)
0 ( 0) l -> r ACK 1000
100 ( 100) r -> l 1000:2000 (1000)
100 ( 0) l -> r ACK 2000
200 ( 100) r -> l 2000:3000 (1000)
200 ( 0) l -> r ACK 3000
300 ( 100) r -> l 3000:4000 (1000)
300 ( 0) l -> r ACK 4000
400 ( 100) r -> l 10000:11000 (1000)
400 ( 0) l -> r ACK 4000
500 ( 100) r -> l 11000:12000 (1000)
500 ( 0) l -> r ACK 4000
600 ( 100) r -> l 12000:13000 (1000)
600 ( 0) l -> r ACK 4000
1200 ( 600) r -> l 4000:5000
1700 ( 500) l -> r ACK 5000 <-
2000 ( 300) r -> l 5000:6000 (1000)
2500 ( 500) l -> r ACK 6000 <-
...
(l is "local" (linux), r is remote. second column is relative time. )
The transfer resumed at 10k per second once the gap had been filled.
Does this throw off the remote "RTT" measurement? (-> No, RTT is only
measured when data comes back?)
I think there is something wrong somewhere in my ISPs network, as
losing 6 packets in a row seems odd to me. Anybody know what could
be going on?
I'm still running 2.0.33 for production work, but I doubt that this
stuff changed.
Regards,
Roger.
-- | Most people would die sooner than think.... | R.E.Wolff@BitWizard.nl | in fact, most do. -- Bertrand Russsell | phone: +31-15-2137555 We write Linux device drivers for any device you may have! fax: ..-2138217- 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/