[Cerowrt-devel] SQM and PPPoE, more questions than answers...
alan.christopher.jenkins at gmail.com
Thu Mar 19 09:49:44 EDT 2015
Hi Seb, I have one last suspicion on this topic
On 19/03/15 08:29, Sebastian Moeller wrote:
> My question still is, is the bandwidth sacrifice really necessary or is this test just showing a corner case in simple.qos that can be fixed. I currently lack enough time to tackle this effectively.
>>>> 2) SQM on ge00 shows better latency under load (LUL), the LUL
>>>> increases for ~2*fq_codels target so 10ms, while SQM on pppeo-ge00
>>>> shows a LUL-increase (LULI) roughly twice as large or around 20ms.
>>>> I have no idea why that is, if anybody has an idea please chime
>> I saw the same, though with higher difference for egress rate. See first three files here:
>> [netperf-wrapper noob puzzle: most of the ping lines vanish part-way through. Maybe I failed it somehow.]
> This is not your fault, the UDP probes net-perf wrapper uses do not accept packet loss, once a packet (I believe) is lost the stream stops. This is not ideal, but it gives a good quick indicator of packet loss for sparse streams ;)
Thinking about this, I remembered the issue that sqm de-priotises ICMP
ping. (Back when I used betterspeedtest and netperf-runner, I did
assume this would be an issue).
I also notice that my test with eth1 (disabling classification) is the
only one where UDP ping (including UDP EF) is visible for any time at
all. (ok, pppoe-wan shows UDP BK, and it very clearly gets higher
latency as I would expect).
So I don't know if your results were clearer, but the results I showed
so far should be treated as a measurement problem.
>>> Once SQM on ge00 actually dives into the PPPoE packets and
>>> applies/tests u32 filters the LUL increases to be almost identical to
>>> pppoe-ge00’s if both ingress and egress classification are active and
>>> do work. So it looks like the u32 filters I naively set up are quite
>>> costly. Maybe there is a better way to set these up...
>> Later you mentioned testing for coupling with egress rate. But you didn't test coupling with classification!
> True, I was interesting in getting the 3-tier shaper to behave sanely, so I did not look at the 1-tier simplest.qos.
>> I switched from simple.qos to simplest.qos, and that achieved the lower latency on pppoe-wan. So I think your naive u32 filter setup wasn't the real problem.
> Erm, but simplest.qos is not using the relevant tc filters, so the these could still account for the issue; that or some loss due to the 3 htb shapers...
More information about the Cerowrt-devel