FYI - tests on Verizon LTE show significant bufferbloat

Jonathan Morton chromatix99 at gmail.com
Mon Dec 31 17:49:06 EST 2012


On 31 Dec, 2012, at 8:44 pm, dpreed at reed.com wrote:

> Here are the "network access link properties" I observed from the client laptop:
>  
> current latency: 63 msec, 0% loss.
> TCP setup latency: 94 msec.
> Network bandwidth: uplink 2.3 Mb/sec, downlink 5.2 Mb/sec
> Network buffer measurements: uplink 3000 msec, downlink 2400 msec.
>  
> Netalyzr doesn't tell me where the buffers are - they might be in the phone itself (Android is based on Linux, but unfortunately it's quite awkward to probe its internal network parameters/stats) or they might be in the path to/from the phone to the public Internet.

I would guess both, since it appears in both directions.  You're not hitting USB bandwidth limits there (USB 1.1 is 12Mbps less some overhead, USB 2.0 is more like 480Mbps), so at least the downlink must be bloated to the tune of a megabyte or so to make those numbers.  The upiink is probably due to Linux network stack defaults in Android.

> This looks depressingly like the old ATT HSPA stats I measured with a USB cable device.

I can reliably reproduce downlink bloat using a tethered iPhone 3G in Finland, producing tens of seconds of latency.  In that case it's a shaped connection, and the shaper evidently has a big dumb tail-drop queue.

> I realize that lots of people at IETF seem to still believe that bufferbloat is totally unimportant, and unnecessary to fix.  However, the wireless companies are, unlike cable companies, not local monopolies.  So they might decide that competition forces them to actually fix the problem, lest their competitors do so first.

Here's hoping...

 - Jonathan Morton




More information about the Bloat-devel mailing list