From: Dave Taht <dave.taht@gmail.com>
To: Jim Gettys <jg@freedesktop.org>
Cc: bloat <bloat@lists.bufferbloat.net>,
"Fred Baker \(fred\)" <fred@cisco.com>,
"aqm@ietf.org" <aqm@ietf.org>,
"cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [aqm] [Bloat] the side effects of 330ms lag in the real world
Date: Tue, 29 Apr 2014 10:02:08 -0700 [thread overview]
Message-ID: <CAA93jw7nfhDbw2ehQAGK9nEUMtaFj=eMu3P0OK6HhHAfBJxdFg@mail.gmail.com> (raw)
In-Reply-To: <CAGhGL2Bzo1Jmq0Tu2t-3w+2m4Sy7BpOkBQE-_C3vAg75JZR=2w@mail.gmail.com>
On Tue, Apr 29, 2014 at 9:44 AM, Jim Gettys <jg@freedesktop.org> wrote:
>
>
>
> On Tue, Apr 29, 2014 at 3:56 AM, Mikael Abrahamsson <swmike@swm.pp.se>
> wrote:
>>
>> On Tue, 29 Apr 2014, Fred Baker (fred) wrote:
>>
>>> Well, we could discuss international communications. I happen to be at
>>> Infocom in Toronto, VPN’d into Cisco San Jose, and did a ping to you:
>>
>>
>> Yes, but as soon as you hit the long distance network the latency is the
>> same regardless of access method. So while I agree that understanding the
>> effect of latency is important, it's no longer a meaningful way of selling
>> fiber access. If your last-mile is fiber instead of ADSL2+ won't improve
>> your long distance latency.
>
>
> FIOS bufferbloat is a problem too.
>
> Measured bufferbloat, symmetric 25/25 service in New Jersey at my inlaw's
> house is 200ms (on the ethernet port of the Actiontec router provided by
> Verizon). So latency under load is the usual problem.
ESR's link, before and after the cerowrt SQM treatment:
https://www.bufferbloat.net/projects/codel/wiki/RRUL_Rogues_Gallery#Verizon-FIOS-Testing-at-25Mbit-up-and-25Mbit-down
> Why would you think the GPON guys are any better in principle than cable or
> DSL? Cable and DSL may be somewhat worse, just because it is older and
> downward compatibility means that new modems on low bandwidth tiers are even
> more grossly over buffered.
Well, buffering on the DSLAM or CMTS needs to be more actively
managed. Fixed limits are much like conventional policing, always
either too large or too small to handle sustained or bursty traffic
respectively.
I have been fiddling with Tim Shepard's "udpburst" tool as a quick
means of measuring head end buffering, even with fq_codel present on
the inbound. (It's not suitable for open internet use as yet, but code
in progress can be had or enhanced at
https://github.com/dtaht/isochronous ). I just added ecn and tos
setting support to it.
server: ./udpburst -S -E -D 32 # Server mode, enable ECN marking, set
dscp to 0x20 (CS1)
client:
This is from a 22Mbit down CMTS
d@nuc:~/git/isochronous$ ./udpburst -f 149.20.63.30 -E -C -d -n 400 -s 1400
1400 bytes -- received 382 of 400 -- 365 consecutive 0 ooo 0 dups 2 ect
........................................................................
........................................................................
........................................................................
........................................................................
........................................................................
.... .. . ... . ... . .. .. . .
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
or roughly 512k of buffering.
A DSL link (6400 down)
d@puck:~/git/isochronous$ ./udpburst -f snapon.lab.bufferbloat.net -n
100 -C -d -s 1000
1000 bytes -- received 71 of 100 -- 71 consecutive 0 ooo 0 dups 0 ect
......................................................................
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
or roughly 64k worth of buffering. Interestingly the bandwidth disparity between
the server (gigE in isc.org's co-lo), is so great that fq_codel can't
kick in before
the 64k dslam buffer is overrun.
> You can look at the netalyzr scatter plots in
> http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/
>
> 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.
> - Jim
>
> - Jim
>
> - Jim
>
>>
>>
>> --
>> Mikael Abrahamsson email: swmike@swm.pp.se
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>
--
Dave Täht
NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
next prev parent reply other threads:[~2014-04-29 17:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 1:24 [Cerowrt-devel] " Dave Taht
2014-04-29 7:08 ` [Cerowrt-devel] [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 ` [Cerowrt-devel] [Bloat] " Aaron Wood
2014-04-29 16:44 ` Jim Gettys
2014-04-29 16:57 ` Jim Gettys
2014-04-29 17:01 ` [Cerowrt-devel] [aqm] [Bloat] " Toke Høiland-Jørgensen
2014-04-29 17:07 ` Jim Gettys
2014-04-29 18:09 ` Greg White
2014-04-30 3:21 ` Dave Taht
2014-04-29 17:02 ` Dave Taht [this message]
2014-04-30 6:16 ` [Cerowrt-devel] [Bloat] [aqm] " Mikael Abrahamsson
2014-04-29 7:43 ` Tristan Seligmann
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/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw7nfhDbw2ehQAGK9nEUMtaFj=eMu3P0OK6HhHAfBJxdFg@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=aqm@ietf.org \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=fred@cisco.com \
--cc=jg@freedesktop.org \
/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