Alexey,
Thanks for the clarification on the pingpong behaviour!
Some more questions..
>> I'm still wondering why the next ack isnt delayed as well, though.
>
>Because out tcp is enough clever to understand that it made
>a shit delaying ACK for previous packet. But not enough psychic
>to foresee future and to avoid delay. :-)
>.100 experiences delack timeout, which is considered as an error.
>It is really error. So, tcp clears pingpong and returns to quickack.
So I understand that we're allowing pingpong to retain state of whether
it makes sense to delay right now or not, based on whats been happening,
and trying to avoid a delayed ack timer expiry..
But...
>This loop would repeat infinitely, if connection were not closed.
>Kernel sees that user replies fastly, switches to canonical BSD mode
>to allow ack piggibacking and tries to delay ack, but silly user does
>not want to reply more. So, we have reduced amount of timeouts twice,
>but this is not a big win in this case.
>
>I am writing this mostly because it is the best demonstration
>why TCP_QUICKACK:=0 is invalidated. :-)
Then whats the point of TCP_QUICKACK socket option at all? If its only
a user hint that gets erased on the first go through, that is one full system call just
to avoid a delay on one packet. The user isnt going to write an application full of
setsockopt() calls based on his data sends, right?
>What's about advice to use TCP_NODELAY in this case, it is _absolutely_
>wrong and in fact presents violation of protocol, this app sends silly
>spagetti of pakets which must be coalesced. It is exactly the situation
>when TCP_NODELAY is straight bug. This app should use TCP_CORK or,
>even better from the viewpoint of performance, to coalesce writes at user
>user level not abusing tcp.
True, this is an abuse of TCP :). But we should have the freedom to do so, right? :)
i.e. User may need to send small amounts of data at a time. The user might even
want to have that data sent out immediately, and not want the kernel to delay the send.
After all, if the application is sending down large full frames, the kernel is by default
not going to be halted by Nagle. Its really only when you are sending small packets
at a time that youre affected by Nagle and might want to set NODELAY, especially
if that application is highly interactive?.
thanks,
Nivedita
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:39 EST