[Bloat] delay-under-load really helps diagnose real world problems

[Bloat] delay-under-load really helps diagnose real world problems

[Bill Ver Steeg (versteb)]

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

So, I have been suffering from pseudo-random performance problems for several months. I tend to travel quite a bit, and use VPNs from several networks. I occasionally suffer from crappy web performance, but the old tools did not provide much useful info. My un-VPNed network speeds were x (where x was site specific and typically about 60 Mbps) and my VPN-ed speed were about 50 Mbps.

It seems that at one site I had occasional web surfing and Webex problems when not on the VPN, but when I got on the VPN from the same site it was OK.

At a different site, I had the opposite problem. I had sporadic problems on the raw network, but seemed to run OK on the VPN.

Well, running the new DSLReports cleared it right up. On the site where I had problems on the raw network, the report said I had ~60 Mbps of throughput - but my delay under load spiked as high as several seconds. When I fired up the VPN, the VPN became the bottleneck link at ~50 Mbps. The VPN had reasonable (not great , but reasonable) buffer sizes, and my delay was ~150ms.

On the site where I had problems on the VPN but the raw network ran OK, I found that the 50 Mbps VPN introduced several seconds of delay under load. It looks like the PoP that I use in that geography has something misconfigured with a huge buffer, and I suffer bloat when it gets congested.

I am running these things down with the various owners, which should prove to be an interesting experience.......

So, hats off to Justin!

Bill VerSteeg

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

Re: [Bloat] delay-under-load really helps diagnose real world problems

[Matthew Ford]

> On 23 Apr 2015, at 22:55, Bill Ver Steeg (versteb) <versteb@cisco.com> wrote:
> 
> So, hats off to Justin!

A big +1 to what Bill said from me. This tool is great and has already helped me improve my own home network setup.

A colleague noted that selecting ‘Public WiFi’ as connection type results in no bloat measurements. Which connection types are bloat measurements enabled for? What’s the plan for the others?

Mat

Re: [Bloat] delay-under-load really helps diagnose real world problems

[jb]

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

I have made the following changes a few hours ago:

Bloat latency stats run on every connection now except GPRS and 3G
if you don't seem them during the test (mobile), they should be there
afterwards.

Download phase waits for quiescent latency measurements, defined by
less than 2x the lowest ping seen, or it simply gives up waiting and
continues.

The flow stats table has combined stats per server, so the megabit per
stream are
summed and the other measurements are averaged. I'm not entirely trusting
of the RTT and RTT Variance numbers from Linux, they come from the TCP_INFO
structure but are probably heavily biased to the end of the connection
rather
than the entire connection. However the re-transmits are definitely ok and
the
congestion window packet count looks about right too.

that's it..


On Sat, Apr 25, 2015 at 12:58 AM, Matthew Ford <ford@isoc.org> wrote:

>
> > On 23 Apr 2015, at 22:55, Bill Ver Steeg (versteb) <versteb@cisco.com>
> wrote:
> >
> > So, hats off to Justin!
>
> A big +1 to what Bill said from me. This tool is great and has already
> helped me improve my own home network setup.
>
> A colleague noted that selecting ‘Public WiFi’ as connection type results
> in no bloat measurements. Which connection types are bloat measurements
> enabled for? What’s the plan for the others?
>
> Mat
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

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

Re: [Bloat] delay-under-load really helps diagnose real world problems

[Simon Barber]

I ran some tests from my cellphone - a Samsung Note 3. I had to select 
'request desktop site' as an option in the chrome browser, and not 
choose '4G' as my connection type (I chose DSL), to get the latency 
measurement to show up. The results are great though.

http://www.dslreports.com/speedtest/355893

Download bloat (buffer in the cell site) is bad, but not absolutely 
horrible, at about 1.1 seconds. Upload direction is terrible - 5.8 
seconds by the end of the test, and would probably have been higher 
given a longer test. I'm assuming that this buffer is in the modem in 
the handset, and is likely an almost infinite buffer.

Simon

On 4/24/2015 7:58 AM, Matthew Ford wrote:
>> On 23 Apr 2015, at 22:55, Bill Ver Steeg (versteb) <versteb@cisco.com> wrote:
>>
>> So, hats off to Justin!
> A big +1 to what Bill said from me. This tool is great and has already helped me improve my own home network setup.
>
> A colleague noted that selecting ‘Public WiFi’ as connection type results in no bloat measurements. Which connection types are bloat measurements enabled for? What’s the plan for the others?
>
> Mat
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] delay-under-load really helps diagnose real world problems

