From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id F2FB621FBDB for ; Wed, 29 Jul 2015 06:41:43 -0700 (PDT) Received: by oixx19 with SMTP id x19so5104772oix.0 for ; Wed, 29 Jul 2015 06:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=T32y/J4tC1YIU+XlkDtiqZRPQfU+H4CRpc1U9Mso8AU=; b=kB7B5ho9Ag2Z8gbVA4LDHsUewcS7Wnj0savLsKiVY8fhHzF2FZielSiu8kJs1VgMFm +AR4gcmmACOT5CXLHC5619V4+O3KerTQGIKR8lnqXeRPCs0eSDXGTJLiWvjlniR4epXj G0D5HXk6AEKmjaW0x3OKTqZrAL7r0/BbGGY6drVi35gM4ql8DA/j1oNDBlg18RvmYMnf aAZ+2fjgOmX3l5a61CMH2/gEBcqBnEydBrfjey+PSvVk7ivmRqrDMANSxjKoF4Y9g6IR rmvqoBeL7p7rGIXBtF/fwKnm3rbcT+vXQdHZRB8dpujfhrgjeNvGs39Vc2pvAK03Lgvp MSsg== MIME-Version: 1.0 X-Received: by 10.202.214.16 with SMTP id n16mr38614234oig.75.1438177302087; Wed, 29 Jul 2015 06:41:42 -0700 (PDT) Received: by 10.202.73.2 with HTTP; Wed, 29 Jul 2015 06:41:41 -0700 (PDT) In-Reply-To: <20150729131542.GA16305@sa-pc> References: <87a8ugqvid.wl-jch@pps.univ-paris-diderot.fr> <20150729131542.GA16305@sa-pc> Date: Wed, 29 Jul 2015 15:41:41 +0200 Message-ID: From: Dave Taht To: Stefan Alfredsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] AQM and PPP on Linux X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 13:42:12 -0000 On Wed, Jul 29, 2015 at 3:15 PM, Stefan Alfredsson wrote: > * Quoting Dave Taht [28 Jul-15 16:44]: >> On Tue, Jul 28, 2015 at 3:09 PM, Juliusz Chroboczek >> wrote: >> > I'm currently away from home, and using a 3G modem for Internet access= . >> > I've found out that both NetworkManager and wvdial/pppd setup the >> > interface to use pfifo_fast (with a qlen of a mere 3 packets!). Setti= ng >> > fq_codel manually appears to work fine, but needs to be redone every t= ime >> > the modem has a hiccup. >> >> However, the netusb-related drivers, and the 3g devices themselves, >> contain oft-huge buffers that reduce the effectiveness of any aqm or >> fq system, sometimes to immeasurability. >> >> I would be very interested in flent benchmarks of your 3g device with >> the 3 packet txqueue and with fq_codel, for the tcp_upload, rrul, and >> rrul_be tests. > > > I have a station with mobile broadband USB modems (4xHuawei E392), > directly connected to a Linux box running kernel 3.16.3, with > a (non-public) netperf server (same kernel) hosted on the well-connected > Swedish university network. > > I also have a 3 packet txqueue, and ran the flent tcp_upload, rrul, rrul_= be > for 3.5G (HSPA+) and 4G (LTE) networks for one of the operators/modems. > For comparison, I ran both pfifo_fast and fq_codel. > > The execution script, output and flent result files are available at > https://www.dropbox.com/s/n5tc1dhtu9jdplz/bloatlist-ppp-150729.zip Thank you SO MUCH for the raw flent data. That made poking through this a s= nap! Of course, the news is mostly bad - a tiny fifo qdisc on LTE looks to be presently best than any amount of queuing/aqm/fq at the layers above the device driver and device. Something like BQL is needed for usbnet, and the usb-cellmodem driver... and some means of tracking completion interrupts sanely to change this picture. We did a bit of work on both these layers a while back but we lost steam at the complex interactions of the usb stack. as an aside - and on the wifi front, recently toke and I did a string of overnight tests on the wifi test rig we are taking to battlemesh, which includes the latest minstrel blues and minstrel variance patches. Sadly, also, mostly of note is the wide variabilty of results from run to run, in the same wifi environment. There were only a few radios we could "hear" to interfere... and I'd done much better with the exact same radios in an environment fully under my control. A tarball of all these flent testruns and tests is at http://snapon.lab.bufferbloat.net/~d/long-running.tgz Anyway... the variance from run to run: http://snapon.lab.bufferbloat.net/~d/long-running/10testscompared.png Trying to pull apart the apparently bi-modal interactions with rate control (and *why*) is going to take some *work*. http://snapon.lab.bufferbloat.net/~d/long-running/themessthatiswifi.png This plot, randomly picked out from the others http://snapon.lab.bufferbloat.net/~d/long-running/wifiratecontrol.png shows clearly the current interaction between the current rate of the wifi and the latency. (but I have no idea *why* it stayed stuck at the lower rate for 20+ seconds!). Still, I believe we have developed means to hold the latency low at nearly any bandwidth, we just have to roll up our sleeves and make per station queuing work and then start glomming on new algorithms. Or so I hope. ... I happened to rather like this plot, from an artistic perspective, showing the bands that each 802.11e queue fits into. Sort of. http://snapon.lab.bufferbloat.net/~d/long-running/vangogh.png But maybe I am thinking of the wrong artist? > From flent --gui inspections, I'd say there is about a factor 10 increase > from base to load latency (from around 40-50 ms to around 400-500 ms), > for both pfifo_fast and fq_codel, for both link types, > with some transients above 1000 ms. > > > Juliusz: Regarding data usage, the 4G measurements consumed 1.4 Gbyte > download and 357 Mbyte upload - but it all depends on the network > throughput as the experiments are time bound (by default 60 seconds). > For 3.5G 100 Mbyte data was sent, and guesstimately 500 Mbyte received > (sorry, didn't capture the amount; but it can probably be found in > the trace files if necessary. However it all depends on your link > throughput which will be different from mine anyway). Yes. One reason why I have not focused much on fixing LTE, is I refuse to have them charge me for attempting to fix their technology. It is bad enough throwing good money away to Netgear to fix their routers, but to get charged through the **** for LTE on a bandwidth basis - and I could see, eating a lot of bandwidth with various tests - ENOBUDGET. Now, if we could, like, get 20 free unlimited use sims for anywhere in the world, that might be an incentive.... ;) > > > Cheers, > Stefan > > -- > Stefan Alfredsson, PhD Tel: +46 (0) 54 700 1668 > Datavetenskap Kontor: 21E-414 (Hus Vanern) > Karlstads universitet PGP 0xB19B4B16 > SE-651 88 Karlstad http://www.cs.kau.se/stefalfr/ > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast