Historic archive of defunct list bloat-devel@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: dpreed@reed.com
Cc: bloat-devel@lists.bufferbloat.net
Subject: Re: FYI - tests on Verizon LTE show significant bufferbloat
Date: Tue, 1 Jan 2013 00:49:06 +0200	[thread overview]
Message-ID: <8D66BAD1-B12A-4D68-89D6-C0D7C781BC52@gmail.com> (raw)
In-Reply-To: <1356979451.184121766@apps.rackspace.com>


On 31 Dec, 2012, at 8:44 pm, dpreed@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


      reply	other threads:[~2012-12-31 22:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-31 18:44 dpreed
2012-12-31 22:49 ` Jonathan Morton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8D66BAD1-B12A-4D68-89D6-C0D7C781BC52@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=bloat-devel@lists.bufferbloat.net \
    --cc=dpreed@reed.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox