From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ia0-x22d.google.com (ia-in-x022d.1e100.net [IPv6:2607:f8b0:4001:c02::22d]) (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 E799021F0F0 for ; Mon, 21 Jan 2013 10:20:31 -0800 (PST) Received: by mail-ia0-f173.google.com with SMTP id l29so2809729iag.32 for ; Mon, 21 Jan 2013 10:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yOjI+6Yycx6aS7AzIoU1I6xlNvZhf2Zn+p0uRqyZGcA=; b=PUSsU4n2DbWx3RWgNF3kBU6C6dovgA90yDjQj0ckNsW6TaH4HLO8NfBFWXFeXHxc/o LRBEu3rIJAjIM+GnpTn/4uYGkgIo2fco/CP18L0/OyLFG0CzbLdqvQB3aiaD+m3Q1aGP nChR5frFFfHDQBN4kJ19NyB7nAVjv80sYugRmuOQyD/YtZOCR5tbGHtpaBLsja1cHSSr CV8vYUh7UmuVtjNaO1UjAaN4O8epgl54ea53CD2XPfZxRUv5E7/vgi53nxvZefynuH+W z17pVfTwJ3Ld3Og6ay7oLX97l/Fz9t1y8XBqflYottfHhNsSoFnLe1tFKZ1lS6hjiebL SnxQ== MIME-Version: 1.0 X-Received: by 10.50.196.164 with SMTP id in4mr9305504igc.86.1358792430983; Mon, 21 Jan 2013 10:20:30 -0800 (PST) Received: by 10.64.135.39 with HTTP; Mon, 21 Jan 2013 10:20:30 -0800 (PST) In-Reply-To: References: Date: Mon, 21 Jan 2013 13:20:30 -0500 Message-ID: From: Dave Taht To: Robert Bradley Content-Type: multipart/alternative; boundary=14dae93405c92c1b7304d3d08459 Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] was filled with hope for killing the last traps, now have brick X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 18:20:32 -0000 --14dae93405c92c1b7304d3d08459 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thx, all! I do like the 24 hour a day development process. I can describe a problem, go to sleep, and have the answer in my mailbox with my first cup of coffee. Trying that patch again, with this last tweak, in about 14 minutes. Have to find a paperclip... A couple fixes to 6relayd arrived, simon clued me up a little bit on the dhcpv6 integration stuff, there was some ath9k tweaks. I have a much harder problem that I've been struggling with, which is the design and implementation of a priority scheme on top of nfq_codel, that lets you do classification without having a rate limiter like htb in line. There's also a few other features in there... the goal is to actually create something suitable as a replacement for PFIFO_FAST in every respect, and the biggest goal is to come up with something that does maximal mixing with the prioritization. I guess if I describe it better, perhaps I'll get to code that I could share around. Struggling with english a lot lately. I have a huge backlog of things I should be writing in that language, rather than C.... .... The two core issues with the design are that while I don't want to require htb, I WOULD like to have the ability to specify a rate, just like htb, however a zillion times simpler. If you want to shudder, read sch_htb.c and sch_cbq.c and sch_hfsc. The original cbq paper is a marvel in opacity. I just want something simple: tc qdisc add dev ge00 cake rate 24mbit and/or leverage the aggregate delay metrics across the queues to come up with an ongoing bandwidth estimate. My thought is, at the rates that home gateways run at, that we can do away with the concept of bursts, and just try to schedule packets on a really fine grained basis, and leverage the existing timestamping facilities in codel, and end up with something that's actually pretty efficient. The second issue is coming up with a weighting scheme that works. There are two scenarios here, one is simply diffserv, the other is doing saner things with multicast... What I have is the same 3 bin shaper that I've been using in simple_qos (but not needing htb!), with better diffserv support... I spent a week in modena with qfq's author trying to decomplexify qfq along the lines of fq_codel, but retaining the weight idea, and using real times (since we have 'em anyway) rather than virtual times. I failed. (doesn't mean I'm going to stop hacking at it, but the entire class structure has to go in order for my brain to stop hurting when I look at the code). I LIKE qfq, and there's a mildly more advanced version of it in the past few cuts of cerowrt. So I'm trying a simpler weighting scheme, and reviewing the literature for other fq schemes that might work. Anyway, if anyone's interested in decoding, in particular, how htb does it's watchdog and scheduling with the cpu packet delivery, I'd love that. On Mon, Jan 21, 2013 at 10:36 AM, Robert Bradley wrote: > You're right; it should indeed be "net_hdr_word(&addr[fn_bit >> 5]);". > That's my fault for not checking the patches thoroughly enough. I'm more > than a bit surprised the compiler accepted that code as-is... > > > On 21 January 2013 13:50, Ketan Kulkarni wrote: > >> Looking at the patch - >> >> - addr[fn_bit >> 5]; >> + net_hdr_word(addr[fn_bit >> 5]); >> >> Should the above line be - (& missing in the above line??) >> >> + net_hdr_word(&addr[fn_bit >> 5]); >> >> -Ketan >> >> On Mon, Jan 21, 2013 at 6:51 PM, Ketan Kulkarni >> wrote: >> > Well with this 3.7.3-1, I didnt see any crashes. I didnt change any >> > default config. >> > The router boots up well (in fact writing this mail through the same) >> > I also note I use IPv4 network only. >> > >> > I collected dmesg after booting up and kept here (in case required) - >> > http://pastebin.com/p1aM1aV8 >> > >> > -Ketan >> > >> > >> > On Mon, Jan 21, 2013 at 2:31 PM, Dave Taht wrote= : >> >> A build without that patch is now up here: >> >> >> >> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.3-1/ >> >> >> >> so 1/3 of the potential causes is not there.... >> >> >> >> On Mon, Jan 21, 2013 at 3:51 AM, Ketan Kulkarni >> wrote: >> >>> >> >>> Hi Dave, >> >>> Probably I can take a look later tonight by having serial cable - I >> >>> have that one handy. >> >>> What is the build and how to re-create the scenario? >> >>> >> >> >> >> Well, I hate to commit sources when stuff is obviously borked. If you >> >> want to try flashing with that you can figure out if it was us or the >> merge >> >> that went bad.... >> >> >> >> >> >> >> >> >> >>> >> >>> Thanks, >> >>> Ketan >> >>> >> >>> >> >>> On Mon, Jan 21, 2013 at 12:54 AM, Dave Taht >> wrote: >> >>> > Mine and Robert Bradley's latest attempt at killing the last ipv6 >> >>> > instruction traps >> >>> > with a rollup patch from bugs 419 and 421... >> >>> > >> >>> > brick the router. It boots, the main green light goes on, then it >> dies. >> >>> > Naturally >> >>> > I left the serial cable at the office... >> >>> > >> >>> > Of course in the middle of this patch set revision I also updated = to >> >>> > 3.7.3 >> >>> > and openwrt head, >> >>> > so have a few more variables than usual than just us to cope with. >> >>> > >> >>> > I would not mind eyeballs on this to see if there is an obvious >> flaw, >> >>> > otherwise I will progressively bisect from what was known to work >> >>> > forward as fast as I can. (besides, the hope is to submit this >> >>> > upstream) >> >>> > >> >>> > net_hdr_word is defined in the 902-unaligned_access_hacks patch in >> >>> > openwrt >> >>> > head... >> >>> > >> >>> > now off to find a small, sharp, pointy object... >> >>> > >> >>> > -- >> >>> > Dave T=E4ht >> >>> > >> >>> > Fixing bufferbloat with cerowrt: >> >>> > http://www.teklibre.com/cerowrt/subscribe.html >> >>> > >> >>> > _______________________________________________ >> >>> > Cerowrt-devel mailing list >> >>> > Cerowrt-devel@lists.bufferbloat.net >> >>> > https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >>> > >> >> >> >> >> >> >> >> >> >> -- >> >> Dave T=E4ht >> >> >> >> Fixing bufferbloat with cerowrt: >> >> http://www.teklibre.com/cerowrt/subscribe.html >> > > > > -- > Robert Bradley > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --14dae93405c92c1b7304d3d08459 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thx, all!

