Hi Dave,
(and sorry William for being off-topic)
On Jan 5, 2013, at 21:31 , Dave Taht wrote:
> Netanalyzer's metrics are wrong when used with a fair queuing or codel
> based system.
I tend t disagree, netalyzr still gives a good estimate of the worst
case buffering. I have a hunch that a hierarchical shaper setup should only
treat tcp flows to codel and use something less gentle for everything else
unless proven to be as well behaved a tcp. Being a layman, I am unsure whether
anything except UDP and TCP actually matter. Maybe fq_codels fq machinery could
be combined with another drop strategy that drops more aggressively to keep UDP
in bound (IIRC DNS used UDP so just rate-policing UDP sounds not like the way
forward after all the buffer bloat experiments bought us). Anyone knows which
protocols are actually relevant? And would white-listing TCP be preferred over
black-listing UDP? (With the usual issues that black-listing tends to be
optimistic, white-listing pessimistic about the future). (Or could we just
cheat on fq_codel and ramp the dropping faster for flow-buckets (also)
containing non-TCP traffic, like increasing count in larger quantities; that
will penalize all traffic hashed to that bucket, but might be an acceptable
price to pay to keep UDP under tighter control)
> They use a single udp flood to measure the "queue" when
> in the "fq" portion of fq_codel there are 1024 by default, and when
> codel kicks in, queue depth is reduced eventually to a level that tcp
> would expect, but has no effect on a single udp flood.
Really? I thought that given enough time codel will reign in on any
misbehaving flows it just takes "a bit longer" if the assumption of the
relevant floe's back off strategy is not matched...
>
> Use a ping vs a big upload as your test, or the rrul test, after
> setting your up/download appropriately.
But the problem with this approach is that heavy UDP traffic will still
be detrimental to the latency of the router, would it not? Oh, and please do
not take me too serious (or serious at all) since I will not be able to
implement any of this (lack of fluency in C, and lack of time to implement the
TCP UDP separation in tc (plus what would one use to flow-queue UDP?))?
best
Sebastian
>
>
>
> On Sat, Jan 5, 2013 at 1:37 PM, William Katsak <[email protected]> wrote:
>> Hello,
>>
>> I am experimenting with using Cero/Sugarland on a PPPoE connection, and
>> can't seem to find a config of simple_qos that works well.
>>
>> The service is DSL, PPPoE, 3M/768K. Without any qos, the router works well,
>> as expected. When I try to use simple_qos, the clients have trouble loading
>> websites (hangs while loading, etc).
>>
>> Netlyzer shows upstream buffering of about 650ms, consistently. I have tried
>> various higher and lower values for UPLINK and DOWNLINK, but nothing seems
>> to help. Anyway, I think 15-20% below link should be fine.
>>
>> Here is my config:
>> UPLINK=550
>> DOWNLINK=1900
>> DEV=ifb0
>> IFACE=ge00
>> DEPTH=42
>> TC=/usr/sbin/tc
>> FLOWS=8000
>> PERTURB="perturb 0" # Permutation is costly, disable
>> FLOWS=16000 #
>> BQL_MAX=3000 # it is important to factor this into the RED calc
>>
>> CEIL=$UPLINK
>> MTU=1492
>> ADSLL=""
>> PPOE=yes
>>
>> Couple of things I am unsure about:
>> 1) Should the IFACE be ge00 or pppoe-ge00?
>> 2) Should the MTU be the pppoe mtu (1492) or the ethernet (1500)
>>
>> One last thing: I have the lan split up into VLAN interfaces se00.1,
>> se00.100, and se00.200. Everything otherwise works as expected with these,
>> but could the naming be breaking something?
>>
>> If anyone is willing to share a working configuration it would be much
>> appreciated.
>>
>> Thanks,
>> Bill Katsak
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> [email protected]
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
> _______________________________________________
> Cerowrt-devel mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
