From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) (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 AB0CD21F0A2 for ; Sun, 17 Mar 2013 12:12:17 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so4976814oag.15 for ; Sun, 17 Mar 2013 12:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=nwiPFfoeGso64B+Cp0ITsZgWPCEQhbg4fumuJjynZKU=; b=UJIdgXzbRbzhy1YgWTsuDi0ta+BWuviKWwTAzKnScIgG9aAJiHgbXiS+S9QLELhwGy Ea7xAvgr2ix5VFpPw4/3UKgf1TeNYEHsDBSTwmcDlbxWl1ym5bZhmzyBdKM2bdIIvcpq X7xbEe3VF0+qacoJIgq6/05thzNC4xlj1FTrwkFdwLmgm5/M/MydNuzPkLuXNbIQnYld JQ0CmL0ZAagbK8Z0GY+1OTa3cj+wGSYgf8McPs6sPcvCCVFiPeFThTToYxR9VxOB72yK gzYWOkCEq2fcFWtRQ/LZFdMv0ePg+ozVL/BO331R1pItPnW6KY6Wk6fQq8Fjw6RLCmp5 1WIA== MIME-Version: 1.0 X-Received: by 10.60.8.197 with SMTP id t5mr6029922oea.4.1363547536452; Sun, 17 Mar 2013 12:12:16 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.22.193 with HTTP; Sun, 17 Mar 2013 12:12:16 -0700 (PDT) Date: Sun, 17 Mar 2013 15:12:16 -0400 X-Google-Sender-Auth: FTMgJQsj-x_radOXtpS4D2bZ6p8 Message-ID: From: Jim Gettys To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=e89a8fb1ef428b771c04d823a618 Cc: Eric Dumazet , tsv-area@ietf.org, bloat , aqm@ietf.org Subject: [Bloat] Flow queuing performance (was: Re: [tsvwg] New Version Notification for draft-baker-tsvwg-aqm-recommendation-00.txt) 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: Sun, 17 Mar 2013 19:12:17 -0000 --e89a8fb1ef428b771c04d823a618 Content-Type: text/plain; charset=ISO-8859-1 To begin with, I tend to use the term 'flow queuing' to distinguish what we're doing with classic "fair queuing", which is overbound in most people's minds, and some of what we do is "unfair" by some metrics. Secondly, an extremely important factoid about why we got so excited about fq_codel (which is really DRR, in term derived from SFQ, combined with CoDel along with detecting thin vs. thick flows) is its performance: If my memory serves me correctly, Eric Dumazet has bench marked fq_codel, when running on a modern x86 processor with modern NIC's only takes a few percent of one x86 core at a 10gE rate. And we get higher total bandwidth over the link as a result. Eric, please correct me if I'm wrong, but you did say I could quote you! Similarly, Dave Taht reports when using fq_codel on CeroWrt (a 600mhz MIPS commodity home router), while the cost of running the fq_codel algorithm is visible in the performance traces, it's well down the list of what functions in Linux are taking the CPU time on that architecture, with huge latency benefits. As a result, at the last Linux Plumber's Conference in August, there was general consensus that we could replace PFIFO_FAST as the default qdisc in Linux, awaiting just our confidence that fq_codel (or something very similar) was mature enough for such a step. These two results demonstrated that on current general purpose architectures, an algorithm such as fq_codel is really do-able for the edge of the Internet. That is not the same statement as saying you can turn on existing implementations of various other fair queuing algorithms in existing big routers or not; just that on general purpose processors we know we can do with these algorithms immediately. I think we all need to reset our expectations from the 1990's where we took away the impression that SFQ/DRR etc were too expensive for deployment: today's general purpose systems are very different than those we had in that era, now often dominated by cache misses more than anything else. Everything we think we know about performance needs to be revisited in the light of modern architectures. Best regards, - JIm --e89a8fb1ef428b771c04d823a618 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
To begin with, I tend to use the term 'flow= queuing' to distinguish what we're doing with classic "fair q= ueuing", which is overbound in most people's minds, and some of wh= at we do is "unfair" by some metrics.

Secondly, an extremely important factoid about why we got so= excited about fq_codel (which is really DRR, in term derived from SFQ, com= bined with CoDel along with detecting thin vs. thick flows) is its performa= nce:

If my memory serves me correctly, Eric Dumazet has bench marked fq_code= l, when running on a modern x86 processor with modern NIC's only takes = a few percent of one x86 core at a 10gE rate. =A0And we get higher total ba= ndwidth over the link as a result. =A0Eric, please correct me if I'm wr= ong, but you did say I could quote you!

Similarly, Dave Taht reports when using fq_codel on CeroWrt (a 600mhz M= IPS commodity home router), while the cost of running the fq_codel algorith= m is visible in the performance traces, it's well down the list of what= functions in Linux are taking the CPU time on that architecture, with huge= latency benefits.

As a result, at the last Linux Plumber's Conference in August, ther= e was general consensus that we could replace PFIFO_FAST as the default qdi= sc in Linux, awaiting just our confidence that fq_codel (or something very = similar) was mature enough for such a step.

These two results demonstrated that on current general purpose architec= tures, an algorithm such as fq_codel is really do-able for the edge of the = Internet. =A0

That is not the same statement as saying y= ou can turn on existing implementations of various other fair queuing algor= ithms in existing big routers or not; just that on general purpose processo= rs we know we can do with these algorithms immediately.

I think we all need to reset our expectations from the 1990's where= we took away the impression that SFQ/DRR etc were too expensive for deploy= ment: today's general purpose systems are very different than those we = had in that era, now often dominated by cache misses more than anything els= e. =A0Everything we think we know about performance needs to be revisited i= n the light of modern architectures.
=A0 =A0 =A0 =A0 =A0 =A0 =A0Best regards,
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 - JIm
--e89a8fb1ef428b771c04d823a618--