Hi Oliver,
On Feb 25, 2014, at 12:14 , Oliver Niesner <[email protected]> wrote: > Hi list, > > I use cerowrt (3.10.24-8) direct behind my main dsl Router. > SQM is set and performance is good. This is the most important part; you seem happy with the actual latency under load. > When i used Netalyzr from my smartphone i've got good results. > >> Network buffer measurements (?): Uplink 96 ms, Downlink is good Presumably the smart phone connects to the cerowrt router via wlan? > > But when i use my notebook i get this: > >> Network buffer measurements (?): Uplink 1200 ms, Downlink is good If you want to change that number neatly reports you will need to change the limit variable of the fq_codel instance(s) on your uplink device (ge00), smaller limit values will cause smaller reported buffering. BUT you should not be concerned about this report at all. Netalyzr tries to fill the buffers with (relative) high bandwidth inelastic unrelenting UDP traffic, one could say it represents a DOS attack better than real traffic. Real traffic be it TCP (by virtue of the protocol) and even UDP (by virtue of application writers implementing their own congestion control) will react to packet loss by reducing the transmit speed. SQM does a good job strategically dropping packets so that all flows can adapt their bandwidth to the available total bandwidth. The beauty of codel is that it starts out quite gentle in a way that is well matched to TCPs congestion avoidance. It will turn less gentle if the traffic does not respond and congestion stays high. Netalyzr now is this weird combination of short duration yet unrelenting traffic. The reason why SQM does not affect the netalyzr probe by much is that the netalyzr traffic stops before fq_codel has ramped up the dropping. So what happe ns is that the probe fills the largest buffer which is specified by the limit parameter of fq_codel, that defaults to 1000 packets on cerowrt (once the queue has limit packets all new packets get dropped, as it resorts to tail dropping, but that really is just an emergency behavior; under normal loads with a slow link the queue will never come close to 1000). TL:DR version, netalyzr probes a buffer depth that while existing has not much relevance on the latency behavior under load for cerowrt. >> > > I tried even wired connection and set ring buffer rx/tx with ethtool to 64, > but > only minimal change in uplink buffer (1100ms). Good idea but wrong tunable ;) > > Has anyone an idea, what i can try to get better uplink performance? Unless you intend to run yur router under continuous DOS attacks, I would recommend to ignore netalyzr's buffer measurements (as they do not reflect cerowrt's behavior under a more realistic load well). Best Regards Sebastian > > Regards, > > Oliver > > _______________________________________________ > 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
