more latency than a telegraph: your mobile network @ work

So i was hanging out in La Guardia yesterday evening. A lot of fun, really recommend the pretzel. As flight after flight was cancelled (and WiFi is not free), people were really turning to their 3G toys to update their social networks about how late they would be and the smell of the person next to them.

Now, the 3G network performance in the area responded by more or less giving up. Constant retransmits (which are hugely inefficient).  I decided to take a look under the hood.

Now, here’s the interesting bit. No packet loss (infinite buffer and retransmits in the radio side, none on the IP side). But look @ the latency. 16s. yes seconds.

So the TCP stack is often considering a packet lost, retransmitting it, and then it gets there. and this then gets worse and worse since that retransmit causes more congestion.

The network was essentially ‘ringing’ going faster and then crashing and then faster etc.

app_111@android:/ $ ping
PING ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=48 time=16414 ms
64 bytes from ( icmp_seq=2 ttl=48 time=15924 ms
64 bytes from ( icmp_seq=3 ttl=47 time=16398 ms
64 bytes from ( icmp_seq=4 ttl=47 time=18775 ms
64 bytes from ( icmp_seq=5 ttl=47 time=20238 ms
64 bytes from ( icmp_seq=6 ttl=48 time=19445 ms
64 bytes from ( icmp_seq=7 ttl=48 time=18531 ms
64 bytes from ( icmp_seq=8 ttl=48 time=17894 ms
64 bytes from ( icmp_seq=9 ttl=48 time=17340 ms
64 bytes from ( icmp_seq=10 ttl=48 time=17982 ms
64 bytes from ( icmp_seq=11 ttl=48 time=17878 ms
64 bytes from ( icmp_seq=12 ttl=48 time=17414 ms
64 bytes from ( icmp_seq=13 ttl=48 time=16781 ms
64 bytes from ( icmp_seq=14 ttl=47 time=16316 ms
64 bytes from ( icmp_seq=16 ttl=48 time=15205 ms
64 bytes from ( icmp_seq=21 ttl=48 time=10901 ms
64 bytes from ( icmp_seq=22 ttl=48 time=9992 ms</pre>






Leave a Reply

Your email address will not be published. Required fields are marked *