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 ?