[Cerowrt-devel] Comcast Uplink Buffers

[Cerowrt-devel] Comcast Uplink Buffers

[William Katsak]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

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@gmail.com>
****************************************

[-- Attachment #2: rrul-comcast.pdf --]
[-- Type: application/pdf, Size: 422610 bytes --]

Re: [Cerowrt-devel] Comcast Uplink Buffers

[Dave Taht]

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@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@gmail.com>
> ****************************************
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Cerowrt-devel] Comcast Uplink Buffers

[William Katsak]

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@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@gmail.com>
>> ****************************************
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>
>
>

-- 
****************************************
William Katsak <wkatsak@gmail.com>
****************************************

Re: [Cerowrt-devel] Comcast Uplink Buffers

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 4826 bytes --]

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@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@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@gmail.com>
>>> ****************************************
>>>
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>
>>>
>>
>>
>>
> --
> ****************************************
> William Katsak <wkatsak@gmail.com>
> ****************************************
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

[-- Attachment #2: Type: text/html, Size: 6700 bytes --]

Re: [Cerowrt-devel] Comcast Uplink Buffers

[Dave Taht]

kill offloads.

On Thu, Mar 5, 2015 at 11:05 AM, Aaron Wood <woody77@gmail.com> wrote:
> 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@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@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@gmail.com>
>>>> ****************************************
>>>>
>>>> _______________________________________________
>>>> Cerowrt-devel mailing list
>>>> Cerowrt-devel@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>
>>>
>>>
>>>
>>
>> --
>> ****************************************
>> William Katsak <wkatsak@gmail.com>
>> ****************************************
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Cerowrt-devel] Comcast Uplink Buffers

[William Katsak]

Alright thanks, I'll run some more tests tonight after other people are 
done using the connection.

Regarding your other questions:

Yes, the machine I am using to test is wired to the Atom via a small 
netgear managed switch.

The only thing that is running on this Atom box is routing, iptables, 
unbound, and DHCP.

Thanks,
-Bill

On 03/05/2015 02:05 PM, Aaron Wood wrote:
> 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@gmail.com
> <mailto:wkatsak@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@gmail.com <mailto:wkatsak@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 <http://netperf.bufferbloat.net>.
>
>             Any insight?
>
>             Thanks,
>             Bill
>
>
>             --
>             ******************************__**********
>             William Katsak <wkatsak@gmail.com <mailto:wkatsak@gmail.com>>
>             ******************************__**********
>
>             _________________________________________________
>             Cerowrt-devel mailing list
>             Cerowrt-devel@lists.__bufferbloat.net
>             <mailto:Cerowrt-devel@lists.bufferbloat.net>
>             https://lists.bufferbloat.net/__listinfo/cerowrt-devel
>             <https://lists.bufferbloat.net/listinfo/cerowrt-devel>
>
>
>
>
>
>     --
>     ******************************__**********
>     William Katsak <wkatsak@gmail.com <mailto:wkatsak@gmail.com>>
>     ******************************__**********
>     _________________________________________________
>     Cerowrt-devel mailing list
>     Cerowrt-devel@lists.__bufferbloat.net
>     <mailto:Cerowrt-devel@lists.bufferbloat.net>
>     https://lists.bufferbloat.net/__listinfo/cerowrt-devel
>     <https://lists.bufferbloat.net/listinfo/cerowrt-devel>
>
>

-- 
****************************************
William Katsak <wkatsak@gmail.com>
****************************************