[Cake] inbound cake or fq_codel shaping fails on cable on netflix reno

[Sebastian Moeller]

I believe that cable modems all default to 192.168.100.1, this seems to be backed by "Cable Modem Operations Support System Interface Specification", CM-SP-CM-OSSIv3.1-I04-150611:

"	• The CM MUST support 192.168.100.1, as the well-known diagnostic IP address accessible only from the CMCI interfaces. The CM MUST support the well-known diagnostic IP address, 192.168.100.1, on all physical interfaces associated with the CMCI. The CM MUST drop SNMP requests coming from the RF interface targeting the well-known IP address."

There might be exceptions to this, but I would be amazed if these would be common...

so:

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

should work on all/most docsis setups.


> On Jul 22, 2018, at 11:57, Pete Heist <pete at heistp.net> wrote:
> 
>> On Jul 21, 2018, at 6:09 PM, Dave Taht <dave.taht at 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
> 
> 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 :)
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake