[Bloat] bufferbloat at high edge rates

[Bloat] bufferbloat at high edge rates

[Dave Taht]

I do keep hoping it's really the browsers misbehaving.

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


-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Bloat] bufferbloat at high edge rates

[Kathleen Nichols]

My measurements are showing those kinds of delays are in the client
network but I don't know enough about this set up to know what's
going on.

If anyone is interested, I'm talking about some recent measurements at
the IRTG MAPRG meeting that is Thursday morning Korea time. I'm
guessing there's not much interest though since I had no comments on the
previous measurements though a fair number of people downloaded my
writeup.

	Kathie


On 11/14/16 11:02 AM, Dave Taht wrote:
> I do keep hoping it's really the browsers misbehaving.
> 
> http://www.dslreports.com/speedtest/6054627
> 
> 

Re: [Bloat] bufferbloat at high edge rates

[Dave Taht]

On Mon, Nov 14, 2016 at 12:06 PM, Kathleen Nichols <nichols@pollere.com> wrote:
>
> My measurements are showing those kinds of delays are in the client
> network but I don't know enough about this set up to know what's
> going on.
>
> If anyone is interested, I'm talking about some recent measurements at
> the IRTG MAPRG meeting that is Thursday morning Korea time. I'm
> guessing there's not much interest though since I had no comments on the
> prevn fus measurements though a fair number of people downloaded my
> writeup.

Well, getting in front of an audience always helps.

Break a leg! (and please post a link to the video and slides when done!)

>         Kathie
>
>
> On 11/14/16 11:02 AM, Dave Taht wrote:
>> I do keep hoping it's really the browsers misbehaving.
>>
>> http://www.dslreports.com/speedtest/6054627
>>
>>
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Bloat] bufferbloat at high edge rates

[jb]

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

Yeah sorry the forum software zipped up the attachment and thus loses the
executable permission flags. I'll attach zips to the post instead which I
think will fix that.


file *amd64

dslrcli-darwin-amd64:  Mach-O 64-bit executable x86_64

dslrcli-freebsd-amd64: ELF 64-bit LSB executable, x86-64, version 1
(FreeBSD), statically linked, not stripped

dslrcli-linux-amd64:   ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
statically linked, not stripped

dslrcli-netbsd-amd64:  ELF 64-bit LSB executable, x86-64, version 1
(NetBSD), statically linked, for NetBSD 5.99, not stripped


On Wed, Nov 16, 2016 at 3:22 AM, Dave Taht <dave.taht@gmail.com> wrote:

> On Mon, Nov 14, 2016 at 12:06 PM, Kathleen Nichols <nichols@pollere.com>
> wrote:
> >
> > My measurements are showing those kinds of delays are in the client
> > network but I don't know enough about this set up to know what's
> > going on.
> >
> > If anyone is interested, I'm talking about some recent measurements at
> > the IRTG MAPRG meeting that is Thursday morning Korea time. I'm
> > guessing there's not much interest though since I had no comments on the
> > prevn fus measurements though a fair number of people downloaded my
> > writeup.
>
> Well, getting in front of an audience always helps.
>
> Break a leg! (and please post a link to the video and slides when done!)
>
> >         Kathie
> >
> >
> > On 11/14/16 11:02 AM, Dave Taht wrote:
> >> I do keep hoping it's really the browsers misbehaving.
> >>
> >> http://www.dslreports.com/speedtest/6054627
> >>
> >>
> >
>
>
>
> --
> 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: 3729 bytes --]

Re: [Bloat] bufferbloat at high edge rates

[jb]

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

The command line tool is available to anyone now (Windows, OSX and linux),
it does buffer bloat probing, using ICMP if run as root, and is immune to
any browser issues. It can be downloaded here from the sticky:
   http://www.dslreports.com/forum/speedtestbinary

So the task remains to find someone with (a) 250+ megabit/second, (b)
showing bloat in the browser, and (c) is prepared to patiently verify it is
a real thing.


On Tue, Nov 15, 2016 at 6:02 AM, Dave Taht <dave.taht@gmail.com> wrote:

