Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a debian server with a bandwidth of 100 Mbps. My clients are mostly connected using 3G networks, for a duration of 30 mn in average. A lot of them have packet loss, rarely, but each time a packet is lost, the tcp link is stalled for 30 seconds or more before everything goes back to normal.

The server uses about 5% of the cpu, memory, and bandwidth.

I have come accross a list of options for debian and tunning the tcp stack:

I wonder which parameter would allow the server or the client to stall less time when a packet is lost. Any idea ?

share|improve this question
You can't tune the client's TCP parameters from the server side. 30 seconds is a really long time to wait on a resend, are you sure the client's simply losing packets, instead of losing their 3G connection completely? Before you take a hatchet to your TCP settings, confirm your assumptions - a packet capture of this delay event would be a good start. – Shane Madden Feb 18 '12 at 23:36
up vote 4 down vote accepted

It is very hard to tune out the problems of packet loss - TCP really doesn't like it, and assumes very strongly that it is a sign of use over capacity rather than an unreliable network. With a 3G link that is ... not always true. documents how to select alternative congestion control algorithms, and has notes about some of the options available in the Linux kernel.

You almost certainly want tcp_frto enabled, since it is designed to work well with intermittent loss environments like radio network, and unlike the Internet.

You might consider raising tcp_maxreordering above the default, if you are experiencing loss while windows are large.

Make sure that SACK and similar features are on; I doubt you have turned them off, but just in case...

Beyond that, there isn't that much that can really help you out here. The congestion control response and, especially, recovery is really the key to improving performance. Don't expect miracles, though, and whatever you do, don't assume that anything will make life better without testing it thoroughly!

share|improve this answer
Thank you for these informations. Do you know by any chance if the server needs to be reboot when i edit sysctl.conf or if a simple sysctl -p is enough for the changes to take effect ? – Joel Feb 19 '12 at 0:34
Those should be able to be changed at runtime. – Daniel Pittman Feb 19 '12 at 0:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.