TCP Delayed ACK in FIN/ACK

[SÅawek Janecki]

I have a node.js client (10.177.62.7) requesting some data from http
rest service from server (10.177.0.1).
Client is simply using nodejs http.request() method (agent=false).
Client is on Ubuntu 11.10 box.
Why client sends FIN ACK after 475ms? Why so slow? He should send FIN
ACK immediately.
I have many situations like this. About 1% of whole traffic is request
with delayed FIN ACK.
Cpu idle on the client is about 99%, so nothing is draining CPU.
How to debug this? What could it be? Is there any sysctl option I need to tune?
I think this behaviour is the Delayed ACK feature of RFC1122 TCP stack.

Link to tcpdump picture (done on a client machine) :
http://i48.tinypic.com/35cpogx.png

Can you tell why kernel delayed that FIN/ACK.
In tcpflow data there is exacly one ACK per packet comming from server.
Why kernel delayed client FIN/ACK.
It could avoid sending ACK every 'data' packet.
But it choose to delay FIN/ACK?
Is this possible? Is this a bug?

I've also posted question on stackexchange:
http://stackoverflow.com/questions/11711218/client-sends-delayed-fin-ack-500ms-to-server

Please help.

-- 
pozdrawiam
SÅawomir Janecki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/