> I do keep hoping it's really the browsers misbehaving.
>
> http://www.dslreports.com/speedtest/6054627
>
>
> --
> 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: 1703 bytes --]

Re: [Bloat] bufferbloat at high edge rates

[Dave Taht]

On Mon, Nov 14, 2016 at 4:11 PM, jb <justin@dslr.net> wrote:
> The command line tool is available to anyone now (Windows, OSX and linux),
> it does buffer bloat probing, using ICMP if run as root, and is immune to
> any browser issues. It can be downloaded here from the sticky:
>    http://www.dslreports.com/forum/speedtestbinary
>
> So the task remains to find someone with (a) 250+ megabit/second, (b)
> showing bloat in the browser, and (c) is prepared to patiently verify it is
> a real thing.

As I am deeply respectful of cultural differences, and yet often
ignorant of many of them, would my appropriate behavior in australia
be:

A) Kisses on both cheeks?

B) A beercan bump?

C) A high five?

D) Throwing 10 lbs of shrimp on your barbie?

E) Something other than the above?



>
> On Tue, Nov 15, 2016 at 6:02 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> I do keep hoping it's really the browsers misbehaving.
>>
>> http://www.dslreports.com/speedtest/6054627
>>
>>
>> --
>> 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
>
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Bloat] bufferbloat at high edge rates

[Jonathan Morton]

> On 15 Nov, 2016, at 02:31, Dave Taht <dave.taht@gmail.com> wrote:
> 
> B) A beercan bump?

As a Pommie myself, I assume this would be most appropriate, given that it’s currently summer down there.

But I could be wrong…

 - Jonathan Morton

Re: [Bloat] bufferbloat at high edge rates

[James Cloos]

>>>>> "j" == jb  <justin@dslr.net> writes:

j> It can be downloaded here from the sticky:
j>    http://www.dslreports.com/forum/speedtestbinary

That links to:

 http://www.dslreports.com/r0/download/2293455~bc6f17b1568921811497422ad3fff3b5/dslrcli-linux-amd64.zip

but that just downloads a text file, not a zip file.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

Re: [Bloat] bufferbloat at high edge rates

[Jan Ceuleers]

On 15/11/16 16:23, James Cloos wrote:
>>>>>> "j" == jb  <justin@dslr.net> writes:
> 
> j> It can be downloaded here from the sticky:
> j>    http://www.dslreports.com/forum/speedtestbinary
> 
> That links to:
> 
>  http://www.dslreports.com/r0/download/2293455~bc6f17b1568921811497422ad3fff3b5/dslrcli-linux-amd64.zip
> 
> but that just downloads a text file, not a zip file.

Read that text file.

Re: [Bloat] bufferbloat at high edge rates

[David Lang]

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

On Tue, 15 Nov 2016, jb wrote:

> The command line tool is available to anyone now (Windows, OSX and linux),
> it does buffer bloat probing, using ICMP if run as root, and is immune to
> any browser issues. It can be downloaded here from the sticky:
>   http://www.dslreports.com/forum/speedtestbinary

This does not seem to be reporting any bloat info (I've run it a couple times)

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

David Lang

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] bufferbloat at high edge rates

[jb]

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

It has to run as root / Admin in order to do ICMP in order to test buffer
bloat.

If you run it under a non privileged user account it cannot get permission
for ICMP, so although it locates the nearest servers using http ping, it
isn't doing any buffer bloat testing.

I'm not sure that is the issue but that's the first thing that comes to
mind..


On Wed, Nov 16, 2016 at 11:34 AM, David Lang <david@lang.hm> wrote:

> On Tue, 15 Nov 2016, jb wrote:
>
> The command line tool is available to anyone now (Windows, OSX and linux),
>> it does buffer bloat probing, using ICMP if run as root, and is immune to
>> any browser issues. It can be downloaded here from the sticky:
>>   http://www.dslreports.com/forum/speedtestbinary
>>
>
> This does not seem to be reporting any bloat info (I've run it a couple
> times)
>
> http://www.dslreports.com/speedtest/6156013
>
> David Lang
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>

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

