From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-gy0-f171.google.com (mail-gy0-f171.google.com [209.85.160.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id DD9BB200624; Wed, 1 Feb 2012 09:12:18 -0800 (PST) Received: by ghbf1 with SMTP id f1so1027912ghb.16 for ; Wed, 01 Feb 2012 09:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=lWhiykdQJIT8YCrNNT4TvSWgUzBSmmAQBUSE7TF5DX4=; b=Nl2aEDtAZSEsRCTYxa6/0ueoHYg8R6pXsm6ETvtfqUcMtRhqmi6nR70mk0Vh0xDeU6 Oo8fUYiRAAZ4xQEU/Kp0p6zVVgJVAUw6uGGuiA47CcZogilJJboZUXZ+E584r2YSDBHN E4P3cCMhuZi7+UC4FcZA6vnldIJlJUzEG4FzA= MIME-Version: 1.0 Received: by 10.50.11.202 with SMTP id s10mr11182944igb.25.1328116337387; Wed, 01 Feb 2012 09:12:17 -0800 (PST) Received: by 10.231.7.21 with HTTP; Wed, 1 Feb 2012 09:12:17 -0800 (PST) Date: Wed, 1 Feb 2012 17:12:17 +0000 Message-ID: From: Dave Taht To: bloat , cerowrt-devel@lists.bufferbloat.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Bloat] Testing Queue models 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, 01 Feb 2012 17:12:19 -0000 Now that I have BQL and the new SFQ, ARED, and SFQRED working in cerowrt, I have been working on modeling the behavior of existing shapers (wshaper, openwrt, sfqred, and something more torrent-proof that doesn't have a name yet) There are several things that will get in the way of doing it well at the present time, and I hope to evolve towards something that works well in nearly all cases. For purposes of this discussion I'll use a few abbreviations. "u" =3D user "d" =3D device "f" =3D flow Some general notes: Accurately determining uplink bandwidth is something that no tool does quite right today, and even then uplink bandwidth can be dynamic (notably on cable). Van and Kathie are working on something that can figure it out better, dynamically, but that code's not ready yet. Instead I'm trying to pull together a shaperprobe that detects modern conditions better, statically, at least. Uplink speed is the principal bottleneck problem that users deal with. I'm running SFQ on all interfaces. This helps break up streams into more manageable chunks. It can be really NICE, on ethernet. In fact, most of my network bottlenecks have moved to my desktops and laptops in the general case, and to get best results I have to run the debloat script and enable SFQ everywhere, in this wack-a-mole game. SFQ has positive effects on wireless as sparse streams move forward in the queue, and are thus shipped as an aggregate at the earliest opportunity. Regrettably there is so much rate-insensitive fixed buffering at present in the Linux wireless stack as to incur huge penalties at variable rates. It can have negative side effects on wireless, as it mucks with packet aggregation across devices. That said, in home use (rather than with dozens of wireless devices) it should help somewhat. I'm not worrying about wireless behavior all that much right now, I'm mostly trying to exercise the new code... as fixing the aggregation problems really needs to have a per-destination queue somehow. Developing correct configuration for RED and ARED is something of a dark ar= t. The new SFQ prioritizes new streams very well. Perhaps overly well. Eric has a patch in progress to make it have more of an idea of 'how new' a stream is. It otherwise is very effective in reducing latency for short, sparse, streams. SFQRED's mental model is closer to what an ISP would use on it's downstream link. It is not (quite) right for what a site would use as an uplink. QFQ, which is what I was using to get 1/d level behavior in the prototype I did several months back, still is hanging under load on cerowrt. It's working on x86. :( Might try working with classful SFQ stuff instead, or I may give DRR a shot instead. Even getting 1/d is hard because the filters can only use IP and IPv6 addresses, so a device issuing traffic on both ipv4 and ipv6 can get twice what it deserves in terms of bandwidth, or more if it has multiple ipv6 addresses. My preferred solution to this (and part of the wireless problem) is to sort things out by source mac address. How to do that, remains a mystery. The way I'm leaning is to invent some sort of "src mac-to-id" filter that is global router-wide. I tend to view (in the home) as having 1/u network performance as the ideal. There are exceptions to this, notably video vs. say, bittorrent. A clever way of getting closer to 1/u might be to sense for more recent DNS queries and move that to a more interactive class. I got 1/d level performance, vs bittorrent, several months back, using a combination of HTB, and a two tier QFQ, then red model. I was happy with this, but QFQ was required. Perhaps I can make SFQRED do this with the right filters, or switch to a combination of DRR and SFQRED.... Anyway, at the present time, I'm trying a few approaches, the most promising one is a two or three tier model using SFQRED, with a very limited number of things prio 1 (dns), 2 (mostly everything), 3 classified and background traffic and torrent, where classifiable. Classification is a rathole however, and I'd rather be aiming for 1/d than 1/f. Regardless openwrt's default AQM does lousy queue depth management at present, and I expect to improve it tremendously over the coming week. --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net