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 <p...@heistp.net> wrote: > >> 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 > > 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@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
