I noticed just now on 10.4.8 that the value for delayed Ack is "3"
which
surprises me. Previously I only noticed it could be "on" (1) or
"off" (0). This may have some bearing on why Mac OS X is ACKing so
lazily.
This is the comment from tcp_input.c (ppc darwin 8.0.7 source), where
DELAY_ACK is defined:
* Indicate whether this ack should be delayed.
* We can delay the ack if:
* - delayed acks are enabled (set to 1) and
* - our last ack wasn't a 0-sized window. We never want to delay
* the ack that opens up a 0-sized window.
* - delayed acks are enabled (set to 2, "more compatible") and
* - our last ack wasn't a 0-sized window.
* - if the peer hasn't sent us a TH_PUSH data packet (this
* solves 3649245)
* - the peer hasn't sent us a TH_PUSH data packet, if he did,
* take this as a clue that we
* need to ACK with no delay. This helps higher level protocols
* who won't send
* us more data even if the window is open because their last
* "segment" hasn't been ACKed
* - delayed acks are enabled (set to 3, "streaming detection") and
* - if we receive more than 4 full packets per second on this
* socket, we're streaming acts as "1".
* - if we don't meet that criteria, acts like "2". Allowing faster
* acking while browsing for example.
(slightly reformatted).
HTH,
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Enhancement of the Director's Income
--------
When LuteFisk is outlawed,
Only outlaws will have LuteFisk
--------
