[Cerowrt-devel] Anyone using PPPoE with Sugarland?

[Sebastian Moeller]

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 <wkatsak at gmail.com> 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
>> Cerowrt-devel at lists.bufferbloat.net
>> 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
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel