From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9A858208AB9 for ; Sun, 25 Oct 2015 13:06:47 -0700 (PDT) Received: from hms-beagle.home.lan ([217.237.68.126]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MV5tl-1a05fC3and-00YU77; Sun, 25 Oct 2015 21:06:43 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <562CFE58.9080806@gmail.com> Date: Sun, 25 Oct 2015 21:07:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <272F8057-8B80-440C-AA22-877B7327FAB0@gmx.de> References: <562A5BE5.6010101@gmail.com> <8AAB9319-17D4-40E5-B5B6-DABCB63864CF@gmx.de> <562CF0E6.5050700@gmail.com> <562CFE58.9080806@gmail.com> To: Richard Smith X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:KgMeV/Ra7mHy33gLl6BGctjGgIkKxVdVEUz010TeAwVMa8ifUE1 SQ5toX0iGvnc70TkAn2IqmjWmyS3BhOuZlxhcSqv8BvoBMGyKfH5UiZphzXUfcXfT1Rk5Bl gz1fRVa7VhGdotDimWFPTcfNH/bPuKLtgJdlIhnnOwB+sc/8KHPunzTLLpw5Jaooz3riUyn uafpQ8KgMa9IiILDUJoSA== X-UI-Out-Filterresults: notjunk:1;V01:K0:YoJ4LqHrNMg=:PtHQlXftYVUteZrXjSBJxR jj0s5r+3TQeOO86wUTwooRoyEc2o80w7glSrTDfVzL/hwB05+NE5oDzJD7N/d669HhmVli9Z9 GB/UocT1elXSPV60ade4Gke0ng7vXh69SE3z0UhbyyyL9bGzdCMWCX7zd+H4CES6dZuFJDPtL a5incfQ1AHaAc3KP1DF3kf3A9cDdsJUYmgr693ES13vxCm2lwkwXWWBRoESPVkpi9UsSS3NyU 0MZjdSiQw/FNV4G1bAJ/WHu2RoCJb2/rlaLHo3BQhiQfTxXK5v0gc0lS2yhvmqolIvaLoH6np 8KFQWEJ5oHh1ubqB0sb8pyes64OOaashOdy55MvDAOqrvd5DrlcDabOhwCnnKxsqHx9LebVUC yHlRaWHjPsCqDSklXhoF+uotMjvLu5MZin9Lykgj9Hu65V8F8/14zEcvgDQf4wViT8ofn/KL0 xFzrNwrWcMreF8iV3hFx4DDdaMg9KBrFbMrQSMMvqG3PqPBOsm6Wt0IDCm2oD2p31SCKFuBEL 60AVkJcTGxTzNo9ETl7UUEM/kyXMC27oQTB2CgNeYV4Gu1L0Wl6LiLkCa0AIeYMgiJN5BHBdL OZ2BwK4nk1iChe4lYKxOIc7tgK4n319gcc1w6mciRDXMbp7V12gR2g4NXCKoIvZKnC9e+l8G2 BTqvA7twEnZjLhh5SDjpuUCZfRghJJJ0XKKGbSWdHemQ4ijQY6r578eSBIV+tRpa1K9Df0Tbh NYNb1bBbT8bCyPvEjusRjFhxZ4rTXqozAs5HAUDYHYE7mmY77/IFwYFcOcG8IBi2ET+/31CrG bpRUZju Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Problems testing sqm (solved) X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2015 20:07:11 -0000 Hi Richard, On Oct 25, 2015, at 17:07 , Richard Smith wrote: > On 10/25/2015 11:10 AM, Richard Smith wrote: >=20 >> So I started to try and re-create my steps for failure.. I _am_ able = to >> duplicate the problem but I'm not able to figure out how. It seems = to >> just come and go irrespective of what I'm doing with the DUT. I'm >> mostly in then bad state but every so often things work as expected. >=20 > I figured it out and now I feel _really_ stupid. Why, the =93I figured it out=94 part heavily argues against the = stupid hypothesis, (it might not account for the feeling though ;) ) > The problem was having WiFi enabled on my laptop. Ah, I guess wifi needs to be made fast ;) >=20 > The netperf server is running on a machine which sits on my = 192.168.11.x network. I've been testing things by connecting up the DUT = WAN to that network and then using 192.168.1.x (or 172.30.42.x) as the = DUT LAN side. >=20 > My wireless network is bridged to 192.168.11.x.. Yes, Yes, I know this = is bad but I haven't put in the time to figure out how to configure = things such that all the broadcast stuff like printers and chromecast = Just Work in a routed world. The SO gets unhappy with me when they are = broken and it's difficult to explain the reasoning. It's on the TODO. I fully understand that at a family home there is only so much = experimentation that is tolerable, maybe unless the whole family is = involved in CS or network engineering. I am lucky enough that we started = without any network attached services so we went all routed with cerowrt = and so far have not turned back (knock on wood), but once I switch to = openwrt (which defaults to bridged) I will have to revisit this again... >=20 > network-manager automatically connects wlan0 to that network. I guess we can not even blame it for doing this, often people = would be furious if it did not... >=20 > When I plug up the ethernet cable network-manager sets up eth0 as the = default route but, doesn't shutdown existing wlan0 connections. So = talking to the DUT via ssh or http: works as expected. However, when I = run: >=20 > netperf-wrapper -H server -l 15 --disable-log -p all rrul >=20 > If I forgot to turn off WiFi then I'm completely bypassing the DUT and = testing my WiFi network instead. Simple in retrospect but tough to diagnose. I had a similar weir = wifi issue: the 2.4GHz wlan in my proprietary ISP-supplied modem router, = that I had left active as an emergency way to get into the modem and = read the stats (which felt simpler at the time then teaching cerowrt to = pass the traffic to the modem over the wan port as well; by then I had = figured out the proper way, but had not disabled the AP, thinking this = lives on a different band than my cerowrt router, so could not hurt and = redundancy is good). But that radio has a =93glitch=94 and roughly every = 56 seconds it caused havoc on the modems traffic on all interfaces = (wired and wlan) showing up as periodic spikes of bad induced latency = under RRUL, took me ages to realize the root cause. The solution was = quite simple, since the 5GHz radio in that unit behaves sanely and it is = a one-out-of-two bands device I just switched the radio to 5GHz = permanently... > "This is not the network you are looking for.=94 You=92d wish jedi mind tricks did not work on openwrt or = sqm-scripts. >=20 > Sigh. Sorry for all the noise. Thanks for everyones help. This has been quite interesting. It also reminds me that =93tc = -s qdisc=94 is a thing to test early, looking at the statistics it = should have been relatively easy to spot that there was too little = traffic on the interfaces. Sidenote, I use if top on my laptop during = similar tests, as it also allows to easily monitor different devices = sequentially (I also like it as I believe that it also shows ACK traffic = in the reverse direction which netperf unfortunately does not see). > Now I'll get back to the original task of comparing the performance of = the 1900acs factory firmware vs openwrt trunk with sqm. I am quite curious about the worst case performance, or the = ingress+egress rate combination that keeps the latency increase under = load sane with minimal packet size traffic. Mikael Abrahamsson did a lot = of relevant testing in the following thread = https://lists.bufferbloat.net/pipermail/cerowrt-devel/2015-June/004726.htm= l . I believe he used iperf to allow manipulating the packet size, = though I believe it should be possible to use the DUT=92s MSS clamping = function to achieve the same with netperf (which is a bit nicer in that = it allows bidirectional saturating traffic with flent=92s RRUL test = easily). Since your unit uses the same/a similar SoC to the turris omni = a that I want to get I am quite curious about the performance numbers = you come up with. Especially with regards to offload functions and the = relation between shaper rates and achieved transfer rates (see Aaron = Wood=92s posts about that at = http://burntchrome.blogspot.de/2015/06/htb-rate-limiting-not-quite-lining-= up.html ) Best Regards Sebastian >=20 > --=20 > Richard A. Smith