I do like the 24 hour a day development process. I can des= cribe a problem, go to sleep, and have the answer in my mailbox with my fir= st cup of coffee.

Trying that patch again, with this last tweak, in = about 14 minutes. Have to find a paperclip...

A couple fixes to 6relayd arrived, simon clued me up a little bit on th= e dhcpv6 integration stuff, there was some ath9k tweaks.

I have a mu= ch harder problem that I've been struggling with, which is the design a= nd implementation of a priority scheme on top of nfq_codel, that lets you d= o classification without having a rate limiter like htb in line. There'= s also a few other features in there... the goal is to actually create some= thing suitable as a replacement for PFIFO_FAST in every respect, and the bi= ggest goal is to come up with something that does maximal mixing with the p= rioritization.

I guess if I describe it better, perhaps I'll get to code that I co= uld share around. Struggling with english a lot lately. I have a huge backl= og of things I should be writing in that language, rather than C....

....

The two core issues with the design are that while I don= 9;t want to require htb, I WOULD like to have the ability to specify a rate= , just like htb, however a zillion times simpler. If you want to shudder, r= ead sch_htb.c and sch_cbq.c and sch_hfsc. The original cbq paper is a marve= l in opacity.

I just want something simple:

tc qdisc add dev ge00 cake rate 24= mbit

and/or leverage the aggregate delay metrics across the queues t= o come up with an ongoing bandwidth estimate.

My thought is, at the = rates that home gateways run at, that we can do away with the concept of bu= rsts, and just try to schedule packets on a really fine grained basis, and = leverage the existing timestamping facilities in codel, and end up with som= ething that's actually pretty efficient.

