From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 34C843B29E; Sun, 22 Jul 2018 06:29:58 -0400 (EDT) Received: from hms-beagle2.lan ([79.192.253.1]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MQiVh-1fZiRz3P0X-00TyOG; Sun, 22 Jul 2018 12:29:54 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 22 Jul 2018 12:29:53 +0200 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , Cake List , cerowrt-devel@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <0B16281A-ED59-4C63-BD78-5ABAF1112C78@gmx.de> References: To: Pete Heist X-Mailer: Apple Mail (2.3445.9.1) X-Provags-ID: V03:K1:4Qy1wkXlI3Q8oZjJ20XGr2+aLzp/hqbKTvgerJXPrdX+myfB8yL 0YsdAD/TONsAcJUy3OT/GLYBBypsxcfE+hRFt0DrrZhJnCXrsMgHHs6aco/hRX7CDeq2ur0 8IWdn78BxScNZuxSfJtHTWLBy9pe+yYEjWvcVczrSZsyjBh8XtVU/Trmp3IvVLVSPnhPRPk +nvDQaCjXgYHfMrglH58A== X-UI-Out-Filterresults: notjunk:1;V01:K0:+w1KCLZ5EeI=:eu3lyDPV+oVyLzLcrm/9KU DObyIJYaRT7QGS3RSC2oYXN8BPtlzNnAZglXIekrFYD5kOhLIahSGZGUFvoct7rc2aY3RoLja Z2MU0SUp2pGKH5l6WwhaEEQU9/S58JDCC/wOrJzCZw1E9yGWpiOKQmJEayGnRoe8C4YCTG8u2 RZARivIXbXrNQmJYN9upds7241mcPBzNoqeSMwJVtsQT36EbwACGP1sn9pTKaBa0VnRUPplyI 2ZygJRRdjHdiEJs05ziS1c0fMlqq/TcBB3b/WVB6SlWTQXcwP9qDMU/3bv3g7ccNKc+qSyLXI Te7x3n1ZIB7T0SrVaOTzOEKYMeZKpFAT/xZa2HuvNk4xi+9KRm6Ra4UElKwAPyKwnO3WOc1hn 51aathX5bsGR/sdKWEqne2ep4obt8Q7acrCKIoAubEBJGCPzOAGD4KEzenjjggNBkTsXBXAJV ekkp4zxIQ9uRRwOJHuqqONx42n8Pds+nWuoPW3bxXD3Xg45jtn7yv4vnHFUZWjN0im2V9HkbO DpwPbYIZ3Zm3xj2GbPUdjzu78qBHpYCCkrcHUlHdCsQQ/nPtfb4Ub5FTJvnmN4weOybyvU/ec Vcj3N8cz4cg9K2x2tsqr5IxiAT+LA4iJYVLqYFHiTWiIzrbqKtglkXqBEcyPvB+hu53IAskij P2oHngHM0ELYI9aKL35RQc3bPtUtjSTX8Jhka3pjOwHpVtAr8w2tbaKPOeZv1rHLlMLeucY+3 JXQaHMakrET1nHkdBmUiV6pFKo92VC2kM1RCaPioRJYPKzyrmxlDKpmy4BkN6TK4yqyOIAhiO M0fmEvx Subject: Re: [Cake] inbound cake or fq_codel shaping fails on cable on netflix reno X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2018 10:29:58 -0000 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: " =E2=80=A2 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 wrote: >=20 >> On Jul 21, 2018, at 6:09 PM, Dave Taht wrote: >>=20 >> 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. >=20 > 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. >=20 > If irtt was configured but didn=E2=80=99t run, that may be because = flent does a connectivity check to the server with =E2=80=9Cirtt client = -n=E2=80=9D, where it sends three requests within 900ms (200ms timeout, = then 300ms then 400ms) and if it doesn=E2=80=99t receive a reply, it = falls back to netperf UDP_RR. Do you think that=E2=80=99s what happened = here? >=20 >> 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) >=20 > Regarding the spikes both you and Arie you=E2=80=99re 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=E2=80=9D. Those numbers = struck me as similar to an issue I=E2=80=99m still dealing with: >=20 > = https://community.ubnt.com/t5/airMAX-Installation/NanoStation-M5-ping-spik= es-about-once-per-second-even-just-to/m-p/2359800/highlight/true#M119202 >=20 > 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=E2=80=99ve gotten crickets in response. >=20 > The cable modem you=E2=80=99re using doesn=E2=80=99t 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: >=20 > sudo ping -l 100 -c 5000 -i 0.001 cablemodem >=20 > Now, back to vacation :) > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake