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/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