5

I have two linux machines connected by a radio modem. The bandwidth is about 2kbps, with ping times of around 400ms (5% packet loss).

Currently, ssh sessions have a delay in the order of 5 seconds, although this varies. Raw telnet is similar and just opening a tcp connection seems to take forever.

Does anyone know how best tune the IP parameters in such a case?

John K
  • 51
  • 2
  • 1
    I wish you luck. I don't think there's much or any "tuning" you'll be able to do, except for perhaps replacing the ancient radio modems with something more modern. – Michael Hampton Apr 20 '18 at 20:30
  • 1
    The error level is high - more 1℅ packets loss. It will produce breaking of encrypted connections. @MichaelHampton is right. – Mikhail Khirgiy Apr 21 '18 at 04:37
  • Can you add current `iwconfig` and `sysctl net.ipv4.tcp_*` configuration to your post? Please benchmark `net.ipv4.tcp_congestion_control = cubic ` against `westwood` (you might have to load `tcp_westwood` module) – anx Apr 21 '18 at 14:23
  • I'm guessing that's 5% loss with *small* packets, because that's the default. Also, 400ms RTT means it can't be more than 50 bytes at 2000 bits per second, because that's how long it takes to transmit those bytes twice (each direction) – derobert Apr 23 '18 at 21:00

2 Answers2

2

Make sure you're running with a sufficiently low MTU, if possible. A single 1500-byte packet takes ~6s to transmit on your link (presuming you meant 2 kilobits per second, not bytes). And you're losing a fair number of them (probably more than 5%, if that is your packet loss with ping remote-end, not ping -s «MAX-SIZE» remote-end), requiring resending the entire packet.

Strictly speaking, IPv4 can go down to an MTU of 68 (which is too small anyway), but Linux's PMTU discovery is limited to no smaller than 552, and possibly other parts of the stack fail below 128 bytes or so.

Note that you are operating at well under a tenth of the bandwidth TCP's designers had back in 1973.

Community
  • 1
derobert
  • 1,288
  • 12
  • 22
0

Loss will degrade TCP throughput. And that lag is well into human perceptible delay.

Consider rethinking the protocols and applications you use for latency and disconnect tolerance. For example:

  • mosh calls itself a "mobile shell" that survives connectivity changes, and predicts echo locally for a faster experience.
  • Citrix has some intelligence to display (Windows) GUI apps over poor connections. Although I doubt you can get much of a GUI at 2 kbps.
John Mahowald
  • 30,009
  • 1
  • 17
  • 32