[Cerowrt-devel] [Bloat] Comcast upped service levels -> WNDR3800 can't cope...
moeller0 at gmx.de
Sat Aug 30 14:21:04 EDT 2014
On August 30, 2014 7:19:17 PM CEST, Aaron Wood <woody77 at gmail.com> wrote:
>On Fri, Aug 29, 2014 at 11:06 AM, Dave Taht <dave.taht at gmail.com>
>> On Fri, Aug 29, 2014 at 9:57 AM, Aaron Wood <woody77 at gmail.com>
>> > Comcast has upped the download rates in my area, from 50Mbps to
>> > This morning I tried to find the limit of the WNDR3800. And I
>> > 50Mbps is still well within capabilities, 100Mbps isn't.
>> > And as I've seen Dave say previously, it's right around 80Mbps
>> > (download + upload).
>> Thank you very much, as always, for doing public benchmarking with a
>No problem, I find this sort of investigation a lot of fun. Even if it
>somewhat maddening at times.
>> Yes we hit kind of an unexpected wall on everything shipped with a
>> originally designed in 1989, and the prevalance of hardware offloads
>> the gap and lower costs between 100mbit and a gige is a real PITA.
>Do you think this is a limitation of MIPS as a whole, or just the
>particular MIPS cores in use on these platforms?
I think that the last MIPS-based SGI systems could saturate at least Gbit Ethernet, so it does not seem to be generic to MIPS as an architecture...
>OTOH, I have noticed that MIPS is losing ground to ARM as bandwidths go
I have a gut-feeling that this change is driven by economics and not technical superiority...
> The router SoCs that I'm seeing from the usual suspects have been
>switching from MIPS to ARM over the last year or two. The WNDR is in
>top-tier for SOHO SoCs, but at a product family is getting long in the
>> > I tried disabling downstream shaping to see what the result was,
>> > wasn't pretty.
>> Well, I'll argue that only seeing an increase of 20ms or so with the
>> only, fq_codeled, (vs 120ms not) is not bad and within tolerances of
>> applications, even voip. Secondly the characteristics of normal
>> traffic, as opposed
>> to the benchmark, make it pretty hard to hit that 100mbit download
>> so a mere outbound rate limiter will suffice.
>Well, yes... I have considered just turning it off entirely, as the
>extra latency isn't awful. And frankly, the laptops (individually)
>see that sort of bandwidth, but the AppleTV might when downloading
>need to go see what the downloads are capped at by Apple).
>The cpu caches are 32k/32k, the memory interface 16 bit. The rate
>> (the thing eating all the cycles, not the fq_codel algorithm!) is
>> single threaded and has global locks,
>> and is at least partially interrupt bound at 100Mbits/sec.
>This is interesting, and lines up with Sebastian's idea about perhaps
>ethtool to lock the upstream interface to 100Mbps. Except that moves
>bottleneck to the next upstream device... (modem), with it's buffer
>so maybe that's not a great idea, either. Upstream is certainly where
>biggest issues are.
Well, my proposal (actually its an idea Dave floated some time ago) in full is to set the WAN interface to 100mbps and only run sqm on the egress... This should keep both bottlenecks under control. I assume that you get 100 plus some slack from your ISP, so that 100mbps Ethernet is still a bit faster
>> > Or should I start looking for something like this:
>> > (although that's an expensive board, given the very low production
>> > for the same cost I could probably build a small passively-cooled
>> > mini/micro-atx setup running x86 and dual NICs).
>> There is that option as well. I would certainly like to find a low
>> that could rate limit + fq_codel at up to 300Mbits/sec. Toke's x86
>> have proven out to do 100Mbit/10Mbit correctly, but I don't remember
>> specs, nor has he tried to push them past that, yet.
>If I do get my hands on a Ventana board (I may still for work
>I'll certain set it up and see what it does in this scenario, too.
>Cerowrt-devel mailing list
>Cerowrt-devel at lists.bufferbloat.net
Sent from my Android device with K-9 Mail. Please excuse my brevity.
More information about the Cerowrt-devel