Re: [Cerowrt-devel] SQM and PPPoE, more questions than answers...

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

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
>>>> in.
>> I saw the same, though with higher difference for egress rate.  See first three files here:
>>
>> https://www.dropbox.com/sh/shwz0l7j4syp2ea/AAAxrhDkJ3TTy_Mq5KiFF3u2a?dl=0
>>
>> [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...