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 <robert.bradley1@gmail.com> 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 <ketkulka@gmail.com> 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 <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)
> 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 <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 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 <dave.taht@gmail.com> 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äht
>>> >
>>> > 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äht
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html



--
Robert Bradley



--
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html