Skip to main content

tcp_keepalive and tcp_retries

By
The Proc entries to change the timeout values for TCP keep alive and TCP retransmissions.
1) TCP Keep-Alive:
A) tcp_keepalive_time:
The number of seconds a connection needs to be idle before TCP
begins sending out keep-alive probes. Keep-alives are only sent
when the SO_KEEPALIVE socket option is enabled. The default
value is 7200 seconds (2 hours).
This default value can be changed by over writing the proc entry.
example: echo 20 > /proc/sys/net/ipv4/tcp_keepalive_time.
B) tcp_keepalive_probes:
The maximum number of TCP keep-alive probes to send before giving
up and killing the connection if no response is obtained
from the other end. The default value is 9.
Corresponding proc entry to change this value.
example: echo 2 > /proc/sys/net/ipv4/tcp_keepalive_probes
C) tcp_keepalive_intvl:
The number of seconds between TCP keep-alive probes. The
default value is 75 seconds.
Corresponding proc entry to change this value.
example: echo 10 > /proc/sys/net/ipv4/tcp_keepalive_intvl

Note:
1) what ever values has taken in examples is the values that we set for USBIP server.
2) Keepalive timer will be kicked off when there is no data transaction on that particular socket.
Cases in which Heart Beat Fails:
The HeartBeat will fail to close the connection when the device has got the data to send or the board
has some response to send. For ISOCH IN devices there will be always some data to send.
2) TCP Retransmissions:
1) TCP retransmission timer will be start as soon as the data has been given to the
IP layer and this timer will be initiated if no ACK is received for this packet.
2) The maximum number of times a TCP packet is retransmitted in established state before giving up
is based on "TCP_RETRIES2" value. The default value is 15, which corresponds to a duration of approximately 13 min, depending on
the retransmission timeout.
3) The interval between two successive retransmissions will be increased exponentially.
(This is based on the RTT value).
4) we can close the connection early by reducing either "Maximum Retransmission time out" or by reducing the "number of retries".
5) we are reducing the number of retries value to "5", which will take approximately 17 seconds to close the connection.
The proc entry to change this value is
/proc/sys/net/ipv4/tcp_retries2
Labels:

Comments

Post a Comment

Popular posts from this blog

Dotnet, .Net 3.5, 2.0, C# Interview Questions

By
Few questions on dotnet, C# 2.0, 3.5 On Object oriented concepts 1)What is inheritance with e.g 2)What is polymorphism -function overloading -Function overriding -virtual keyword use -Static keyword and use -Abstract classes -Interface -Object 3)What is threading and how do we use in realtime application(cognizant) 4)What is threadpooling, lock, monitor(write code sample) 5)Architecture of current project 6)Session state, diffrent types of state management. 7)What is Application_Start, how it works. 8)Type of authentication in asp.net 9)How to configure ASP.NET application. 10) What is Impersonation. 11) What is WebService, WSDL, UDDI, Discovery, asmx files. 12) How to implement WebService and use it. 13) When to use WebServices. 14) WPF, how to implement(BOA) 15) Testing concvepts. 16) Test attributes 17) Flow of Automation Test Method execution 18) Features of dotnet 3.5 19) CLR, garbage collection 20) Finally block 21) Manifest, Metadata, MSIL 22) Assemblies, Type of assemblies, str...
2 comments
Read more

Remote debugging for ARM target board

By
Remote debugging for ARM target board With GDB one can both trace and modify code and data flow, and otherwise analyze the behavior of code, without explicitly changing any of it. Rather than run a full-blown instance of GDB on the target platform, you can use GDBserver , a program that lets you run GDB on a different machine than the one on which your program is running. The advantage of using GDBserver is that it needs just a fraction of the target resources that GDB consumes, because it implements only the low-level functionality of the debugger -- namely setting breakpoints and accessing the target processor registers and read/write application memory. GDBserver takes control of the application being debugged, and then waits for instructions from a remote instance of GDB running on a development workstation. Remote target needs to have debugging stub (gdbserver), The gdbserver is also referred to as the 'stub' and must be cross-compiled for that targ...
3 comments
Read more