Regarding
http://www.dslreports.com/speedtest/380810

The upload graph was broken, or partially so, because you're using Firefox/24.0 which dates from 2014 and apparently doesn't know how to feedback information on the upload so the measurement was done from each upload as it finished

So that is why the upload graph is no good, but the upload number is about right.

Also it did have stalls and drops but not too bad, not enough to trigger an error.
  46.98s 10hz drop stats frames=15 total ms=3985


On Tue, Apr 28, 2015 at 5:22 PM, Jesper Dangaard Brouer <brouer@redhat.com> wrote:

On Tue, 28 Apr 2015 10:03:48 +0300 Marko Myllynen <myllynen@redhat.com> wrote:

> On 2015-04-28 09:55, Jesper Dangaard Brouer wrote:
> >
> > Finally, there is a easy-to-use browser based speedtest that also
> > measures bufferbloat:
> >
> >  http://www.dslreports.com/speedtest
> >
> > After you run the test, click the green "Results + Share" button to see
> > more detailed information.  Which will contain a graph with "Ping
> > response under load", which will indicate if you have bufferbloat on
> > your link.
>
> FWIW, my results using RHEL 6 + Lenovo T420s + 4G modem:

Thanks - I'm surprised to see how well 4G handles this.  I was
expecting to see higher delays under load.

> http://www.dslreports.com/speedtest/380810

The upload graph looks a little strange.

> http://www.speedtest.net/my-result/4322094820
>
> Speedtest has servers in Finland so that might explain a bit. I was
> running two Fedora guest installations in the background during the
> tests so the system was rather busy.

Could you try to run this in a Chrome browser?
The author (Cc'ed) sayed Firefox on Linux is too slow...

--
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer