From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 BEA283B29E; Wed, 8 Feb 2017 11:35:31 -0500 (EST) Received: by mail-qk0-x242.google.com with SMTP id 11so18561051qkl.0; Wed, 08 Feb 2017 08:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2RkLWVR+y87r3PkbL1zKOh8Vs60GONqKkOTCOrIJ+fA=; b=rukZW1eTmRObrSCm48w1XwJxRrCB02fDwwGIQuZAAaAm4s1P/MLHy4iWCbFAl3me+9 FpVh6tDoO3PxhqIXpD7JKJjZP2E98MEFZO5sqdl1BsYiBnP8m5GB50GoAI03Sr3fZ/Zq LTHdhKnhbURXdjjvoYVs4fOGHXgAlBWTJSQs5flSmYtJcHGOltheq6imxVFm9c8/66R7 JJm+PsSdT/6ZsL1YsiQXhfoCpDry0nYivIBtQ59NyP57QcmLLvEoymHmMQVvvCZLFnkG WDs6SSpN/v8yxIXdBA/cEba00sgSdMbN6oVko02T5NKSxzEIj/8z18LBSN0jz0vHGwLR vbzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2RkLWVR+y87r3PkbL1zKOh8Vs60GONqKkOTCOrIJ+fA=; b=YcWDncNxkXgExLxpH5wCr1maNHev88N/rYzKhufkpTze13FQ1qpVgMI0D/oD2t8LDb g5mKwDN9JijDmGcPZR3ytQTrUYUtgnSEHw1iEHP0h4pBL6LnO8SoCrXGD1K/eykEHOh7 Wx7WgR0yMT7daf1T8H2TnDppdzb87euUHUpO3Pz/e400DkD4hs2TqbvImJj8RBcVR9M6 Ol2Cs9Xi7hI/LIvL3nzpjYvtOD1kXyzQQ+2eRknJxcmo9bc44Xt+3HKwKn/Sfi4+IUab 3aaZe0/i1jP/92IOVwk+FKZKrUDlsqZpaEA6S1BVGlc502NbsFC83ziejek9xIq4wOnf eS4w== X-Gm-Message-State: AMke39kJuHtlGYd4aW8HrbE+yV7uVyP+W0DS79PGUwGF1FsgISLd8TG2Nl7q9kf2yimbS7O9Wh84t4AmYUFbQw== X-Received: by 10.55.198.149 with SMTP id s21mr22603528qkl.196.1486571731129; Wed, 08 Feb 2017 08:35:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.132 with HTTP; Wed, 8 Feb 2017 08:35:30 -0800 (PST) In-Reply-To: <87bmucu0gs.fsf@toke.dk> References: <32C42951-373F-4D90-8936-AA07039E5D73@gmail.com> <877f5c2pew.fsf@toke.dk> <878tpqge5g.fsf@toke.dk> <877f52rz68.fsf@toke.dk> <87bmucu0gs.fsf@toke.dk> From: Dave Taht Date: Wed, 8 Feb 2017 08:35:30 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Pete Heist , Cake List , make-wifi-fast@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] [Make-wifi-fast] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available 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: Wed, 08 Feb 2017 16:35:31 -0000 On Wed, Feb 8, 2017 at 8:11 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Pete Heist writes: > >> Yeah, I have recently begun learning Go myself, and like it too. Apart >> from the fact that it produces these huge statically linked binaries, >> and requires glibc, so you can't run it on embedded systems (such as >> LEDE). >> >> If I were to integrate code that actually shipped packets into Flent, I >> would probably use Python=E2=80=A6 >> >> Even after the new SSA back end, they can still be large. I hadn=E2=80= =99t >> thought to run Flent on embedded hardware, so there isn=E2=80=99t a >> performance impact from running the test code itself on the hardware >> you=E2=80=99re testing. But that=E2=80=99s true, if it needs to sometime= s, then Go >> doesn=E2=80=99t work. > > It's not so much running the test *from* the router, as it is having the > server component (netserver) run on a router to test. To do that it'll > have to be C, basically... I note that I usually run tests *through* the router rather than *to* the router, and most of my targets for this have evolved to be arm (odroid c2), and x86 platforms, so I could get past a gbit. Long ago I started writing a spec for the things that we couldn't quite do sanely using netperf as a substrate (twd in my github repo), but I gave up as getting to netperf equivalence was too hard. Of note I've always regarded exposing d-itg and some sort of monotonic voip-like test to the internet as too dangerous without a solid 3 way handshake, and leveraging existing voip and webrtc/videoconferencing servers (like freeswitch) way too hard to setup and measure. (there are plenty of tools to generate rtp-like packets). I am unfond of the current ping and udp tests in the rrul component because they don't look like these traffic types, and drawing conclusions from their behavior as if they were is wrong. Also, with very low RTTs, the measurement flows tend to skew the tests - you'll consistently see "lower bandwidth" measured when you cut an RTT from 100 to 1ms via active queue management, when what is really happening is 100x more measurement traffic. Of the choices today for writing network servers, go appears to be the leading candidate, and certain things that might affect timings (for example, stop the world garbage collection) can be turned off during a test. Being lazy about writing protocols and wanting to (eventually) also have a C version, I'd looked over both protobufs, and https://capnproto.org/ as means to abstract enough of that out to handle both test negotiation and simulation... and then I went back to just using trusty old netperf 'cause when you are getting orders of magnitude improvements throughout the stack it really didn't matter. We're now at the point with both cake and fq_codel at the wifi mac layer, where getting precision timings with variances below a ms is becoming needed. (I basically ignore anything less than 3ms as noise presently)... and for example, I'm anal enough (now) to see this tiny latency spikes on tests like this on 60 second intervals and wonder where they are coming from... http://www.taht.net/~d/worldwide_fairness.png >> It=E2=80=99s not critical, but why am I able to see this level of reduc= tion >> when there=E2=80=99s already fq-codel in the driver? 25ms is very good,= I only >> wonder where I=E2=80=99m getting the extra 10-15ms from, out of interes= t. :) >> >> The driver queues up two aggregates beneath the queue to keep the >> hardware busy. It may be possible to improve slightly upon this, but we >> have not gotten around to trying yet. >> >> Ok, if rtt were about half of 25ms there would be almost no argument >> for external rate limiting. Even as it is now, I question what >> difference the user sees between 12ms and 25ms latency for Internet >> traffic. It also makes me more interested to see results for Chaos >> Calmer with fq_codel applied on the Wi-Fi device without limiting. >> >> Yup, exactly. We want to get to the point where you'll have no reason t= o >> do any rate limiting. >> >> That reminds me, is there any way to disable fq-codel in the ath9k >> driver, and revert to being able to use the qdisc layer without >> limiting? Then I could do this testing without having to install Chaos >> Calmer, and it could avoid some re-flashing in case I need to re-test >> something in the new driver code again. > > Nope, no way to turn it off. > > -Toke > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org