* [Bloat] I have a new record for bloat
@ 2017-01-31 20:02 Aaron Wood
2017-01-31 20:13 ` Dave Taht
0 siblings, 1 reply; 9+ messages in thread
From: Aaron Wood @ 2017-01-31 20:02 UTC (permalink / raw)
To: bloat
[-- Attachment #1: Type: text/plain, Size: 3210 bytes --]
This is wifi tethering from my OSX laptop to my iPhone, right after the
laptop tried to reconnect to the iphone after waking up.
64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=42907.196 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=41922.290 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=40971.714 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=39967.402 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=38964.115 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=37986.640 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=37026.309 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=56 time=36073.683 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=56 time=35075.141 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=56 time=26273.867 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=56 time=25268.726 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=56 time=24270.618 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=56 time=23269.550 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=56 time=22265.406 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=56 time=21264.648 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=56 time=20305.022 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=56 time=19316.740 ms
64 bytes from 8.8.8.8: icmp_seq=26 ttl=56 time=17310.953 ms
64 bytes from 8.8.8.8: icmp_seq=25 ttl=56 time=18316.163 ms
64 bytes from 8.8.8.8: icmp_seq=27 ttl=56 time=16320.196 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=56 time=15409.592 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=56 time=14411.919 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=56 time=13505.362 ms
64 bytes from 8.8.8.8: icmp_seq=31 ttl=56 time=12505.893 ms
64 bytes from 8.8.8.8: icmp_seq=32 ttl=56 time=11502.744 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=56 time=10501.390 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=56 time=9560.551 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=56 time=8566.430 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=56 time=7570.286 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=56 time=6588.928 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=56 time=5643.342 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=56 time=4639.435 ms
64 bytes from 8.8.8.8: icmp_seq=40 ttl=56 time=3722.169 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=56 time=2719.881 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=56 time=1806.913 ms
64 bytes from 8.8.8.8: icmp_seq=43 ttl=56 time=1218.198 ms
64 bytes from 8.8.8.8: icmp_seq=55 ttl=43 time=1030.052 ms
64 bytes from 8.8.8.8: icmp_seq=56 ttl=43 time=638.601 ms
64 bytes from 8.8.8.8: icmp_seq=57 ttl=43 time=216.295 ms
64 bytes from 8.8.8.8: icmp_seq=58 ttl=43 time=200.674 ms
64 bytes from 8.8.8.8: icmp_seq=59 ttl=43 time=797.261 ms
64 bytes from 8.8.8.8: icmp_seq=60 ttl=43 time=992.238 ms
64 bytes from 8.8.8.8: icmp_seq=61 ttl=43 time=1696.089 ms
64 bytes from 8.8.8.8: icmp_seq=62 ttl=43 time=1139.896 ms
64 bytes from 8.8.8.8: icmp_seq=63 ttl=43 time=588.823 ms
64 bytes from 8.8.8.8: icmp_seq=64 ttl=43 time=663.070 ms
64 bytes from 8.8.8.8: icmp_seq=65 ttl=43 time=782.507 ms
64 bytes from 8.8.8.8: icmp_seq=66 ttl=43 time=426.705 ms
64 bytes from 8.8.8.8: icmp_seq=67 ttl=43 time=220.192 ms
64 bytes from 8.8.8.8: icmp_seq=68 ttl=43 time=228.405 ms
64 bytes from 8.8.8.8: icmp_seq=69 ttl=43 time=130.555 ms
64 bytes from 8.8.8.8: icmp_seq=70 ttl=43 time=210.779 ms
-Aaron
[-- Attachment #2: Type: text/html, Size: 5309 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bloat] I have a new record for bloat
2017-01-31 20:02 [Bloat] I have a new record for bloat Aaron Wood
@ 2017-01-31 20:13 ` Dave Taht
2017-01-31 20:22 ` Dave Taht
2017-01-31 20:42 ` Jim Gettys
0 siblings, 2 replies; 9+ messages in thread
From: Dave Taht @ 2017-01-31 20:13 UTC (permalink / raw)
To: Aaron Wood; +Cc: bloat
On Tue, Jan 31, 2017 at 12:02 PM, Aaron Wood <woody77@gmail.com> wrote:
> This is wifi tethering from my OSX laptop to my iPhone, right after the
> laptop tried to reconnect to the iphone after waking up.
>
> 64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=42907.196 ms
Not even close for the record as we got something like 800 seconds out
of gogo-in-flight. But as for wifi + tethering, you "win", I guess.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=41922.290 ms
> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=40971.714 ms
> 64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=39967.402 ms
> 64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=38964.115 ms
> 64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=37986.640 ms
> 64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=37026.309 ms
> 64 bytes from 8.8.8.8: icmp_seq=7 ttl=56 time=36073.683 ms
> 64 bytes from 8.8.8.8: icmp_seq=8 ttl=56 time=35075.141 ms
> 64 bytes from 8.8.8.8: icmp_seq=17 ttl=56 time=26273.867 ms
> 64 bytes from 8.8.8.8: icmp_seq=18 ttl=56 time=25268.726 ms
> 64 bytes from 8.8.8.8: icmp_seq=19 ttl=56 time=24270.618 ms
> 64 bytes from 8.8.8.8: icmp_seq=20 ttl=56 time=23269.550 ms
> 64 bytes from 8.8.8.8: icmp_seq=21 ttl=56 time=22265.406 ms
> 64 bytes from 8.8.8.8: icmp_seq=22 ttl=56 time=21264.648 ms
> 64 bytes from 8.8.8.8: icmp_seq=23 ttl=56 time=20305.022 ms
> 64 bytes from 8.8.8.8: icmp_seq=24 ttl=56 time=19316.740 ms
> 64 bytes from 8.8.8.8: icmp_seq=26 ttl=56 time=17310.953 ms
> 64 bytes from 8.8.8.8: icmp_seq=25 ttl=56 time=18316.163 ms
> 64 bytes from 8.8.8.8: icmp_seq=27 ttl=56 time=16320.196 ms
> 64 bytes from 8.8.8.8: icmp_seq=28 ttl=56 time=15409.592 ms
> 64 bytes from 8.8.8.8: icmp_seq=29 ttl=56 time=14411.919 ms
> 64 bytes from 8.8.8.8: icmp_seq=30 ttl=56 time=13505.362 ms
> 64 bytes from 8.8.8.8: icmp_seq=31 ttl=56 time=12505.893 ms
> 64 bytes from 8.8.8.8: icmp_seq=32 ttl=56 time=11502.744 ms
> 64 bytes from 8.8.8.8: icmp_seq=33 ttl=56 time=10501.390 ms
> 64 bytes from 8.8.8.8: icmp_seq=34 ttl=56 time=9560.551 ms
> 64 bytes from 8.8.8.8: icmp_seq=35 ttl=56 time=8566.430 ms
> 64 bytes from 8.8.8.8: icmp_seq=36 ttl=56 time=7570.286 ms
> 64 bytes from 8.8.8.8: icmp_seq=37 ttl=56 time=6588.928 ms
> 64 bytes from 8.8.8.8: icmp_seq=38 ttl=56 time=5643.342 ms
> 64 bytes from 8.8.8.8: icmp_seq=39 ttl=56 time=4639.435 ms
> 64 bytes from 8.8.8.8: icmp_seq=40 ttl=56 time=3722.169 ms
> 64 bytes from 8.8.8.8: icmp_seq=41 ttl=56 time=2719.881 ms
> 64 bytes from 8.8.8.8: icmp_seq=42 ttl=56 time=1806.913 ms
> 64 bytes from 8.8.8.8: icmp_seq=43 ttl=56 time=1218.198 ms
> 64 bytes from 8.8.8.8: icmp_seq=55 ttl=43 time=1030.052 ms
> 64 bytes from 8.8.8.8: icmp_seq=56 ttl=43 time=638.601 ms
> 64 bytes from 8.8.8.8: icmp_seq=57 ttl=43 time=216.295 ms
> 64 bytes from 8.8.8.8: icmp_seq=58 ttl=43 time=200.674 ms
> 64 bytes from 8.8.8.8: icmp_seq=59 ttl=43 time=797.261 ms
> 64 bytes from 8.8.8.8: icmp_seq=60 ttl=43 time=992.238 ms
> 64 bytes from 8.8.8.8: icmp_seq=61 ttl=43 time=1696.089 ms
> 64 bytes from 8.8.8.8: icmp_seq=62 ttl=43 time=1139.896 ms
> 64 bytes from 8.8.8.8: icmp_seq=63 ttl=43 time=588.823 ms
> 64 bytes from 8.8.8.8: icmp_seq=64 ttl=43 time=663.070 ms
> 64 bytes from 8.8.8.8: icmp_seq=65 ttl=43 time=782.507 ms
> 64 bytes from 8.8.8.8: icmp_seq=66 ttl=43 time=426.705 ms
> 64 bytes from 8.8.8.8: icmp_seq=67 ttl=43 time=220.192 ms
> 64 bytes from 8.8.8.8: icmp_seq=68 ttl=43 time=228.405 ms
> 64 bytes from 8.8.8.8: icmp_seq=69 ttl=43 time=130.555 ms
> 64 bytes from 8.8.8.8: icmp_seq=70 ttl=43 time=210.779 ms
>
> -Aaron
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bloat] I have a new record for bloat
2017-01-31 20:13 ` Dave Taht
@ 2017-01-31 20:22 ` Dave Taht
2017-01-31 20:30 ` Toke Høiland-Jørgensen
2017-01-31 20:42 ` Jim Gettys
1 sibling, 1 reply; 9+ messages in thread
From: Dave Taht @ 2017-01-31 20:22 UTC (permalink / raw)
To: Aaron Wood; +Cc: bloat
As for my best-ever winner for an ISP test under load, this is cake
compared against sonic.net's default router for their fiber network
connecting from SF to my box in fremont (10 hops).
http://www.taht.net/~d/sonic_106_cake_vs_default.png
We're talking a max of 1.5ms extra induced jitter under load here...
on a 4ms path... and actually latency is reduced once the link gets
going. I sort of now need to do a strictly voip/videoconference test
with no other traffic on the link because of the gpon related
acquire/release delays... but the jamophone seems more feasible by the
day.
(I managed to get it closer to 100% of the uplink later)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bloat] I have a new record for bloat
2017-01-31 20:22 ` Dave Taht
@ 2017-01-31 20:30 ` Toke Høiland-Jørgensen
0 siblings, 0 replies; 9+ messages in thread
From: Toke Høiland-Jørgensen @ 2017-01-31 20:30 UTC (permalink / raw)
To: Dave Taht; +Cc: Aaron Wood, bloat
Dave Taht <dave.taht@gmail.com> writes:
> As for my best-ever winner for an ISP test under load, this is cake
> compared against sonic.net's default router for their fiber network
> connecting from SF to my box in fremont (10 hops).
>
> http://www.taht.net/~d/sonic_106_cake_vs_default.png
>
> We're talking a max of 1.5ms extra induced jitter under load here...
> on a 4ms path... and actually latency is reduced once the link gets
> going. I sort of now need to do a strictly voip/videoconference test
> with no other traffic on the link because of the gpon related
> acquire/release delays... but the jamophone seems more feasible by the
> day.
>
> (I managed to get it closer to 100% of the uplink later)
Yay! Welcome to the 21st century! ;)
-Toke
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bloat] I have a new record for bloat
2017-01-31 20:13 ` Dave Taht
2017-01-31 20:22 ` Dave Taht
@ 2017-01-31 20:42 ` Jim Gettys
2017-02-11 9:04 ` Neil Davies
1 sibling, 1 reply; 9+ messages in thread
From: Jim Gettys @ 2017-01-31 20:42 UTC (permalink / raw)
To: Dave Taht; +Cc: Aaron Wood, bloat
[-- Attachment #1: Type: text/plain, Size: 4649 bytes --]
On Tue, Jan 31, 2017 at 3:13 PM, Dave Taht <dave.taht@gmail.com> wrote:
> On Tue, Jan 31, 2017 at 12:02 PM, Aaron Wood <woody77@gmail.com> wrote:
> > This is wifi tethering from my OSX laptop to my iPhone, right after the
> > laptop tried to reconnect to the iphone after waking up.
> >
> > 64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=42907.196 ms
>
> Not even close for the record as we got something like 800 seconds out
> of gogo-in-flight. But as for wifi + tethering, you "win", I guess.
>
I measured GoGo a couple years ago at about 740 seconds(!).
IIRC, we've seen some other cellular systems with bloat at >60 seconds.
I don't understand what I'm seeing at the moment on my Pixel XL on
T-Mobile (upstream). I need to retake the data and post it along with the
qdisc structure on current Android, for people to mull over.
- Jim
>
> > 64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=41922.290 ms
> > 64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=40971.714 ms
> > 64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=39967.402 ms
> > 64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=38964.115 ms
> > 64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=37986.640 ms
> > 64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=37026.309 ms
> > 64 bytes from 8.8.8.8: icmp_seq=7 ttl=56 time=36073.683 ms
> > 64 bytes from 8.8.8.8: icmp_seq=8 ttl=56 time=35075.141 ms
> > 64 bytes from 8.8.8.8: icmp_seq=17 ttl=56 time=26273.867 ms
> > 64 bytes from 8.8.8.8: icmp_seq=18 ttl=56 time=25268.726 ms
> > 64 bytes from 8.8.8.8: icmp_seq=19 ttl=56 time=24270.618 ms
> > 64 bytes from 8.8.8.8: icmp_seq=20 ttl=56 time=23269.550 ms
> > 64 bytes from 8.8.8.8: icmp_seq=21 ttl=56 time=22265.406 ms
> > 64 bytes from 8.8.8.8: icmp_seq=22 ttl=56 time=21264.648 ms
> > 64 bytes from 8.8.8.8: icmp_seq=23 ttl=56 time=20305.022 ms
> > 64 bytes from 8.8.8.8: icmp_seq=24 ttl=56 time=19316.740 ms
> > 64 bytes from 8.8.8.8: icmp_seq=26 ttl=56 time=17310.953 ms
> > 64 bytes from 8.8.8.8: icmp_seq=25 ttl=56 time=18316.163 ms
> > 64 bytes from 8.8.8.8: icmp_seq=27 ttl=56 time=16320.196 ms
> > 64 bytes from 8.8.8.8: icmp_seq=28 ttl=56 time=15409.592 ms
> > 64 bytes from 8.8.8.8: icmp_seq=29 ttl=56 time=14411.919 ms
> > 64 bytes from 8.8.8.8: icmp_seq=30 ttl=56 time=13505.362 ms
> > 64 bytes from 8.8.8.8: icmp_seq=31 ttl=56 time=12505.893 ms
> > 64 bytes from 8.8.8.8: icmp_seq=32 ttl=56 time=11502.744 ms
> > 64 bytes from 8.8.8.8: icmp_seq=33 ttl=56 time=10501.390 ms
> > 64 bytes from 8.8.8.8: icmp_seq=34 ttl=56 time=9560.551 ms
> > 64 bytes from 8.8.8.8: icmp_seq=35 ttl=56 time=8566.430 ms
> > 64 bytes from 8.8.8.8: icmp_seq=36 ttl=56 time=7570.286 ms
> > 64 bytes from 8.8.8.8: icmp_seq=37 ttl=56 time=6588.928 ms
> > 64 bytes from 8.8.8.8: icmp_seq=38 ttl=56 time=5643.342 ms
> > 64 bytes from 8.8.8.8: icmp_seq=39 ttl=56 time=4639.435 ms
> > 64 bytes from 8.8.8.8: icmp_seq=40 ttl=56 time=3722.169 ms
> > 64 bytes from 8.8.8.8: icmp_seq=41 ttl=56 time=2719.881 ms
> > 64 bytes from 8.8.8.8: icmp_seq=42 ttl=56 time=1806.913 ms
> > 64 bytes from 8.8.8.8: icmp_seq=43 ttl=56 time=1218.198 ms
> > 64 bytes from 8.8.8.8: icmp_seq=55 ttl=43 time=1030.052 ms
> > 64 bytes from 8.8.8.8: icmp_seq=56 ttl=43 time=638.601 ms
> > 64 bytes from 8.8.8.8: icmp_seq=57 ttl=43 time=216.295 ms
> > 64 bytes from 8.8.8.8: icmp_seq=58 ttl=43 time=200.674 ms
> > 64 bytes from 8.8.8.8: icmp_seq=59 ttl=43 time=797.261 ms
> > 64 bytes from 8.8.8.8: icmp_seq=60 ttl=43 time=992.238 ms
> > 64 bytes from 8.8.8.8: icmp_seq=61 ttl=43 time=1696.089 ms
> > 64 bytes from 8.8.8.8: icmp_seq=62 ttl=43 time=1139.896 ms
> > 64 bytes from 8.8.8.8: icmp_seq=63 ttl=43 time=588.823 ms
> > 64 bytes from 8.8.8.8: icmp_seq=64 ttl=43 time=663.070 ms
> > 64 bytes from 8.8.8.8: icmp_seq=65 ttl=43 time=782.507 ms
> > 64 bytes from 8.8.8.8: icmp_seq=66 ttl=43 time=426.705 ms
> > 64 bytes from 8.8.8.8: icmp_seq=67 ttl=43 time=220.192 ms
> > 64 bytes from 8.8.8.8: icmp_seq=68 ttl=43 time=228.405 ms
> > 64 bytes from 8.8.8.8: icmp_seq=69 ttl=43 time=130.555 ms
> > 64 bytes from 8.8.8.8: icmp_seq=70 ttl=43 time=210.779 ms
> >
> > -Aaron
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
> >
>
>
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
[-- Attachment #2: Type: text/html, Size: 9773 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bloat] I have a new record for bloat
2017-01-31 20:42 ` Jim Gettys
@ 2017-02-11 9:04 ` Neil Davies
2017-02-11 18:24 ` Dave Taht
2017-03-31 22:07 ` Alex Burr
0 siblings, 2 replies; 9+ messages in thread
From: Neil Davies @ 2017-02-11 9:04 UTC (permalink / raw)
To: bloat
[-- Attachment #1: Type: text/plain, Size: 7177 bytes --]
We’ve measured timings like this on many 3GPP based systems in various countries.
It is an interaction between the radio link protocol, other parts of the 3GPP data path and way
in which such devices are integrated with the operating system (even in iOS), it is
not about the quantity of buffers but more the protocol interactions during times of stress on the
radio bearer and/or during handover.
There are protocol configuration options, different design objectives and operational management
mechanisms they _could_ use, but there is no incentive for the cellular operators to invest the
time and effort to investigate and resolve.
The same mindset that created these sort of performance artefacts is also driving changes in DSL
standards, so watch out for these sort of artefacts (again induced by things that you have no direct
control over) starting to occur in “high speed” DSL systems (such as VDSL) when conditions are less
than perfect.
Neil
> On 31 Jan 2017, at 20:42, Jim Gettys <jg@freedesktop.org <mailto:jg@freedesktop.org>> wrote:
>
>
>
> On Tue, Jan 31, 2017 at 3:13 PM, Dave Taht <dave.taht@gmail.com <mailto:dave.taht@gmail.com>> wrote:
> On Tue, Jan 31, 2017 at 12:02 PM, Aaron Wood <woody77@gmail.com <mailto:woody77@gmail.com>> wrote:
> > This is wifi tethering from my OSX laptop to my iPhone, right after the
> > laptop tried to reconnect to the iphone after waking up.
> >
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=0 ttl=56 time=42907.196 ms
>
> Not even close for the record as we got something like 800 seconds out
> of gogo-in-flight. But as for wifi + tethering, you "win", I guess.
>
> I measured GoGo a couple years ago at about 740 seconds(!).
>
> IIRC, we've seen some other cellular systems with bloat at >60 seconds.
>
> I don't understand what I'm seeing at the moment on my Pixel XL on T-Mobile (upstream). I need to retake the data and post it along with the qdisc structure on current Android, for people to mull over.
> - Jim
>
>
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=1 ttl=56 time=41922.290 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=2 ttl=56 time=40971.714 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=3 ttl=56 time=39967.402 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=4 ttl=56 time=38964.115 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=5 ttl=56 time=37986.640 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=6 ttl=56 time=37026.309 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=7 ttl=56 time=36073.683 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=8 ttl=56 time=35075.141 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=17 ttl=56 time=26273.867 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=18 ttl=56 time=25268.726 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=19 ttl=56 time=24270.618 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=20 ttl=56 time=23269.550 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=21 ttl=56 time=22265.406 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=22 ttl=56 time=21264.648 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=23 ttl=56 time=20305.022 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=24 ttl=56 time=19316.740 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=26 ttl=56 time=17310.953 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=25 ttl=56 time=18316.163 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=27 ttl=56 time=16320.196 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=28 ttl=56 time=15409.592 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=29 ttl=56 time=14411.919 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=30 ttl=56 time=13505.362 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=31 ttl=56 time=12505.893 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=32 ttl=56 time=11502.744 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=33 ttl=56 time=10501.390 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=34 ttl=56 time=9560.551 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=35 ttl=56 time=8566.430 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=36 ttl=56 time=7570.286 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=37 ttl=56 time=6588.928 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=38 ttl=56 time=5643.342 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=39 ttl=56 time=4639.435 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=40 ttl=56 time=3722.169 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=41 ttl=56 time=2719.881 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=42 ttl=56 time=1806.913 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=43 ttl=56 time=1218.198 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=55 ttl=43 time=1030.052 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=56 ttl=43 time=638.601 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=57 ttl=43 time=216.295 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=58 ttl=43 time=200.674 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=59 ttl=43 time=797.261 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=60 ttl=43 time=992.238 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=61 ttl=43 time=1696.089 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=62 ttl=43 time=1139.896 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=63 ttl=43 time=588.823 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=64 ttl=43 time=663.070 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=65 ttl=43 time=782.507 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=66 ttl=43 time=426.705 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=67 ttl=43 time=220.192 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=68 ttl=43 time=228.405 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=69 ttl=43 time=130.555 ms
> > 64 bytes from 8.8.8.8 <http://8.8.8.8/>: icmp_seq=70 ttl=43 time=210.779 ms
> >
> > -Aaron
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net <mailto:Bloat@lists.bufferbloat.net>
> > https://lists.bufferbloat.net/listinfo/bloat <https://lists.bufferbloat.net/listinfo/bloat>
> >
>
>
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org <http://blog.cerowrt.org/>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net <mailto:Bloat@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/bloat <https://lists.bufferbloat.net/listinfo/bloat>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net <mailto:Bloat@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinfo/bloat <https://lists.bufferbloat.net/listinfo/bloat>
[-- Attachment #2: Type: text/html, Size: 18762 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bloat] I have a new record for bloat
2017-02-11 9:04 ` Neil Davies
@ 2017-02-11 18:24 ` Dave Taht
2017-03-31 22:07 ` Alex Burr
1 sibling, 0 replies; 9+ messages in thread
From: Dave Taht @ 2017-02-11 18:24 UTC (permalink / raw)
To: Neil Davies; +Cc: bloat, Jim Gettys
On Sat, Feb 11, 2017 at 1:04 AM, Neil Davies <neil.davies@pnsol.com> wrote:
> We’ve measured timings like this on many 3GPP based systems in various
> countries.
>
> It is an interaction between the radio link protocol, other parts of the
> 3GPP data path and way
> in which such devices are integrated with the operating system (even in
> iOS), it is
> not about the quantity of buffers but more the protocol interactions during
> times of stress on the
> radio bearer and/or during handover.
Meh. On a handover - with less buffering - packet lossage would barely
bother anyone.
> There are protocol configuration options, different design objectives and
> operational management
> mechanisms they _could_ use, but there is no incentive for the cellular
> operators to invest the
> time and effort to investigate and resolve.
At one level this lets ISPs continue to be necessary for good network
performance, and a way for them to differniate themselves from the
cellular folk. (if they were listening, also)
At least a few within the celluar industry are listening - apparently
NEC wasn't, but Dirk, here, just moved onto Huawei....
http://dirk-kutscher.info/posts/5g-its-the-network-stupid/
> The same mindset that created these sort of performance artefacts is also
> driving changes in DSL
> standards, so watch out for these sort of artefacts (again induced by things
> that you have no direct
> control over) starting to occur in “high speed” DSL systems (such as VDSL)
> when conditions are less
> than perfect.
I am extremely grumpy that despite the general availability of the
BQL[1] technique (less than 50 lines of code!) for managing
ring-buffers simply in firmware designed to operate at a range of
configured speeds... *especially* including both old style and modern
DSL chipsets...
only free.fr has actually implemented something like it. 3 months
after we shipped fq_codel. in 2012.
[1] https://lwn.net/Articles/454390/
It's in all the major ethernet drivers now, at least.
> Neil
>
> On 31 Jan 2017, at 20:42, Jim Gettys <jg@freedesktop.org> wrote:
>
>
>
> On Tue, Jan 31, 2017 at 3:13 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> On Tue, Jan 31, 2017 at 12:02 PM, Aaron Wood <woody77@gmail.com> wrote:
>> > This is wifi tethering from my OSX laptop to my iPhone, right after the
>> > laptop tried to reconnect to the iphone after waking up.
>> >
>> > 64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=42907.196 ms
>>
>> Not even close for the record as we got something like 800 seconds out
>> of gogo-in-flight. But as for wifi + tethering, you "win", I guess.
>
>
> I measured GoGo a couple years ago at about 740 seconds(!).
>
> IIRC, we've seen some other cellular systems with bloat at >60 seconds.
>
> I don't understand what I'm seeing at the moment on my Pixel XL on T-Mobile
> (upstream). I need to retake the data and post it along with the qdisc
> structure on current Android, for people to mull over.
> - Jim
>>
>>
>> > 64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=41922.290 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=40971.714 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=39967.402 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=38964.115 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=37986.640 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=37026.309 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=7 ttl=56 time=36073.683 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=8 ttl=56 time=35075.141 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=17 ttl=56 time=26273.867 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=18 ttl=56 time=25268.726 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=19 ttl=56 time=24270.618 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=20 ttl=56 time=23269.550 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=21 ttl=56 time=22265.406 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=22 ttl=56 time=21264.648 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=23 ttl=56 time=20305.022 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=24 ttl=56 time=19316.740 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=26 ttl=56 time=17310.953 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=25 ttl=56 time=18316.163 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=27 ttl=56 time=16320.196 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=28 ttl=56 time=15409.592 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=29 ttl=56 time=14411.919 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=30 ttl=56 time=13505.362 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=31 ttl=56 time=12505.893 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=32 ttl=56 time=11502.744 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=33 ttl=56 time=10501.390 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=34 ttl=56 time=9560.551 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=35 ttl=56 time=8566.430 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=36 ttl=56 time=7570.286 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=37 ttl=56 time=6588.928 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=38 ttl=56 time=5643.342 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=39 ttl=56 time=4639.435 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=40 ttl=56 time=3722.169 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=41 ttl=56 time=2719.881 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=42 ttl=56 time=1806.913 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=43 ttl=56 time=1218.198 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=55 ttl=43 time=1030.052 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=56 ttl=43 time=638.601 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=57 ttl=43 time=216.295 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=58 ttl=43 time=200.674 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=59 ttl=43 time=797.261 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=60 ttl=43 time=992.238 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=61 ttl=43 time=1696.089 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=62 ttl=43 time=1139.896 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=63 ttl=43 time=588.823 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=64 ttl=43 time=663.070 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=65 ttl=43 time=782.507 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=66 ttl=43 time=426.705 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=67 ttl=43 time=220.192 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=68 ttl=43 time=228.405 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=69 ttl=43 time=130.555 ms
>> > 64 bytes from 8.8.8.8: icmp_seq=70 ttl=43 time=210.779 ms
>> >
>> > -Aaron
>> >
>> > _______________________________________________
>> > Bloat mailing list
>> > Bloat@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/bloat
>> >
>>
>>
>>
>> --
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> http://blog.cerowrt.org
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>
--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bloat] I have a new record for bloat
2017-02-11 9:04 ` Neil Davies
2017-02-11 18:24 ` Dave Taht
@ 2017-03-31 22:07 ` Alex Burr
2017-04-01 4:05 ` Dave Täht
1 sibling, 1 reply; 9+ messages in thread
From: Alex Burr @ 2017-03-31 22:07 UTC (permalink / raw)
To: bloat
On Saturday, February 11, 2017 9:05 AM, Neil Davies <neil.davies@pnsol.com> wrote:
> The same mindset that created these sort of performance artefacts is also driving changes in DSL
> standards, so watch out for these sort of artefacts (again induced by things that you have no direct
> control over) starting to occur in “high speed” DSL systems (such as VDSL) when conditions are less
> than perfect.
Are you referring to G.998.4? That's supposed to introduce a max of 63ms delay. But it's been a while since I was involved in DSL, so maybe it's something new...
Alex
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bloat] I have a new record for bloat
2017-03-31 22:07 ` Alex Burr
@ 2017-04-01 4:05 ` Dave Täht
0 siblings, 0 replies; 9+ messages in thread
From: Dave Täht @ 2017-04-01 4:05 UTC (permalink / raw)
To: bloat
On 3/31/17 3:07 PM, Alex Burr wrote:
>
>
>
>
> On Saturday, February 11, 2017 9:05 AM, Neil Davies <neil.davies@pnsol.com> wrote:
>
>
>> The same mindset that created these sort of performance artefacts is also driving changes in DSL
>> standards, so watch out for these sort of artefacts (again induced by things that you have no direct
>> control over) starting to occur in “high speed” DSL systems (such as VDSL) when conditions are less
>
>> than perfect.
>
> Are you referring to G.998.4? That's supposed to introduce a max of 63ms delay. But it's been a while since I was involved in DSL, so maybe it's something new...
It's not the encoding, it's the queuing. Unless they also adopt
something like "bql" in their ring buffers in their firmware, and
something like fq_codel slightly above that, under distant conditions or
when rate limited by the provider, they new stuff will bloat up.
>
> Alex
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-04-01 4:05 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-31 20:02 [Bloat] I have a new record for bloat Aaron Wood
2017-01-31 20:13 ` Dave Taht
2017-01-31 20:22 ` Dave Taht
2017-01-31 20:30 ` Toke Høiland-Jørgensen
2017-01-31 20:42 ` Jim Gettys
2017-02-11 9:04 ` Neil Davies
2017-02-11 18:24 ` Dave Taht
2017-03-31 22:07 ` Alex Burr
2017-04-01 4:05 ` Dave Täht
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox