It is a whole lot better than other ISPs.
55% are As and Bs
including Cs (which by the standard of most ISPs, is still decent)
take the total to 90% ..
On Sat, Jun 6, 2015 at 1:54 PM, Aaron Wood wrote:
> Huh, those results are rather different from mine when I had free.fr:
>
>
> http://burntch
Huh, those results are rather different from mine when I had free.fr:
http://burntchrome.blogspot.com/2014/01/bufferbloat-or-lack-thereof-on-freefr.html
-Aaron
On Fri, Jun 5, 2015 at 1:06 PM, Dave Taht wrote:
> 63% F bloat grade for
> http://www.dslreports.com/speedtest/results/isp/r3895-Orang
On 06/05/2015 05:32 PM, jb wrote:
It's supposed to be GPRS
but the graph library is not cooperating for a reason that I can't work
out at the moment.
Just a guess - doesn't like having something go past the left edge
perhaps? You could try swapping positions with G3 and see if that makes
thi
It's supposed to be GPRS
but the graph library is not cooperating for a reason that I can't work out
at the moment.
> Interesting stuff. What is that label to the left of "3G" meant to be?
It seems to show-up in the column charts for all countries.
On Sat, Jun 6, 2015 at 8:49 AM, Rick Jones wr
Feature requests: (in your copious spare time)
A) be able to break the bloat grade out up and down. as one example
free.fr has limited control on the down (their IPtv implementation
makes it impossible to fix), but total control on the up, and I
figured that they would do better than they did on u
Dave
Those result pages I pushed out this week, and they are are a work in
progress
I expect to be adding more depth to them, stay tuned.
Unrelated to buffer bloat results, there is a global speed map available
too:
http://www.dslreports.com/speedtest/results/country
With click features for co
63% F bloat grade for
http://www.dslreports.com/speedtest/results/isp/r3895-Orange%20Broadband
I was disappointed to see the numbers for free, but wish I had insight
into up vs down for their bloat scores.
http://www.dslreports.com/speedtest/results/isp/r2816-Free%20France
but... so wonderful to
On Fri, Jun 5, 2015 at 10:59 AM, Adrian Kennard wrote:
> On 05/06/2015 18:57, Kevin Darbyshire-Bryant wrote:
>> It was the uplink side and the recent adoption of Zyxel kit which
>> made me wonder out loud to AA-Andrew earlier today regarding A&A
>> bufferbloat experiences/testing on that side of t
Very cool. Does this mean that Cisco are not planning on enforcing any
IP rights over PIE?
Simon
On 6/4/2015 3:06 PM, Hironori Okano -X (hokano - AAP3 INC at Cisco) wrote:
Hi all,
I’m Hironori Okano and Fred’s intern.
I’d like to let you know that I have implemented FQ-PIE as a linux
kernel
On 05/06/2015 18:57, Kevin Darbyshire-Bryant wrote:
> It was the uplink side and the recent adoption of Zyxel kit which
> made me wonder out loud to AA-Andrew earlier today regarding A&A
> bufferbloat experiences/testing on that side of things with the new
> modems. You're an ISP that would have s
On 05/06/2015 18:51, Adrian Kennard wrote:
> On 05/06/2015 18:48, Dave Taht wrote:
>> So I am curious as to how well A&A's AS20712 (?) clients are doing on
>> the new dslreports.com/speedtest, which shows the "bloat" grade and
>> actual behavior over time?
> As I say, we try not to be a factor in b
On 05/06/2015 18:48, Dave Taht wrote:
> So I am curious as to how well A&A's AS20712 (?) clients are doing on
> the new dslreports.com/speedtest, which shows the "bloat" grade and
> actual behavior over time?
As I say, we try not to be a factor in buffering, so would be
interesting to see. I suspe
On 05/06/2015 18:23, Dave Taht wrote:
>>> A&A struck me as an extremely clueful ISP (I think they have had ipv6
>>> /48s for forever?)
>>> and it has been my impression that folk like that were using things
>>> like HFSC + SFQ already
>>> in their "rate limiters", and had experimented also with fq_
On 05/06/2015 18:23, Dave Taht wrote:
>> Adrian Kennard the owner writes code for their ISP grade routers etc
>> (Firebricks). Very clever chap. And yes very early adopters and promoters
>> of IPv6. No idea what qdiscs etc they've experimented with. I'll try to
>> ask. Would be interesting
On Fri, Jun 5, 2015 at 10:27 AM, Adrian Kennard wrote:
> On 05/06/2015 18:23, Dave Taht wrote:
A&A struck me as an extremely clueful ISP (I think they have had ipv6
/48s for forever?)
and it has been my impression that folk like that were using things
like HFSC + SFQ already
>>
On 05/06/2015 18:27, Adrian Kennard wrote:
> On 05/06/2015 18:23, Dave Taht wrote:
in their "rate limiters", and had experimented also with fq_codel by now.
> Oh, I meant to say, the policers used on broadband links have a very
> very simple logic of small packets (<1000) are allowed more pred
Hi Dave, hi LIst,
On Jun 5, 2015, at 18:46 , Dave Taht wrote:
> On Fri, Jun 5, 2015 at 9:35 AM, Jonathan Morton wrote:
>> Going back to fundamentals, there's a clear distinction between traffic
>> which is latency sensitive and traffic which is bandwidth sensitive. Perhaps
>> surprisingly, web
On Fri, Jun 5, 2015 at 10:20 AM, Kevin Darbyshire-Bryant
wrote:
> On 05/06/2015 17:19, Dave Taht wrote:
>> On Fri, Jun 5, 2015 at 7:33 AM, Kevin Darbyshire-Bryant
>> wrote:
>>>
>>> On 04/06/15 21:01, Jonathan Morton wrote:
>>>
>>> A useful exercise might be to log the idle latency over a long per
On 05/06/2015 17:19, Dave Taht wrote:
> On Fri, Jun 5, 2015 at 7:33 AM, Kevin Darbyshire-Bryant
> wrote:
>>
>> On 04/06/15 21:01, Jonathan Morton wrote:
>>
>> A useful exercise might be to log the idle latency over a long period of
>> time, and correlate it to peak load periods, as A&A do.
>> http
> I do not regard ping promotion as a "feature".
Neither do I, but in this case at least ping isn't getting an unfair
advantage over other latency sensitive traffic. Measurements based on ping
therefore correctly show a big improvement over doing nothing.
Fq_codel also naturally promotes pings an
On Fri, Jun 5, 2015 at 9:35 AM, Jonathan Morton wrote:
> Going back to fundamentals, there's a clear distinction between traffic
> which is latency sensitive and traffic which is bandwidth sensitive. Perhaps
> surprisingly, web traffic tends to fall into the former category, unless the
> link band
Going back to fundamentals, there's a clear distinction between traffic
which is latency sensitive and traffic which is bandwidth sensitive.
Perhaps surprisingly, web traffic tends to fall into the former category,
unless the link bandwidth is very low by current standards (analogue modem
territory
On Fri, Jun 5, 2015 at 7:33 AM, Kevin Darbyshire-Bryant
wrote:
>
>
> On 04/06/15 21:01, Jonathan Morton wrote:
>
> A useful exercise might be to log the idle latency over a long period of
> time, and correlate it to peak load periods, as A&A do.
> http://aa.net.uk/kb-broadband-cqm.html .
>
> Minor
Yes, making a distinction between large and small packet sizes helps.
There is a clear bifurcation in network traffic at around 300 bytes,
with all kinds of packet sizes below 300, with very few packets sized
in the 300-1100 byte range. webrtc and hangout traffic tends to about
1000 bytes for some
Hi Chaps,
I was speaking with Andrews & Arnold (a UK clueful ISP) about their
experiences with bufferbloat and was sent this graph:
https://support.aa.net.uk/VMG1312:_QoS
I was surprised at how such a simple 'priority by packet size' scheme
appears to work. Clearly there's slightly more goi
On 04/06/15 21:01, Jonathan Morton wrote:
A useful exercise might be to log the idle latency over a long period
of time, and correlate it to peak load periods, as A&A do.
http://aa.net.uk/kb-broadband-cqm.html .
Minor claim to 'infamy'. The line graph shown on that page is my ADSL
line f
26 matches
Mail list logo