Re: [Bloat] bufferbloat at high edge rates

[Stefan Alfredsson]

I had the same problem, getting no bloat report. I tested just now 
running as root, and got bloat measurements in 
http://www.dslreports.com/speedtest/6166098 and 
http://www.dslreports.com/speedtest/6166295

 From Firefox, I get somewhat higer latency (~100 ms) versus ~20-60 ms 
via the command line client:

http://www.dslreports.com/speedtest/6130740
http://www.dslreports.com/speedtest/6130727
http://www.dslreports.com/speedtest/6130708
http://www.dslreports.com/speedtest/6130690


Two things to note:

- Firefox tests were run yesterday at around lunchtime  (~12.00 CET), 
and CLI tests just now (~06.40 CET). So time-of-day effect may be a 
reason for less bloat now. I'll do a better comparison when I get to my 
desktop.

- CLI tests were run in a docker container, for security purposes. I 
used host networking so it should not have affected measurements much, 
but still. This was how it was executed:


// downloaded the dslreports cli tool to my host /tmp directory, mapping 
/tmp to /host in the debian container

$ docker run --rm -t -i -v /tmp:/host:ro debian

root@db0ea060caa7:/# apt-get update ; apt-get install ca-certificates
[... snip ...]
root@db0ea060caa7:/# /host/dslrcli-linux-amd64
Selecting nearest servers....
Download Testing.....
Upload Testing.....
Uploading results...
Download : 883.56 Megabit/sec Upload : 895.32 Megabit/sec
http://www.dslreports.com/speedtest/6166098



A better option would be using CAP_NET_RAW, I'll see if this works 
instead of running with full root privs.

/Stefan



On 16/11/16 05:09, jb wrote:
> It has to run as root / Admin in order to do ICMP in order to test 
> buffer bloat.
>
> If you run it under a non privileged user account it cannot get 
> permission for ICMP, so although it locates the nearest servers using 
> http ping, it isn't doing any buffer bloat testing.
>
> I'm not sure that is the issue but that's the first thing that comes 
> to mind..
>
>
> On Wed, Nov 16, 2016 at 11:34 AM, David Lang <david@lang.hm 
> <mailto:david@lang.hm>> wrote:
>
>     On Tue, 15 Nov 2016, jb wrote:
>
>         The command line tool is available to anyone now (Windows, OSX
>         and linux),
>         it does buffer bloat probing, using ICMP if run as root, and
>         is immune to
>         any browser issues. It can be downloaded here from the sticky:
>         http://www.dslreports.com/forum/speedtestbinary
>         <http://www.dslreports.com/forum/speedtestbinary>
>
>
>     This does not seem to be reporting any bloat info (I've run it a
>     couple times)
>
>     http://www.dslreports.com/speedtest/6156013
>     <http://www.dslreports.com/speedtest/6156013>
>
>     David Lang
>     _______________________________________________
>     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
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] bufferbloat at high edge rates

[Stefan Alfredsson]

* Quoting Stefan Alfredsson <stefan.alfredsson@kau.se> [16 Nov-16 07:00]:
> - Firefox tests were run yesterday at around lunchtime  (~12.00 CET), and
> CLI tests just now (~06.40 CET). So time-of-day effect may be a reason for
> less bloat now. I'll do a better comparison when I get to my desktop.

I've done tests with CLI, Firefox and Chrome; repeated 3 times in
a round-robin fashion (cli, ff, chrome, cli, ff, chrome, cli, ff, chrome).

In summary:

- There is 5-10 ms additional latency during all tests.
- CLI and Chrome have the same latency figures, 23 ms base latency 
  Firefox has a base latency of 100 ms RTT, most likely due to US
  responders being used by Firefox and EU responders being used by CLI and Chrome.  
- Chrome achives 30-40 Mbps higher throughput than CLI.


Results from a standard Ubuntu Xenial system running kernel 4.4.0-45-generic #66-Ubuntu SMP Wed Oct 19 14:12:37 UTC 2016

