lkml.org 
[lkml]   [2012]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectTCP Delayed ACK in FIN/ACK
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-08-04 17:21    [W:0.037 / U:0.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site