[Cerowrt-devel] Comcast Uplink Buffers

[Aaron Wood]

Bill,

I'd recommend setting the bandwidth values low (very low) at first, just to
establish that the setup is working correctly.  I'm able to get better
control of latency at those bitrates on an WNDR3800:

http://burntchrome.blogspot.com/2014/05/fixing-bufferbloat-on-comcasts-blast.html

I'd start slow, and then start raising the limits until you see issues.

But it's possible something else is causing issues.  Is your netperf source
wired to the Atom?  (for bandwidth levels that ruler flat, I normally
assume wired.  I've seen wifi give odd 30ms jumps in latency, but those
normally come with an drop in bandwidth as well).

What else is running on the Atom box?

-Aaron




On Thu, Mar 5, 2015 at 7:49 AM, William Katsak <wkatsak at gmail.com> wrote:

> Dave,
>
> Thanks for the reply. I should have made it clearer that I am not running
> this on a Netgear 3800, I am running the sqm system on an Atom D510 box at
> 1.66 GHz (two cores + hyperthreads) with 2 GB RAM and good Intel NICs.
> While running the rrul, the CPU is barely breaking a sweat.
>
> The OS is Ubuntu server and I've made a nice wrapper to run simple.qos via
> the if-pre-up/post-down hooks.
>
> Can you suggest any tweaks to the settings that would better take
> advantage of the extra CPU that I have?
>
> Thanks,
> Bill
>
>
>
>
> On 03/05/2015 10:43 AM, Dave Taht wrote:
>
>> well, cerowrt's inbound shaper runs out of cpu at +60mbits. That is
>> possibly part of your problem.
>>
>> the peaks you are seeing are not bad - but to me, probably indicative
>> of running out of cpu, which will among other things, drop packets
>> burstily.
>>
>> As comcast has rolled out 100mbit+ service in a ton of places
>> (including my home), we really, really, really need to find a way to
>> do better rate shaping at higher speeds (or develop a faster policer)
>> on some successor hardware.
>>
>> If you turn off inbound shaping (0 for that parameter) my measurements
>> typically show over 600ms of latency on inbound on comcast at 100mbit
>> down, but at least, doing the tcp_upload tests, we can hold the upload
>> more under control. It is a totally unsatisfactory thing to have
>> downloads got so much out of control, it really messes up other
>> things, inside of a few seconds, on big downloads, but at this point I
>> have to recommend turning off inbound shaping and just living with it.
>>
>> Very high on my list now is finally writing (or tom sawyering someone
>> into writing!) "bobbie - the kinder, gentler policer" in the hope that
>> that could actually run faster and better than shaping does on this
>> low end hardware.
>>
>>
>>
>> On Thu, Mar 5, 2015 at 7:35 AM, William Katsak <wkatsak at gmail.com> wrote:
>>
>>> Hello all,
>>>
>>> I just moved and had to switch my ISP from Optimum (Cablevision) to
>>> Comcast
>>> (100/10 link).
>>>
>>> I am running my own port of simple.qos over to Debian/Ubuntu, and it
>>> worked
>>> fine on Cablevision (I basically use scripts in if-pre-up.d and
>>> if-post-down.d to set the variables set up/tear down simple.qos).
>>>
>>> However, since I moved over to Comcast, I am seeing something like 600
>>> ms of
>>> uplink buffering according to Netlyzer. Also, the Internet browsing
>>> "feels"
>>> slow when Netflix is in use elsewhere in the apartment (like before I
>>> knew
>>> anything about bufferbloat).
>>>
>>> My config looks like this:
>>> UPLINK=7500
>>> DOWNLINK=85000
>>> QDISC=fq_codel
>>> LLAM="tc_stab"
>>> LINKLAYER="none"
>>> OVERHEAD=0
>>> STAB_MTU=2047
>>> STAB_MPU=0
>>> STAB_TSIZE=512
>>> AUTOFLOW=0
>>> LIMIT=1001   # sane global default for *LIMIT for fq_codel on a small
>>> memory
>>> device
>>> ILIMIT=
>>> ELIMIT=
>>> ITARGET="auto"
>>> ETARGET="auto"
>>> IECN="ECN"
>>> EECN="NOECN"
>>> SQUASH_DSCP="1"
>>> SQUASH_INGRESS="0"
>>> IQDISC_OPTS=""
>>> EQDISC_OPTS=""
>>> TC=`which tc`
>>> #TC="sqm_logger tc"# this redirects all tc calls into the log
>>> IP=$( which ip )
>>> INSMOD=`which modprobe`
>>> TARGET="5ms"
>>> IPT_MASK="0xff"
>>> IPT_MASK_STRING="/${IPT_MASK}"     # for set-mark
>>>
>>> I've also attached the output of a run of rrul against
>>> netperf.bufferbloat.net.
>>>
>>> Any insight?
>>>
>>> Thanks,
>>> Bill
>>>
>>>
>>> --
>>> ****************************************
>>> William Katsak <wkatsak at gmail.com>
>>> ****************************************
>>>
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>
>>>
>>
>>
>>
> --
> ****************************************
> William Katsak <wkatsak at gmail.com>
> ****************************************
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20150305/daba98c6/attachment-0002.html>