General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Keith Winstein <keithw@mit.edu>
To: Michael Richardson <mcr@sandelman.ca>
Cc: "bloat@lists.bufferbloat.net" <bloat@lists.bufferbloat.net>,
	"end2end-interest@postel.org" <end2end-interest@postel.org>
Subject: Re: [Bloat] [e2e] bufferbloat paper
Date: Thu, 10 Jan 2013 02:37:41 -0500	[thread overview]
Message-ID: <CAMzhQmMHi6e-opq2ySpYZgcrbf454WSjV5gLjjPuHxM0bTgcBw@mail.gmail.com> (raw)
In-Reply-To: <1354.1357740450@sandelman.ca>

Hello Michael,

On Wed, Jan 9, 2013 at 9:07 AM, Michael Richardson <mcr@sandelman.ca> wrote:
> Have you considered repeating your test with two phones?

Yes, we have tried up to four phones at the same time.

> Can the download on phone1 affect the latency seen by a second phone?

In our experience, a download on phone1 will not affect the unloaded
latency seen by phone2. The cell towers appear to use a per-UE
(per-phone) queue on uplink and downlink. (This is similar to what a
commodity cable modem user sees -- I don't get long delays just
because my neighbor is saturating his uplink or downlink and causing a
standing queue for himself.)

However, a download on phone1 can affect the average throughput seen
by phone2 when it is saturating its link, suggesting that the two
phones are contending for the same limited resource (timeslices and
OFDM resource blocks, or possibly just backhaul throughput).

> Obviously the phones should be located right next to each other, with
> some verification that they are actually associated to the same tower.

This is harder than we thought it would be -- the phones have a
tendency to wander around rapidly among cell IDs (sometimes switching
several times in a minute). We're not sure if the different cell IDs
really represent different towers (we doubt it) or maybe just
different LTE channels or logical channels. I understand in LTE it is
possible for multiple towers to cooperate to receive one packet, so
the story may be more complicated.

In practice it is possible to get four phones to "hold still" on the
same cell ID for five minutes to do a test, but it is a bit like
herding cats and requires some careful placement and luck.

Best regards,
Keith

  reply	other threads:[~2013-01-10  7:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-08  7:35 [Bloat] " Ingemar Johansson S
2013-01-08 10:42 ` [Bloat] [e2e] " Keith Winstein
2013-01-08 12:19   ` Ingemar Johansson S
2013-01-08 12:44     ` Keith Winstein
2013-01-08 13:19       ` Ingemar Johansson S
2013-01-08 15:29         ` dpreed
2013-01-08 16:40           ` Mark Allman
2013-01-09 14:07   ` Michael Richardson
2013-01-10  7:37     ` Keith Winstein [this message]
2013-01-10 13:46       ` Michael Richardson
2013-01-08 15:04 ` dpreed
2013-01-18 22:00 ` [Bloat] " Haiqing Jiang
2013-01-10 13:48 [Bloat] [e2e] " dpreed

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

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=CAMzhQmMHi6e-opq2ySpYZgcrbf454WSjV5gLjjPuHxM0bTgcBw@mail.gmail.com \
    --to=keithw@mit.edu \
    --cc=bloat@lists.bufferbloat.net \
    --cc=end2end-interest@postel.org \
    --cc=mcr@sandelman.ca \
    /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