General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Greg White <g.white@CableLabs.com>
To: "Jim Gettys" <jg@freedesktop.org>,
	"Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: "aqm@ietf.org" <aqm@ietf.org>,
	"cerowrt-devel@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [aqm]  the side effects of 330ms lag in the real world
Date: Tue, 29 Apr 2014 18:09:15 +0000	[thread overview]
Message-ID: <CF854049.33612%g.white@cablelabs.com> (raw)
In-Reply-To: <CAGhGL2C5czsFcjVL8QJbZ9=oFMFNFv+iALcCgfko9eE9e9V9Xg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]

FYI piggybacked requests in DOCSIS eliminate the possibility of request collisions (and resulting backoff/retry).  In DOCSIS 3.0 they will result in lower latency only as a result of eliminating these events.  In a lightly loaded DOCSIS 3.0 network (few neighbors contending for bandwidth) the collision probability will be low anyway, so it won't make much difference.  In a highly utilized network (especially in the case where a lot of neighbors are sending at rates below the piggybacking threshold) it can make a bigger difference.

Packet rates above ~200pps will be sufficient to ensure piggybacking.

I usually consider ~6ms to be the nominal upstream MAC latency, and ~0.7ms to be the equivalent on downstream, making the RTT on the DOCSIS 3.0 link close to 7ms (depending on configuration).

-Greg

From: Jim Gettys <jg@freedesktop.org<mailto:jg@freedesktop.org>>
Date: Tuesday, April 29, 2014 at 11:07 AM
To: Toke Høiland-Jørgensen <toke@toke.dk<mailto:toke@toke.dk>>
Cc: bloat <bloat@lists.bufferbloat.net<mailto:bloat@lists.bufferbloat.net>>, "Fred Baker (fred)" <fred@cisco.com<mailto:fred@cisco.com>>, "aqm@ietf.org<mailto:aqm@ietf.org>" <aqm@ietf.org<mailto:aqm@ietf.org>>, "cerowrt-devel@lists.bufferbloat.net<mailto:cerowrt-devel@lists.bufferbloat.net>" <cerowrt-devel@lists.bufferbloat.net<mailto:cerowrt-devel@lists.bufferbloat.net>>, Mikael Abrahamsson <swmike@swm.pp.se<mailto:swmike@swm.pp.se>>
Subject: Re: [aqm] [Bloat] the side effects of 330ms lag in the real world




On Tue, Apr 29, 2014 at 1:01 PM, Toke Høiland-Jørgensen <toke@toke.dk<mailto:toke@toke.dk>> wrote:
Jim Gettys <jg@freedesktop.org<mailto:jg@freedesktop.org>> writes:

> Now, if someone gives me real fiber to the home, with a real switch fabric
> upstream, rather than gpon life might be somewhat better (if the switches aren't
> themselves overbuffered.... But so far, it isn't.

As a data point for this, I have fibre to my apartment building and
ethernet into the apartment. I get .5 ms to my upstream gateway and
about 6 ms to Google. Still measured up to ~20 ms of bufferbloat while
running at 100 Mbps...

http://files.toke.dk/bufferbloat/data/karlstad/cdf_comparison.png

However, as that graph shows, it is quite possible to completely avoid
bufferbloat by deploying the right shaping​
And in that case fibre
*does* have a significant latency advantage. The best latency I've seen
to the upstream gateway on DSL has been ~12 ms.

​Media access is a killer on Cable too, putting the latency floor at around 8ms on my Docsis 3.0 Comcast service, though you can sometimes get lucky and piggyback. to somewhat lower latency, IIRC conversations with Greg White about how cable works.
                                       - Jim


-Toke


[-- Attachment #2: Type: text/html, Size: 5143 bytes --]

  reply	other threads:[~2014-04-29 18:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-29  1:24 [Bloat] " Dave Taht
2014-04-29  7:08 ` [Bloat] [aqm] " Mikael Abrahamsson
2014-04-29  7:21   ` Fred Baker (fred)
2014-04-29  7:56     ` Mikael Abrahamsson
2014-04-29 15:46       ` Dave Taht
2014-04-29 16:51         ` Aaron Wood
2014-04-29 16:44       ` Jim Gettys
2014-04-29 16:57         ` Jim Gettys
2014-04-29 17:01         ` Toke Høiland-Jørgensen
2014-04-29 17:07           ` Jim Gettys
2014-04-29 18:09             ` Greg White [this message]
2014-04-30  3:21           ` Dave Taht
2014-04-30  6:53           ` Jan Ceuleers
2014-04-30  8:19             ` Pedro Tumusok
2014-04-30  8:30             ` Mikael Abrahamsson
2014-04-29 17:02         ` Dave Taht
2014-04-30  6:16         ` Mikael Abrahamsson
2014-04-29  7:43   ` Tristan Seligmann
2014-04-29 23:01 Hal Murray
2014-04-29 23:26 Michael Spacefalcon
2014-04-29 23:56 ` Steinar H. Gunderson
2014-04-30  0:14 ` Hal Murray

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=CF854049.33612%g.white@cablelabs.com \
    --to=g.white@cablelabs.com \
    --cc=aqm@ietf.org \
    --cc=bloat@lists.bufferbloat.net \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=jg@freedesktop.org \
    --cc=toke@toke.dk \
    /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