TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through ODBC)

Arnaud Lesauvage <thewild@freesurf.fr> writes:

> Magnus Hagander a écrit :
>> Since it works with different speeds in different clients, it *probably*
>> isn't on the server side. I'm far from sure on that though, there may be
>> other paramters that are implicitly changed when ODBC is used.
>
> Yes, that was my first impression also. But the fact that the server
> waits for an ACK from the client before it goes on sending packet is
> quite strange, isn't it ?

I don't think that's what happens.

Those are two very different but unfortunately related things.

1) the Nagle algorithm (disabled by TCP_NO_DELAY) is an optimization
when sending. It prevents sending many small packets, by waiting a
little bit for them to become bigger. The price is a higher latency.

2) the half-ACK frequency is an similar optimization when
receiving. It cuts the number of sent acknowledgements by two, by
waiting a little bit to receive a 2nd packet, acknowledging the two
packets using only one ACK. You can disable it with TcpAckFrequency in
the registry.


So far, those two have nothing in common. But the thing is, TCP
_piggybacks_ acknowledgements packets of data flowing in one direction
together with data packets flowing in the opposite direction.

So, if you force TCP to send data more frequently with TCP_NO_DELAY,
then it will also send ACKs (of the opposite communication) more
frequently as a side effect. Once you decided to send a packet, then
better put the maximum information in it!

Same thing if you force TCP to send ACKs more frequently using
TcpAckFrequency: then you'll get some TCP_NO_DELAY effect as a
bonus. Once you decided to send an ACK, then better send the staging
data in the same packet!

So you see that TcpAckFrequency can (in some scenarios) play the role
of TCP_NO_DELAY. And vice-versa. That's probably what you experienced.