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.

fred basset
  • 1,025
  • 3
  • 15
  • 22
  • 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
  • In order to disable congestion control you can simply create empty implementation: http://comments.gmane.org/gmane.linux.network/183051 Or you can set all parameters to very high values, which in your case should give you the same results: http://superuser.com/questions/307213/tcp-slow-start-and-congestion-control-and-how-to-modify-them – Darth Hunterix May 20 '14 at 21:09
  • Or you can go UDP and implement transmission control yourself - this way you'll be able to easily tune it as best as you can to your needs. – Darth Hunterix May 20 '14 at 21:21
  • Thanks Darth I've been experimenting with UDP transfer and was able to get about 10KBytes/second upload, quite a bit faster. Still would prefer the easy route of tuning TCP, if that is possible. – fred basset May 20 '14 at 21:56
  • While you're at it, you can also try SCTP: http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol Since it implements some features of both TCP and UDP it can give you pretty interesting results. – Darth Hunterix May 21 '14 at 19:27

1 Answers1

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.

msw
  • 10,503
  • 1
  • 31
  • 43
  • 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 01:54