Dslrcli version 0.1 - 15-Nov-2016
test 1 http://www.dslreports.com/speedtest/6169686
test 4 http://www.dslreports.com/speedtest/6169764
test 7 http://www.dslreports.com/speedtest/6169798


Firefox 49.0.2:
test 2 http://www.dslreports.com/speedtest/6169706
test 5 http://www.dslreports.com/speedtest/6169776
test 8 http://www.dslreports.com/speedtest/6169819


Google Chrome 54.0.2840.71
test 3 http://www.dslreports.com/speedtest/6169747
test 6 http://www.dslreports.com/speedtest/6169788
test 9 http://www.dslreports.com/speedtest/6169833



> A better option would be using CAP_NET_RAW, I'll see if this works instead
> of running with full root privs.

Yes, copying the binary to /usr/bin and setting cap_net_raw made it report bloat.
(sudo setcap cap_net_raw+ep /usr/bin/dslrcli-linux-amd64)

/Stefan

-- 
Stefan Alfredsson, PhD         Tel: +46 (0) 54 700 1668
Datavetenskap                  Kontor: 21E-414 (Hus Vanern)
Karlstads universitet          PGP 0xB19B4B16
SE-651 88 Karlstad             http://www.cs.kau.se/stefalfr/

Re: [Bloat] bufferbloat at high edge rates

[jb]

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

Hi Stefan,

The reason for the higher latency is the auto-selection of the servers, the
IP address you were on for the browser tests was for a reason I can't yet
work out, only offering US servers. It is surprising that you got a
gigabit, pretty much.

You can avoid this problem in the browser test by selecting manually, using
test preferences, only euro servers and it will use the nearest of those.

The command line test was pinging all 76 servers so it used euro ones.

So my reaction from your tests is that the in-brwser buffer bloat testing
is probably accurate even at high speeds and with the same servers,
probably returning the same measurement.

thanks
-Justin

On Wed, Nov 16, 2016 at 5:00 PM, Stefan Alfredsson <stefan.alfredsson@kau.se
> wrote:

> I had the same problem, getting no bloat report. I tested just now running
> as root, and got bloat measurements in http://www.dslreports.com/spee
> dtest/6166098 and http://www.dslreports.com/speedtest/6166295
>
> From Firefox, I get somewhat higer latency (~100 ms) versus ~20-60 ms via
> the command line client:
>
> http://www.dslreports.com/speedtest/6130740
> http://www.dslreports.com/speedtest/6130727
> http://www.dslreports.com/speedtest/6130708
> http://www.dslreports.com/speedtest/6130690
>
>
> Two things to note:
>
> - Firefox tests were run yesterday at around lunchtime  (~12.00 CET), and
> CLI tests just now (~06.40 CET). So time-of-day effect may be a reason for
> less bloat now. I'll do a better comparison when I get to my desktop.
>
> - CLI tests were run in a docker container, for security purposes. I used
> host networking so it should not have affected measurements much, but
> still. This was how it was executed:
>
>
> // downloaded the dslreports cli tool to my host /tmp directory, mapping
> /tmp to /host in the debian container
>
> $ docker run --rm -t -i -v /tmp:/host:ro debian
>
> root@db0ea060caa7:/# apt-get update ; apt-get install ca-certificates
> [... snip ...]
> root@db0ea060caa7:/# /host/dslrcli-linux-amd64
> Selecting nearest servers....
> Download Testing.....
> Upload Testing.....
> Uploading results...
> Download : 883.56 Megabit/sec Upload : 895.32 Megabit/sec
> http://www.dslreports.com/speedtest/6166098
>
>
>
> A better option would be using CAP_NET_RAW, I'll see if this works instead
> of running with full root privs.
>
> /Stefan
>
>
>
> On 16/11/16 05:09, jb wrote:
>
>> It has to run as root / Admin in order to do ICMP in order to test buffer
>> bloat.
>>
>> If you run it under a non privileged user account it cannot get
>> permission for ICMP, so although it locates the nearest servers using http
>> ping, it isn't doing any buffer bloat testing.
>>
>> I'm not sure that is the issue but that's the first thing that comes to
>> mind..
>>
>>
>> On Wed, Nov 16, 2016 at 11:34 AM, David Lang <david@lang.hm <mailto:
>> david@lang.hm>> wrote:
>>
>>     On Tue, 15 Nov 2016, jb wrote:
>>
>>         The command line tool is available to anyone now (Windows, OSX
>>         and linux),
>>         it does buffer bloat probing, using ICMP if run as root, and
>>         is immune to
>>         any browser issues. It can be downloaded here from the sticky:
>>         http://www.dslreports.com/forum/speedtestbinary
>>         <http://www.dslreports.com/forum/speedtestbinary>
>>
>>
>>     This does not seem to be reporting any bloat info (I've run it a
>>     couple times)
>>
>>     http://www.dslreports.com/speedtest/6156013
>>     <http://www.dslreports.com/speedtest/6156013>
>>
>>     David Lang
>>     _______________________________________________
>>     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
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>
>
>
>

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

