> On Jul 21, 2018, at 6:09 PM, Dave Taht <dave.t...@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 :)
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
