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...
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
