Re: [Bloat] T-Mobile LTE buffer bloat
On Thu, Oct 31, 2013 at 1:45 AM, Hal Murray wrote: > > > My personal record for a mobile network is 180 seconds RTT. They *really* > > *really* want to deliver the packets, and if the radio environment go bad > > they'll still buffer 400 packets (or so). > > I've seen 50 seconds on the big-bad-internet with no radio links. I assume > it was a link down and some box like my DSL modem didn't flush the queue > and/or didn't implement the corner of the RFC that says to bump the hop > count > every second.. > Heh. I've seen > 60 seconds, even on WiFi, in DC on Xfinity WiFi service. I've seen > 20 seconds over the Internet (but with a satellite link in the way) to Peru. Over the Acela wireless, I've seen > 90 seconds (their back haul is 3g or 4g, depending). > > I routinely see not-quite 4 seconds on the download side of a DSL link. > > > -- > These are my opinions. I hate spam. > > > > ___ > 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
Re: [Bloat] T-Mobile LTE buffer bloat
Also, it would be important to understand what radio access technology the LTE-WiFi-GW was really using at the time of the measurement. In hybrid GSM/UMTS/LTE networks (like T-Mobile's), mobile phones frequently fall back to GSM (GPRS), so you cannot blame LTE in this case. There are many myths around bufferbloat in mobile networks. You really need to understand the specifics of the network, its utilization at a given time -- and the deficiencies of the gear you are using. Having said that, in LTE there are apparently significant differences in latency (variation) depending on the operator and equipment vendor. For example, I have seen LTE measurements from hotspot areas in Tokyo that still looked much better (max 60 ms uplink delay) than what I hear sometimes from friends in the US. It's about time for structured measurement campaign that helps us to analyze this better. Best regards, Dirk > -Original Message- > From: bloat-boun...@lists.bufferbloat.net [mailto:bloat- > boun...@lists.bufferbloat.net] On Behalf Of Mikael Abrahamsson > Sent: Donnerstag, 31. Oktober 2013 01:02 > To: Stephen Hemminger > Cc: bloat@lists.bufferbloat.net > Subject: Re: [Bloat] T-Mobile LTE buffer bloat > > On Wed, 30 Oct 2013, Stephen Hemminger wrote: > > > There is zero configuration of proxy, it is just a LTE <-> wifi hotspot. > > I suspect some caching (or commercial interest) at their end. > > I have no insight in how T-Moble does things, but I know that vendors pitch > video/image compression stuff and you want to put it *before* it goes out > the radio network (because that's the expensive resource), so that's why my > guess it's doing the image-rewriting not in the end user box, but in a > centrally > placed device in their network. > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > ___ > 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
Re: [Bloat] T-Mobile LTE buffer bloat
> My personal record for a mobile network is 180 seconds RTT. They *really* > *really* want to deliver the packets, and if the radio environment go bad > they'll still buffer 400 packets (or so). I've seen 50 seconds on the big-bad-internet with no radio links. I assume it was a link down and some box like my DSL modem didn't flush the queue and/or didn't implement the corner of the RFC that says to bump the hop count every second.. I routinely see not-quite 4 seconds on the download side of a DSL link. -- These are my opinions. I hate spam. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] T-Mobile LTE buffer bloat
On Thu, Oct 31, 2013 at 03:04:23AM +0100, Stefan Alfredsson wrote: > Hi, Stephen, the list, > > We're running a 3G/4G measurement site at Karlstad university, with > mobile broadband subscriptions from the four major telecom operators > in Sweden. I was curious to see how measurements in our network > would compare to yours, so I did a measurement run with netalyzer. Groovy! Can I ask that you try something that can more likely stress out that bus than netanlyzer? The netperf-wrappers tools (notably the tcp_bidirectional and rrul test), use C, rather than java. There is a reasonably local-to-you netperf rrul server at demo.tohojo.dk. You can also easily setup a local one netanlyzer doesn't work well above 12Mbits, in particular. Netperf-wrappers works to 10GigE speeds. apt-get install python-matplotlib for that ubuntu version you will need to build netperf 2.6 from scratch, pulling it down from svn or it's website compiling with ./configure --enable-demo && make install git clone https://github.com/tohojo/netperf-wrapper.git cd netperf-wrapper sudo python setup.py install sample command line: netperf-wrapper -H demo.tohojo.dk -p all_scaled -o mymodem_name.svg \ -t "the modem I'm testing" --disable-log rrul > > To summarize, the measured buffering is well below one second for > all tests, although the results are not directly comparable since we > are using directly attached USB modems (Huawei E392 with Ubuntu > 12.04) ubuntu has backported fq_codel as far as 12.04. What kernel are you using? > instead of a separate router box. However, the numbers might > be interesting in a more general perspective. Yes, they are. These are repeatable? I don't consider "less than 1 second" to be "good". 5ms is good. At 250ms seems to be where stuff starts to break... > > Tele2 LTE: Upload 12 Mbit/s, 240 ms buffering, Download > 20 > Mbit/s, buffering not measurable > http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-6593-7f837e62-5321-488e-b480 > > Tele2 HSPA+: Upload 1.1 Mbit/s, 630 ms buffering, Download > 20 > Mbit/s, 509 ms buffering > http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-23052-a0e80cbb-9a7c-44e0-ba88 You'll note here that the buffering goes up as the bandwidth goes down. This is the inverse of the desired result. > > Telenor LTE: Upload 16 Mbit/s, 190 ms buffering, Download >20 > Mbit/s, 470 ms buffering > http://n3.netalyzr.icsi.berkeley.edu/summary/id=36ea240d-31617-45bca5e3-53ef-450e-a9bf > > Telenor HSPA+: Upload 3.4 Mbit/s, 200 ms buffering, Download > 14 > Mbit/s, 490 ms buffering > http://n3.netalyzr.icsi.berkeley.edu/summary/id=36ea240d-31612-c6d0d98d-8bcf-4a03-832d > > Telia LTE: Upload 18 Mbit/s, 140 ms buffering, Download > 20 Mbit/s, > buffering not measurable > http://n3.netalyzr.icsi.berkeley.edu/summary/id=36ea240d-31599-1ebc684e-c164-4786-832a > > Telia HSPA+: Upload 1.1 Mbit/s, 630 ms buffering, Download > 20 > Mbit/s, 640 ms buffering > http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-22984-40c59ae2-0c36-4e67-9039 > (note similarity with Tele2 HSPA+ - IIUC Tele2 and Telia share the > 3G network infrastructure) > > Tre LTE: Upload 19 Mbit/s, 150 ms buffering, Download > 20 Mbit/s, > 98 ms buffering > http://n3.netalyzr.icsi.berkeley.edu/summary/id=36ea240d-31648-86a273a5-82ae-4929-a634 > > Tre HSPA+: Upload 3.5 Mbit/s, 190 ms buffering, Download > 8.6 > Mbit/s, 780 ms buffering > http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-6609-3316da33-9ea6-41ca-a8ac > > > For reference, I also made a measurement from the same host, but > using a wired connection over the Swedish university network: Upload > was measured to > 20 Mbit/s and download to 15 Mbit/s, with no > measurable buffering. > http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-6563-078896ce-dc0a-4333-9119 That was kind of my point. Netanyzler has issues at higher speeds. Please give the rrul test a shot. > > > Regards, > Stefan Alfredsson > > > > On 10/31/13 00:25 , Stephen Hemminger wrote: > >I got one of these Samsung LTE hotspot. > >Not surprisingly it has huge bloat and a stupid http proxy > >that netalyzer claims rewrites images. > >Bandwidth: Up 1.6 Mbit/sec Down 4.3Mbit/sec > >Latency: 140ms 0% loss > >Buffering: Uplink 5100ms Down 1800ms > > > >How can the uplink side be so bad! 5 seconds??? > > > >Might even return it as defective. You can't even add a review on their > >website. Probably they would end taking down like Apple. > >___ > >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 ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] T-Mobile LTE buffer bloat
Hi, Stephen, the list, We're running a 3G/4G measurement site at Karlstad university, with mobile broadband subscriptions from the four major telecom operators in Sweden. I was curious to see how measurements in our network would compare to yours, so I did a measurement run with netalyzer. To summarize, the measured buffering is well below one second for all tests, although the results are not directly comparable since we are using directly attached USB modems (Huawei E392 with Ubuntu 12.04) instead of a separate router box. However, the numbers might be interesting in a more general perspective. Tele2 LTE: Upload 12 Mbit/s, 240 ms buffering, Download > 20 Mbit/s, buffering not measurable http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-6593-7f837e62-5321-488e-b480 Tele2 HSPA+: Upload 1.1 Mbit/s, 630 ms buffering, Download > 20 Mbit/s, 509 ms buffering http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-23052-a0e80cbb-9a7c-44e0-ba88 Telenor LTE: Upload 16 Mbit/s, 190 ms buffering, Download >20 Mbit/s, 470 ms buffering http://n3.netalyzr.icsi.berkeley.edu/summary/id=36ea240d-31617-45bca5e3-53ef-450e-a9bf Telenor HSPA+: Upload 3.4 Mbit/s, 200 ms buffering, Download > 14 Mbit/s, 490 ms buffering http://n3.netalyzr.icsi.berkeley.edu/summary/id=36ea240d-31612-c6d0d98d-8bcf-4a03-832d Telia LTE: Upload 18 Mbit/s, 140 ms buffering, Download > 20 Mbit/s, buffering not measurable http://n3.netalyzr.icsi.berkeley.edu/summary/id=36ea240d-31599-1ebc684e-c164-4786-832a Telia HSPA+: Upload 1.1 Mbit/s, 630 ms buffering, Download > 20 Mbit/s, 640 ms buffering http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-22984-40c59ae2-0c36-4e67-9039 (note similarity with Tele2 HSPA+ - IIUC Tele2 and Telia share the 3G network infrastructure) Tre LTE: Upload 19 Mbit/s, 150 ms buffering, Download > 20 Mbit/s, 98 ms buffering http://n3.netalyzr.icsi.berkeley.edu/summary/id=36ea240d-31648-86a273a5-82ae-4929-a634 Tre HSPA+: Upload 3.5 Mbit/s, 190 ms buffering, Download > 8.6 Mbit/s, 780 ms buffering http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-6609-3316da33-9ea6-41ca-a8ac For reference, I also made a measurement from the same host, but using a wired connection over the Swedish university network: Upload was measured to > 20 Mbit/s and download to 15 Mbit/s, with no measurable buffering. http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-6563-078896ce-dc0a-4333-9119 Regards, Stefan Alfredsson On 10/31/13 00:25 , Stephen Hemminger wrote: I got one of these Samsung LTE hotspot. Not surprisingly it has huge bloat and a stupid http proxy that netalyzer claims rewrites images. Bandwidth: Up 1.6 Mbit/sec Down 4.3Mbit/sec Latency: 140ms 0% loss Buffering: Uplink 5100ms Down 1800ms How can the uplink side be so bad! 5 seconds??? Might even return it as defective. You can't even add a review on their website. Probably they would end taking down like Apple. ___ 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
Re: [Bloat] T-Mobile LTE buffer bloat
>> >> My personal record for a mobile network is 180 seconds RTT. They *really* >> *really* want to deliver the packets, and if the radio environment go bad >> they'll still buffer 400 packets (or so). > > Darn. You win. The worst I've seen is 84 seconds. > Here's a ping trace from t-mobile when there was a big music festival a block from my apartment. 122 seconds (but zero loss), before I get disconnected. PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=46 time=46656.509 ms 64 bytes from 8.8.8.8: seq=1 ttl=46 time=47046.226 ms 64 bytes from 8.8.8.8: seq=2 ttl=46 time=47210.621 ms 64 bytes from 8.8.8.8: seq=3 ttl=46 time=46300.097 ms 64 bytes from 8.8.8.8: seq=4 ttl=46 time=46490.259 ms 64 bytes from 8.8.8.8: seq=5 ttl=46 time=45543.573 ms 64 bytes from 8.8.8.8: seq=6 ttl=46 time=44610.118 ms 64 bytes from 8.8.8.8: seq=7 ttl=46 time=43659.564 ms 64 bytes from 8.8.8.8: seq=8 ttl=46 time=42677.023 ms 64 bytes from 8.8.8.8: seq=9 ttl=46 time=41747.164 ms 64 bytes from 8.8.8.8: seq=10 ttl=46 time=40834.181 ms 64 bytes from 8.8.8.8: seq=11 ttl=46 time=39834.719 ms 64 bytes from 8.8.8.8: seq=12 ttl=46 time=38898.367 ms 64 bytes from 8.8.8.8: seq=13 ttl=46 time=37966.098 ms 64 bytes from 8.8.8.8: seq=14 ttl=46 time=38126.381 ms 64 bytes from 8.8.8.8: seq=15 ttl=46 time=37173.727 ms 64 bytes from 8.8.8.8: seq=16 ttl=46 time=37393.522 ms 64 bytes from 8.8.8.8: seq=17 ttl=46 time=36405.295 ms 64 bytes from 8.8.8.8: seq=18 ttl=46 time=35495.237 ms 64 bytes from 8.8.8.8: seq=19 ttl=46 time=34522.977 ms 64 bytes from 8.8.8.8: seq=20 ttl=46 time=35750.939 ms 64 bytes from 8.8.8.8: seq=21 ttl=46 time=40660.576 ms 64 bytes from 8.8.8.8: seq=22 ttl=46 time=39730.537 ms 64 bytes from 8.8.8.8: seq=23 ttl=46 time=38730.503 ms 64 bytes from 8.8.8.8: seq=24 ttl=46 time=37804.354 ms 64 bytes from 8.8.8.8: seq=25 ttl=46 time=36819.838 ms 64 bytes from 8.8.8.8: seq=26 ttl=46 time=37153.646 ms 64 bytes from 8.8.8.8: seq=27 ttl=46 time=37413.711 ms 64 bytes from 8.8.8.8: seq=28 ttl=46 time=37581.268 ms 64 bytes from 8.8.8.8: seq=29 ttl=46 time=37733.075 ms 64 bytes from 8.8.8.8: seq=30 ttl=46 time=40190.826 ms 64 bytes from 8.8.8.8: seq=31 ttl=46 time=101158.557 ms 64 bytes from 8.8.8.8: seq=32 ttl=46 time=101264.386 ms 64 bytes from 8.8.8.8: seq=33 ttl=46 time=103640.134 ms 64 bytes from 8.8.8.8: seq=34 ttl=46 time=103819.819 ms 64 bytes from 8.8.8.8: seq=35 ttl=46 time=103958.008 ms 64 bytes from 8.8.8.8: seq=36 ttl=46 time=104057.496 ms 64 bytes from 8.8.8.8: seq=37 ttl=46 time=103081.290 ms 64 bytes from 8.8.8.8: seq=38 ttl=46 time=103191.206 ms 64 bytes from 8.8.8.8: seq=39 ttl=46 time=107700.964 ms 64 bytes from 8.8.8.8: seq=40 ttl=46 time=107818.726 ms 64 bytes from 8.8.8.8: seq=41 ttl=46 time=106833.938 ms 64 bytes from 8.8.8.8: seq=42 ttl=46 time=107042.706 ms 64 bytes from 8.8.8.8: seq=43 ttl=46 time=110530.331 ms 64 bytes from 8.8.8.8: seq=44 ttl=46 time=115255.932 ms 64 bytes from 8.8.8.8: seq=45 ttl=46 time=121191.910 ms 64 bytes from 8.8.8.8: seq=46 ttl=46 time=120217.588 ms 64 bytes from 8.8.8.8: seq=47 ttl=46 time=120653.489 ms 64 bytes from 8.8.8.8: seq=48 ttl=46 time=122025.125 ms ping: sendto: Network is unreachable ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] T-Mobile LTE buffer bloat
On Wed, 30 Oct 2013, Michael Richardson wrote: What about the other ports and things? I wonder if the image rewriting causes additional bloat... I don't really see it causing additional bloat. It might cause additional delays (the device there needs to fetch the image, recode it, and then serve it to the requesting client), but since the data is now hopefully smaller, it shouldn't cause additional buffering. Guess it comes down to how you define "bloat". -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] T-Mobile LTE buffer bloat
I agree with others that the image rewriting/compression is likely a network "service". What about the other ports and things? I wonder if the image rewriting causes additional bloat... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] T-Mobile LTE buffer bloat
On Wed, 30 Oct 2013, Stephen Hemminger wrote: There is zero configuration of proxy, it is just a LTE <-> wifi hotspot. I suspect some caching (or commercial interest) at their end. I have no insight in how T-Moble does things, but I know that vendors pitch video/image compression stuff and you want to put it *before* it goes out the radio network (because that's the expensive resource), so that's why my guess it's doing the image-rewriting not in the end user box, but in a centrally placed device in their network. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] T-Mobile LTE buffer bloat
On Thu, 31 Oct 2013 00:34:12 +0100 (CET) Mikael Abrahamsson wrote: > On Wed, 30 Oct 2013, Stephen Hemminger wrote: > > > Not surprisingly it has huge bloat and a stupid http proxy that > > netalyzer claims rewrites images. > > This could be done in the provider network, did you try it without the > thingie? There is zero configuration of proxy, it is just a LTE <-> wifi hotspot. I suspect some caching (or commercial interest) at their end. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] T-Mobile LTE buffer bloat
On Wed, Oct 30, 2013 at 4:34 PM, Mikael Abrahamsson wrote: > On Wed, 30 Oct 2013, Stephen Hemminger wrote: > >> Not surprisingly it has huge bloat and a stupid http proxy that netalyzer >> claims rewrites images. > > > This could be done in the provider network, did you try it without the > thingie? > > >> How can the uplink side be so bad! 5 seconds??? > > > My personal record for a mobile network is 180 seconds RTT. They *really* > *really* want to deliver the packets, and if the radio environment go bad > they'll still buffer 400 packets (or so). Darn. You win. The worst I've seen is 84 seconds. > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > > ___ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] T-Mobile LTE buffer bloat
On Wed, 30 Oct 2013, Stephen Hemminger wrote: Not surprisingly it has huge bloat and a stupid http proxy that netalyzer claims rewrites images. This could be done in the provider network, did you try it without the thingie? How can the uplink side be so bad! 5 seconds??? My personal record for a mobile network is 180 seconds RTT. They *really* *really* want to deliver the packets, and if the radio environment go bad they'll still buffer 400 packets (or so). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] T-Mobile LTE buffer bloat
I got one of these Samsung LTE hotspot. Not surprisingly it has huge bloat and a stupid http proxy that netalyzer claims rewrites images. Bandwidth: Up 1.6 Mbit/sec Down 4.3Mbit/sec Latency: 140ms 0% loss Buffering: Uplink 5100ms Down 1800ms How can the uplink side be so bad! 5 seconds??? Might even return it as defective. You can't even add a review on their website. Probably they would end taking down like Apple. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