The second issue is coming up with a weighting scheme that works. There= are two scenarios here, one is simply diffserv, the other is doing saner t= hings with multicast... What I have is the same 3 bin shaper that I've = been using in simple_qos (but not needing htb!), with better diffserv suppo= rt...

I spent a week in modena with qfq's author trying to decomplexify q= fq along the lines of fq_codel, but retaining the weight idea, and using re= al times (since we have 'em anyway) rather than virtual times. I failed= .=A0 (doesn't mean I'm going to stop hacking at it, but the entire = class structure has to go in order for my brain to stop hurting when I look= at the code). I LIKE qfq, and there's a mildly more advanced version o= f it in the past few cuts of cerowrt.

So I'm trying a simpler weighting scheme, and reviewing the literat= ure for other fq schemes that might work.

Anyway, if anyone's in= terested in decoding, in particular, how htb does it's watchdog and sch= eduling with the cpu packet delivery, I'd love that.



On Mon, Jan 21, 2013 at 10:36 AM, Ro= bert Bradley <robert.bradley1@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
You're right; it should indeed be "net_hdr_word(&= amp;addr[fn_bit >> 5]);".=A0 That's my fault for not checkin= g the patches thoroughly enough.=A0 I'm more than a bit surprised the c= ompiler accepted that code as-is...


On 21 January 2013 13:50, Ketan Kulkarni <ketkulka@gmail= .com> wrote:
Looking at the patch -

- =A0 =A0 =A0 =A0 =A0 =A0 =A0addr[fn_bit >> 5];
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0net_hdr_word(addr[fn_bit >> 5]);

Should the above line be - (& missing in the above line??)

+ =A0 =A0 =A0 =A0 =A0 =A0 =A0net_hdr_word(&addr[fn_bit >> 5]);
-Ketan

On Mon, Jan 21, 2013 at 6:51 PM, Ketan Kulkarni <ketkulka@gmail.com> wrote:
> Well with this 3.7.3-1, I didnt see any crashes. I didnt change any > default config.
> The router boots up well (in fact writing this mail through the same)<= br> > I also note I use IPv4 network only.
>
> I collected dmesg after booting up and kept here (in case required) -<= br> > http://past= ebin.com/p1aM1aV8
>
> -Ketan
>
>
> On Mon, Jan 21, 2013 at 2:31 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> A build without that patch is now up here:
>>
>> http://snapon.lab.bufferbloat.net/~cero2/cerowrt= /wndr/3.7.3-1/
>>
>> so 1/3 of the potential causes is not there....
>>
>> On Mon, Jan 21, 2013 at 3:51 AM, Ketan Kulkarni <ketkulka@gmail.com> wrote:=
>>>
>>> Hi Dave,
>>> Probably I can take a look later tonight by having serial cabl= e - I
>>> have that one handy.
>>> What is the build and how to re-create the scenario?
>>>
>>
>> Well, I hate to commit sources when stuff is obviously borked. If = you
>> want to try flashing with that you can figure out if it was us or = the merge
>> that went bad....
>>
>>
>>
>>
>>>
>>> Thanks,
>>> Ketan
>>>
>>>
>>> On Mon, Jan 21, 2013 at 12:54 AM, Dave Taht <dave.taht@gmail.com> wrot= e:
>>> > Mine and Robert Bradley's latest attempt at killing t= he last ipv6
>>> > instruction traps
>>> > with a rollup patch from bugs 419 and 421...
>>> >
>>> > brick the router. It boots, the main green light goes on,= then it dies.
>>> > Naturally
>>> > I left the serial cable at the office...
>>> >
>>> > Of course in the middle of this patch set revision I also= updated to
>>> > 3.7.3
>>> > and openwrt head,
>>> > so have a few more variables than usual than just us to c= ope with.
>>> >
>>> > I would not mind eyeballs on this to see if there is an o= bvious flaw,
>>> > otherwise I will progressively bisect from what was known= to work
>>> > forward as fast as I can. (besides, the hope is to =A0sub= mit this
>>> > upstream)
>>> >
>>> > net_hdr_word is defined in the 902-unaligned_access_hacks= patch in
>>> > openwrt
>>> > head...
>>> >
>>> > now off to find a small, sharp, pointy object...
>>> >
>>> > --
>>> > Dave T=E4ht
>>> >
>>> > Fixing bufferbloat with cerowrt:
>>> > http://www.teklibre.com/cerowrt/subscribe.html
>>> >
>>> > _______________________________________________
>>> > Cerowrt-devel mailing list
>>> > Cerowrt-devel@lists.bufferbloat.net
>>> > https://lists.bufferbloat.net/listinfo/cerowrt-de= vel
>>> >
>>
>>
>>
>>
>> --
>> Dave T=E4ht
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html



--
Robert Bradley



--
Dave T=E4ht

Fixi= ng bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.ht= ml=20 --14dae93405c92c1b7304d3d08459--