Re: [Bloat] bufferbloat at high edge rates

[David Lang]

I was running it as root via sudo

David Lang

On Wed, 16 Nov 2016, jb wrote:

> It has to run as root / Admin in order to do ICMP in order to test buffer
> bloat.
>
> If you run it under a non privileged user account it cannot get permission
> for ICMP, so although it locates the nearest servers using http ping, it
> isn't doing any buffer bloat testing.
>
> I'm not sure that is the issue but that's the first thing that comes to
> mind..
>
>
> On Wed, Nov 16, 2016 at 11:34 AM, David Lang <david@lang.hm> wrote:
>
>> On Tue, 15 Nov 2016, jb wrote:
>>
>> The command line tool is available to anyone now (Windows, OSX and linux),
>>> it does buffer bloat probing, using ICMP if run as root, and is immune to
>>> any browser issues. It can be downloaded here from the sticky:
>>>   http://www.dslreports.com/forum/speedtestbinary
>>>
>>
>> This does not seem to be reporting any bloat info (I've run it a couple
>> times)
>>
>> http://www.dslreports.com/speedtest/6156013
>>
>> David Lang
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>>
>

Re: [Bloat] bufferbloat at high edge rates

[jb]

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

Apparently there is not enough duration currently: there is actual buffer
bloat data in your results, but it is insufficient in quantity so the site
isn't bothering to show and interpret it. Can you try one run by extending
the duration of download and upload phases?

if that doesn't work I'll have to patch the binary to make sure there is
always enough, and upload a new one..

thanks

On Thu, Nov 17, 2016 at 7:54 AM, Colin Dearborn <Colin.Dearborn@sjrb.ca>
wrote:

> I just ran it on ubuntu 16.04.1 LTS, as root, and it did not store the
> bufferbloat, quality or speed grades.
>
> https://www.dslreports.com/speedtest/6186501
>
> https://www.dslreports.com/speedtest/6186425
>
>
>
> I do note that it ran these tests over my HE.net tunnel and there doesn’t
> seem to be an easy way to choose IPv6 vs IPv4 on the command line.
>
> Disabling the IPv6 tunnel, I still don’t see the grades:
>
> https://www.dslreports.com/speedtest/6187015
>
>
>
> ./dslrcli-linux-amd64 --version
>
> Dslrcli version 0.1 - 17-Nov-2016
>
>
>
> *From:* Bloat [mailto:bloat-bounces@lists.bufferbloat.net] *On Behalf Of *
> jb
> *Sent:* Tuesday, November 15, 2016 9:09 PM
> *To:* David Lang <david@lang.hm>
> *Cc:* bloat <bloat@lists.bufferbloat.net>
> *Subject:* Re: [Bloat] bufferbloat at high edge rates
>
>
>
> It has to run as root / Admin in order to do ICMP in order to test buffer
> bloat.
>
>
>
> If you run it under a non privileged user account it cannot get permission
> for ICMP, so although it locates the nearest servers using http ping, it
> isn't doing any buffer bloat testing.
>
>
>
> I'm not sure that is the issue but that's the first thing that comes to
> mind..
>
>
>
>
>
> On Wed, Nov 16, 2016 at 11:34 AM, David Lang <david@lang.hm> wrote:
>
> On Tue, 15 Nov 2016, jb wrote:
>
> The command line tool is available to anyone now (Windows, OSX and linux),
> it does buffer bloat probing, using ICMP if run as root, and is immune to
> any browser issues. It can be downloaded here from the sticky:
>   http://www.dslreports.com/forum/speedtestbinary
>
>
> This does not seem to be reporting any bloat info (I've run it a couple
> times)
>
> http://www.dslreports.com/speedtest/6156013
>
> David Lang
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>
>

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

