Hi Alexei,
On Sat Nov 29, 2025 at 6:46 PM CET, Alexei Starovoitov wrote:
On Fri, Nov 28, 2025 at 2:27 PM Alexis Lothoré (eBPF Foundation) alexis.lothore@bootlin.com wrote:
[...]
The original test was configured with a 20s duration and a 1% error margin. The new test is configured with 1MB of data being pushed and a 2% error margin, to:
- make the duration tolerable in CI
- while keeping enough margin for rate measure fluctuations depending on the CI machines load
Applied, but it's still a bit flaky in my setup. Fails like this from time to time when run in parallel with other tests: run_test:FAIL:rate error is lower than threshold unexpected rate error is lower than threshold: actual 6 > expected 2 #450 tc_edt:FAIL
Yeah, that's what I was worrying about with this test. For the record, I tested the v2 using my own fork this time to run GH actions before sending, rather than opening a dummy PR onto the official GH repo, and this somehow led to only x86 testing (which passed). I then saw the test failing on the official CI triggered by the series being posted, in S390. I guess this is not so suprising, as any qemu other than x86 will likely make tests more sensitive to CPU load.
Maybe we can afford to raise the admissible error on the effective rate to something way higher, like 10%. That would validate any rate between 4.5MBps and 5.5MBps, but that's still pretty far from the rates we can expect if the shaper fails to trigger, so the test would still make sense.
Otherwise, an intermediate test that we could do is setting it as a serial test and see if it improves things in CI ?
Alexis