* [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