Re: [Bloat] bufferbloat at high edge rates

[David Lang]

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

my run was on 16.10 and I extended both upload and download to 45 sec.

David Lang

On Thu, 17 Nov 2016, jb wrote:

> Date: Thu, 17 Nov 2016 11:16:27 +1100
> From: jb <justin@dslr.net>
> To: Colin Dearborn <Colin.Dearborn@sjrb.ca>
> Cc: bloat <bloat@lists.bufferbloat.net>
> Subject: Re: [Bloat] bufferbloat at high edge rates
> 
> Apparently there is not enough duration currently: there is actual buffer
> bloat data in your results, but it is insufficient in quantity so the site
> isn't bothering to show and interpret it. Can you try one run by extending
> the duration of download and upload phases?
>
> if that doesn't work I'll have to patch the binary to make sure there is
> always enough, and upload a new one..
>
> thanks
>
> On Thu, Nov 17, 2016 at 7:54 AM, Colin Dearborn <Colin.Dearborn@sjrb.ca>
> wrote:
>
>> I just ran it on ubuntu 16.04.1 LTS, as root, and it did not store the
>> bufferbloat, quality or speed grades.
>>
>> https://www.dslreports.com/speedtest/6186501
>>
>> https://www.dslreports.com/speedtest/6186425
>>
>>
>>
>> I do note that it ran these tests over my HE.net tunnel and there doesn’t
>> seem to be an easy way to choose IPv6 vs IPv4 on the command line.
>>
>> Disabling the IPv6 tunnel, I still don’t see the grades:
>>
>> https://www.dslreports.com/speedtest/6187015
>>
>>
>>
>> ./dslrcli-linux-amd64 --version
>>
>> Dslrcli version 0.1 - 17-Nov-2016
>>
>>
>>
>> *From:* Bloat [mailto:bloat-bounces@lists.bufferbloat.net] *On Behalf Of *
>> jb
>> *Sent:* Tuesday, November 15, 2016 9:09 PM
>> *To:* David Lang <david@lang.hm>
>> *Cc:* bloat <bloat@lists.bufferbloat.net>
>> *Subject:* Re: [Bloat] bufferbloat at high edge rates
>>
>>
>>
>> It has to run as root / Admin in order to do ICMP in order to test buffer
>> bloat.
>>
>>
>>
>> If you run it under a non privileged user account it cannot get permission
>> for ICMP, so although it locates the nearest servers using http ping, it
>> isn't doing any buffer bloat testing.
>>
>>
>>
>> I'm not sure that is the issue but that's the first thing that comes to
>> mind..
>>
>>
>>
>>
>>
>> On Wed, Nov 16, 2016 at 11:34 AM, David Lang <david@lang.hm> wrote:
>>
>> On Tue, 15 Nov 2016, jb wrote:
>>
>> The command line tool is available to anyone now (Windows, OSX and linux),
>> it does buffer bloat probing, using ICMP if run as root, and is immune to
>> any browser issues. It can be downloaded here from the sticky:
>>   http://www.dslreports.com/forum/speedtestbinary
>>
>>
>> This does not seem to be reporting any bloat info (I've run it a couple
>> times)
>>
>> http://www.dslreports.com/speedtest/6156013
>>
>> David Lang
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>>
>>
>

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat