Hello

I've noticed a bit different behaviour with regard to delayed acks on OBSD.

Some other systems (2 linux distros, win2k/xp) I tested, pretty much acted as I've always seen it - 1 ack per max. 2 segments, but no bigger delay than some arbitrary value (looking at rfc, no more than 500ms, but usually less), thus in reality - 1 ack every 2 segments assuming latency is low enough.

For my ridiculously asymmetric line - 24:1 (6144/256) - at single full download, that's roughly 2/3+ upload used for acks only, partially due to hefty adsl overhead (and after looking at pppoa rfc, 2 atm cells used for just 1 ack).

On OpenBSD though, the result was generally perfect 66% segments acked. Looking at tcpdump output, the acks on receiving side were sent precisely after receiving : 1,2,1,2,1,2... segments. The test was made on lan between two obsd 4.0 boxes (generic kernel), limiting the speed with one queue (and none as well) on sending host, as needed. Speed didn't seem to matter though - behaviour was the same with 256kbit as it was with 100mbit.

Assuming it's intended behaviour - what are the reasons for implementing it in this way ?

Reply via email to