[jb]

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

Apologies, it is sorted. Try now on mobile. There is a new box coloured
purple!

Multiple issues, main one being the Highcharts charting js plugin is quite
heavy at 200kb, so I am opting to not use it for the results page on mobile
at least not yet. Perhaps if one is on 4G I should not worry,.

However now, either way, the response is displayed during the test (in the
purple box) and also stored.
So viewing past tests in desktop mode still shows everything.


On Sat, Apr 25, 2015 at 12:56 PM, Simon Barber <simon@superduper.net> wrote:

> I ran some tests from my cellphone - a Samsung Note 3. I had to select
> 'request desktop site' as an option in the chrome browser, and not choose
> '4G' as my connection type (I chose DSL), to get the latency measurement to
> show up. The results are great though.
>
> http://www.dslreports.com/speedtest/355893
>
> Download bloat (buffer in the cell site) is bad, but not absolutely
> horrible, at about 1.1 seconds. Upload direction is terrible - 5.8 seconds
> by the end of the test, and would probably have been higher given a longer
> test. I'm assuming that this buffer is in the modem in the handset, and is
> likely an almost infinite buffer.
>
> Simon
>
>
> On 4/24/2015 7:58 AM, Matthew Ford wrote:
>
>> On 23 Apr 2015, at 22:55, Bill Ver Steeg (versteb) <versteb@cisco.com>
>>> wrote:
>>>
>>> So, hats off to Justin!
>>>
>> A big +1 to what Bill said from me. This tool is great and has already
>> helped me improve my own home network setup.
>>
>> A colleague noted that selecting ‘Public WiFi’ as connection type results
>> in no bloat measurements. Which connection types are bloat measurements
>> enabled for? What’s the plan for the others?
>>
>> Mat
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>
>

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

Re: [Bloat] delay-under-load really helps diagnose real world problems

[Simon Barber]

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

This is a great tool. Just ran another test from my cell, this time not 
selecting the 'desktop'  mode, and choosing 4G as my access method.  
Similar results to the last one.

http://www.dslreports.com/speedtest/359928

Perhaps on the mobile platforms you could include a button on the results 
page to show the latency graph, but not actually load it until the button 
is pressed.

Simon

Sent with AquaMail for Android
http://www.aqua-mail.com


On April 24, 2015 9:13:12 PM jb <justin@dslr.net> wrote:

> Apologies, it is sorted. Try now on mobile. There is a new box coloured
> purple!
>
> Multiple issues, main one being the Highcharts charting js plugin is quite
> heavy at 200kb, so I am opting to not use it for the results page on mobile
> at least not yet. Perhaps if one is on 4G I should not worry,.
>
> However now, either way, the response is displayed during the test (in the
> purple box) and also stored.
> So viewing past tests in desktop mode still shows everything.
>
>
> On Sat, Apr 25, 2015 at 12:56 PM, Simon Barber <simon@superduper.net> wrote:
>
> > I ran some tests from my cellphone - a Samsung Note 3. I had to select
> > 'request desktop site' as an option in the chrome browser, and not choose
> > '4G' as my connection type (I chose DSL), to get the latency measurement to
> > show up. The results are great though.
> >
> > http://www.dslreports.com/speedtest/355893
> >
> > Download bloat (buffer in the cell site) is bad, but not absolutely
> > horrible, at about 1.1 seconds. Upload direction is terrible - 5.8 seconds
> > by the end of the test, and would probably have been higher given a longer
> > test. I'm assuming that this buffer is in the modem in the handset, and is
> > likely an almost infinite buffer.
> >
> > Simon
> >
> >
> > On 4/24/2015 7:58 AM, Matthew Ford wrote:
> >
> >> On 23 Apr 2015, at 22:55, Bill Ver Steeg (versteb) <versteb@cisco.com>
> >>> wrote:
> >>>
> >>> So, hats off to Justin!
> >>>
> >> A big +1 to what Bill said from me. This tool is great and has already
> >> helped me improve my own home network setup.
> >>
> >> A colleague noted that selecting ‘Public WiFi’ as connection type results
> >> in no bloat measurements. Which connection types are bloat measurements
> >> enabled for? What’s the plan for the others?
> >>
> >> Mat
> >> _______________________________________________
> >> Bloat mailing list
> >> Bloat@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/bloat
> >>
> >
> >

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