From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.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 4E342200372 for ; Mon, 2 Jan 2012 13:31:46 -0800 (PST) Received: by iagw33 with SMTP id w33so43293428iag.16 for ; Mon, 02 Jan 2012 13:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XsyN+JpWIt6FcoSwiLrfKitXYeZV/CW+sZ88iaNCA1Q=; b=DuMjjB9x3Nz3fua4BcXtA7cZonhKQ+hCKzFx0MIDOX5kHpIcTI7z+uqRxQ1ZqWYw9g 0lf62ZeOZoBc8oHtiMJ2Sy/HQFqVM0dx8P1jK41lwhkUudwHWhA4xiBAmzbLaJlzh9lq cYiWVnpe1+wdRgqLj8kfUKJXpG7Eet2mmujnE= MIME-Version: 1.0 Received: by 10.50.182.130 with SMTP id ee2mr59444051igc.30.1325539905239; Mon, 02 Jan 2012 13:31:45 -0800 (PST) Received: by 10.231.159.193 with HTTP; Mon, 2 Jan 2012 13:31:45 -0800 (PST) In-Reply-To: References: <1325481751.2526.23.camel@edumazet-laptop> Date: Mon, 2 Jan 2012 22:31:45 +0100 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] finally... winning on wired! 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: Mon, 02 Jan 2012 21:31:46 -0000 On Mon, Jan 2, 2012 at 9:07 AM, Dave Taht wrote: > On Mon, Jan 2, 2012 at 6:22 AM, Eric Dumazet wro= te: >> Please try the patch I posted this morning to solve this SFQ bug. Yes, that patch brings SFQ at light workloads to being indistinguishable from QFQ! http://www.teklibre.com/~d/bloat/sfqnewvsqfq10iperfs.png (if you stare at this image long enough you might see a pattern, but I don'= t) (I certainly am seeing an afterimage, though) >>A "nolimit" implementation could use a dynamic memory allocator >> scheme, eventually consuming less memory on typical use :) At what point could SFQ be considered a replacement for pfifo_fast? :) I have not managed to crash QFQ yet with your other new patch. I will run it overnight. There are new versions (bql-14) of both the net-next kernel and cerowrt up = at: http://huchra.bufferbloat.net/~d/bql/ http://huchra.bufferbloat.net/~cero1/bql-smoketests/ incorporating your SFQ and QFQ patches. About the only kernel problem I have left to check for is some issues with routing /27 and /32 netmasks I had a few weeks back. * (for our studio audience) while I'm DELIGHTED to see SFQ be 4x less latent now... It is important to remain cognizant of just how much better SFQ and QFQ are vs a vs the default PFIFO_FAST, for latency under load. In the 10 iperf case, *65* times better. The difference between 2 ms and 11= 0ms is quite perceptible by a human, and all sorts of important stuff - voice, = dns, new connections leap to the head of the queue with either qdisc. So, to give a concrete example - a DNS lookup takes about 16ms on my system= , and a new connection to google takes about 55 ms - so with QFQ/SFQ inside of the *delay I formerly experienced* (under this load) - I get connected to web sites, and fairly often - their entire web pages. Also ssh 'feels' much better. Voice works much better. --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net