5

On my project we have remote Linux nodes that communicate over the Internet via very low speed CDMA cell modems. The bandwidth on these modems is about 2kbyte/second and the RTT back to the server is about 800ms.

Based on these limitations, would there be any benefit in trying to tune the Linux TCP stack to match this performance? E.g. I recently found out about the pluggable congestion control algorithms and am wondering if there's a different one to the default that might work better. Sometimes I've seen downloads on these modems crawl to 800 bytes/second. I ran some UDP tests and packet loss was about 25%.

Linux is 2.6.35.3 with Debian Wheezy on ARMHF.

  • There is so much more complexity, I'm pretty sure that all you are going to get here is conjecture and opinion and not a definitive answer. So just try it and see. – mdpc May 20 '14 at 18:11
  • Yes I will run some experiments myself, but hopefully someone out there has a similar setup time mine and can advise... – fred basset May 20 '14 at 18:59
  • Congestion control algorithms performance depends rather on packet loss than bandwidth. Running tests is a good idea (you can post results here, for future generations), but I doubt you'll notice any difference (in similar packet loss conditions), because in all cases you'll reach peak transfer very quickly. Or you can just switch them off completely. With that low bandwidth you won't affect any other users, and you'll get the best connection possible. – Darth Hunterix May 20 '14 at 20:05
  • How do I switch congestion control off? – fred basset May 20 '14 at 20:33
  • I don't have much experience in congestion control tuning, but have you looked at Hybla? It sounds like it might be the one you need. – Bratchley May 20 '14 at 20:54
1

"I've seen downloads on these modems crawl to 800 bytes/second."

You've not given loss measurements, so it is impossible to tell if you are seeing congestion or merely smaller-than-spec channel capacity.

It is important to note that TCP was designed on hardware much slower and probably with a greater error rate than your equipment. For slower connections, TCP makes extremely good use of available capacity.

You can try different congestion control mechanisms but I'd be surprised if you get better throughput than you do currently. Measuring real channel capacity over real networks is staggeringly more complicated than it seems it should be.

  • Updated, packet loss about 25%. – fred basset May 20 '14 at 20:33
  • That's what I mean about measurement of real networks: 25% packet loss is dreadfully underspecified and would need dispersion, burstiness, and so on to properly characterize. I maintain my guess about standard TCP being hard to beat for your capacity and mean loss rate. – msw May 20 '14 at 20:54
  • you are probably right, I'll continue my experiments however and update this post if I find anything promising. – fred basset May 21 '14 at 1:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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