From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com [209.85.215.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 790E8202229; Mon, 7 Nov 2011 11:56:41 -0800 (PST) Received: by eyb6 with SMTP id 6so5685558eyb.16 for ; Mon, 07 Nov 2011 11:56:39 -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; bh=zJfBgPNM+ugB2y9ThOoiiort80F4S/W0Pq49NOR53Xc=; b=r5Shd6QoLvMBUrbgOowSOMipO37N+U5WF4KWXFfmRhzcjmvzeKEZn711/r6Zd2UU/P 1HfifARNioDhOkwaePGJU0axo4L1qD4c5qL5UmfYnBiPVeVCHJ4N8Ru0SVL8dKWCN/Ts PZ0gKUhFiFRXkOw5Ladd7XJ4cOrI1OB2c6alI= MIME-Version: 1.0 Received: by 10.182.225.3 with SMTP id rg3mr9386436obc.77.1320695799333; Mon, 07 Nov 2011 11:56:39 -0800 (PST) Received: by 10.182.15.40 with HTTP; Mon, 7 Nov 2011 11:56:38 -0800 (PST) In-Reply-To: <20111107192517.GH2798@tuxdriver.com> References: <20111107192517.GH2798@tuxdriver.com> Date: Mon, 7 Nov 2011 20:56:38 +0100 Message-ID: From: Dave Taht To: "John W. Linville" Content-Type: multipart/alternative; boundary=f46d044469f3f9c2bc04b12a73af Cc: bloat-devel , bloat Subject: Re: [Bloat] what I think is wrong with eBDP in debloat-testing 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, 07 Nov 2011 19:56:42 -0000 --f46d044469f3f9c2bc04b12a73af Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 7, 2011 at 8:25 PM, John W. Linville wr= ote: > On Mon, Nov 07, 2011 at 08:10:57PM +0100, Dave Taht wrote: > > > John was right when he wrote in the initial announcement: > > > > "This version runs separate instances of the algorithm for each WMM > > queue -- I reckon that makes sense. " > > > > and it doesn't. > > > > "I still ignore HT aggregation, as I'm pretty sure I don't understand > > how it really effects the issue." > > > > Messes it up completely. > > So, can I drop that patch from debloat-testing now? :-) > > Yea, drop it. (also drop the ancient ath9k patch. It was always wrong) However, the timestamping/ewma/completion components of the idea are good, although a couple improvements could be made. 1) Getting kernel time is pretty high overhead. And that clock wanders. There's a nice, handy TSF clock part of every wireless device that is stabler (I think) and could be used instead. I don't know if all devices make it independently available from the hardware. A) exported from the driver up into the mac80211 driver to where a packet scheduler/classifier (net/sched/whatever) could get at it. or B) made available as a separate clocksource using the clocksource API. and C) tsf timestamp packets on entry to ndo_select_queue before handing off and up to the scheduler. Granularity doesn't need to be better than a TU so it doesn't need to read from the hardware directly every time. The kernel makes no guarantees about how the clock relates to anything other than the hardware itself... In other words, how to get that clock's timestamp up into a place where the packet scheduler can use it is something of a problem, easily solved, however getting at that clocksource back at a packet scheduler layer is mildly harder. 2) Also station id is needed (something more hashable and < 32 bits than a mac addr) AND a few fields from minstrel's per-sta info - which is really hard to get at on a per packet basis, as it's under a rcu) Felix and I discussed starting to wedge a structure into the otherwise mostly unused 'user-defined' 48 byte space in a skb in that section of the mac80211 code and I kind of prefer to just add more fields to the bql stuff... if I knew what they all were. Which I don't. 3) Completions per station would be a useful abstraction to have also wedged into that structure... > -- > John W. Linville Someday the world will need a hero, and y= ou > linville@tuxdriver.com might be all we have. Be ready. > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net --f46d044469f3f9c2bc04b12a73af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Nov 7, 2011 at 8:25 PM, John W. = Linville <li= nville@tuxdriver.com> wrote:
On Mon, Nov 07, 2011 at 08:10:57PM +0100, Dave Taht wrote= :

> John was right when he wrote in the initial announcement:
>
> "This version runs separate instances of the algorithm for each W= MM
> queue -- I reckon that makes sense. "
>
> and it doesn't.
>
> "I still ignore HT aggregation, as I'm pretty sure I don'= t understand
> how it really effects the issue."
>
> Messes it up completely.

So, can I drop that patch from debloat-testing now? =A0:-)


Yea, drop it. (also drop the ancient ath9k patch. It was always= wrong)

However, the timestamping/ewma/completion components of the = idea are good, although a couple improvements could be made.

1) Getting kernel time is pretty high overhead. And that clock wanders.= There's a nice, handy TSF clock part of every wireless device that is = stabler (I think) and could be used instead. I don't know if all device= s make it independently available from the hardware.

A) exported from the driver up into the mac80211 driver to where a pack= et scheduler/classifier (net/sched/whatever) could get at it.

or
=
B) made available as a separate clocksource using the clocksource API.<= br>
and C) tsf timestamp packets on entry to ndo_select_queue before handin= g off and up to the scheduler.

Granularity doesn't need to be be= tter than a TU so it doesn't need to read from the hardware directly ev= ery time.
The kernel makes no guarantees about how the clock relates to anything othe= r than the hardware itself...

In other words, how to get that clock&= #39;s timestamp up into a place where the packet scheduler can use it is so= mething of a problem, easily solved, however getting at that clocksource ba= ck at a packet scheduler layer is mildly harder.

2) Also station id is needed (something more hashable and < 32 bits = than a mac addr) AND a few fields from minstrel's per-sta info - which = is really hard to get at on a per packet basis, as it's under a rcu)
Felix and I discussed starting to wedge a structure into the otherwise = mostly unused 'user-defined' 48 byte space in a skb in that section= of the mac80211 code and I kind of prefer to just add more fields to the b= ql stuff... if I knew what they all were. Which I don't.

3) Completions per station would be a useful abstraction to have also w= edged into that structure...


=A0
--
John W. Linville =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Someday the world will need= a hero, and you
linville@tuxdriver.com =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0might be all we have. =A0Be ready.



--
Dave T=E4= ht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferblo= at.net
--f46d044469f3f9c2bc04b12a73af--