[Bloat] bufferbloat at high edge rates

[jb]

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 at 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 at db0ea060caa7:/# apt-get update ; apt-get install ca-certificates
> [... snip ...]
> root at 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 at lang.hm <mailto:
>> david at 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 at lists.bufferbloat.net <mailto:Bloat at lists.bufferbloat.net>
>>     https://lists.bufferbloat.net/listinfo/bloat
>>     <https://lists.bufferbloat.net/listinfo/bloat>
>>
>>
>>
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20161117/0ac42e89/attachment-0002.html>