From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from comxexch02.comx.local (nat-server.lanfw.cxnet.dk [87.72.215.201]) by huchra.bufferbloat.net (Postfix) with ESMTP id C784F200840 for ; Sat, 14 Jan 2012 08:45:13 -0800 (PST) Received: from 172.31.1.117 ([172.31.1.117]) by comxexch02.comx.local ([172.31.1.117]) with Microsoft Exchange Server HTTP-DAV ; Sat, 14 Jan 2012 16:35:31 +0000 Date: Sat, 14 Jan 2012 17:35:28 +0100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <042401ccd2da$881e7f33$75011fac@comx.local> From: "Jesper Dangaard Brouer" X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [Bloat] What is fairness, anyway? was: Re: finally... winning on wired! Thread-Index: AczS2ogec929uUVnTCm4kuHdSRic+w== To: "Dan Siemon" , "bloat" MIME-Version: 1.0 Subject: Re: [Bloat] What is fairness, anyway? was: Re: 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: Sat, 14 Jan 2012 16:45:15 -0000 Hi Dan=0A= =0A= It delights me to see that you are using TC options linklayer ADSL and = overhead (from my ADSL optimizer work), in your qos scripts :)=0A= =0A= Cheers,=0A= Jesper Brouer=0A= =0A= Dan Siemon skrev:=0A= =0A= On Sun, 2012-01-08 at 01:40 +0100, Dave Taht wrote: > On Thu, Jan 5, 2012 at 6:52 PM, Bob Briscoe = wrote: > > > > In a nutshell, bit-rate equality, where each of N active users gets = 1/N of > > the bit-rate, was found to be extremely _unfair_ when the activity = of > > different users is widely different. For example: > > * 5 light users all active 1% of the time get close to 100% of a = shared link > > whenever they need it. > > * However, if instead 2 of these users are active 100% of the time, = FQ gives > > the other three light users only 33% of the link whenever they are = active. > > * That's pretty rubbish for a solution that claims to isolate each = user from > > the excesses of others. >=20 > Without AQM or FQ, we have a situation where one stream from one user > at a site, can eat more than 100% of the bandwidth. >=20 > 1/u would be a substantial improvement! Indeed I've found this to be the case. I've been using a Linux tc configuration in both the upstream and downstream which is designed to protect each host's bandwidth share and within that provide three traffic classes with flow fairness (script link below). With this configuration I no longer have to worry about other network traffic interfering with a decent web experience or VoIP call. http://git.coverfire.com/?p=3Dlinux-qos-scripts.git;a=3Dblob;f=3Dsrc-3tos= .sh;hb=3DHEAD --=20 Key ID: 133F6C3E Key Fingerprint: 72B3 AF04 EFFE 65E4 46FF 7E5B 9297 18BA 133F 6C3E _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat