Re: [Cerowrt-devel] [Cake] inbound cake or fq_codel shaping fails on cable on netflix reno

[Pete Heist <pete@heistp.net>]

[-- Attachment #1: Type: text/plain, Size: 2742 bytes --]

> On Jul 21, 2018, at 6:09 PM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> PS I also have two other issues going on. This is the first time I've
> been using irtt with a 20ms interval, and I regularly see single 50+ms
> spikes (in both ping and irtt) data and also see irtt stop
> transmitting.

irtt should keep sending for the duration of the test. I noticed that it looks like irtt was actually used in only one of these initial tests: ping-2018-07-21T082842.445812.flent-newark-reno.flent. In the rest, netperf UDP_RR was used, which can stop sending upon packet loss.

If irtt was configured but didn’t run, that may be because flent does a connectivity check to the server with “irtt client -n”, where it sends three requests within 900ms (200ms timeout, then 300ms then 400ms) and if it doesn’t receive a reply, it falls back to netperf UDP_RR. Do you think that’s what happened here?

> On this front, it could merely be that my (not tested in
> months!) test cablemodem setup is malfunctioning also! Or we're
> hitting power save. Or (finally) seeing request-grant delays. Or
> scheduling delay somewhere in the net-next kernel I'm using... Or....
> (regardless, this seems independent of my main issue, and I've not had
> such high res data before)

Regarding the spikes both you and Arie you’re seeing, I also saw in one of your later emails "0 delay via fq would be better than even
the 15-40ms I'm getting now with linux flows”. Those numbers struck me as similar to an issue I’m still dealing with:

https://community.ubnt.com/t5/airMAX-Installation/NanoStation-M5-ping-spikes-about-once-per-second-even-just-to/m-p/2359800/highlight/true#M119202 <https://community.ubnt.com/t5/airMAX-Installation/NanoStation-M5-ping-spikes-about-once-per-second-even-just-to/m-p/2359800/highlight/true#M119202>

To summarize, with airOS on the NanoStation M5, there are isochronous pauses around once per second in the processing of all packets, not just for the WiFi device but Ethernet also. Packets are not lost, but queued for either 20ms, if one Ethernet port is connected, or 40ms, if both are connected. This behavior is exactly described by the ar7240sw_phy_poll_reset function in ag71xx_ar7240.c, so it looks to me like the ar7240 internal switch is being reset once per second for no apparent reason. So far I’ve gotten crickets in response.

The cable modem you’re using doesn’t happen to have built-in WiFi and an ar7240, does it? If it does and has the same or a similar driver problem, you could just do a low-interval ping straight to its Ethernet adapter and check for isochronous spikes, something like:

sudo ping -l 100 -c 5000 -i 0.001 cablemodem

Now, back to vacation :)

[-- Attachment #2: Type: text/html, Size: 3583 bytes --]