Thx, all!<br><br>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.<br><br>Trying that patch again, with this last tweak, in about 14 minutes. Have to find a paperclip...<br>
<br>A couple fixes to 6relayd arrived, simon clued me up a little bit on the dhcpv6 integration stuff, there was some ath9k tweaks.<br><br>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.<br>
<br>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....<br>
<br>....<br><br>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.<br>
<br>I just want something simple:<br><br>tc qdisc add dev ge00 cake rate 24mbit<br><br>and/or leverage the aggregate delay metrics across the queues to come up with an ongoing bandwidth estimate.<br><br>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. <br>
<br>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...<br>
<br>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.<br>
<br>So I'm trying a simpler weighting scheme, and reviewing the literature for other fq schemes that might work.<br><br>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.<br>
<br><br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 10:36 AM, Robert Bradley <span dir="ltr"><<a href="mailto:robert.bradley1@gmail.com" target="_blank">robert.bradley1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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...<br>

</div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On 21 January 2013 13:50, Ketan Kulkarni <span dir="ltr"><<a href="mailto:ketkulka@gmail.com" target="_blank">ketkulka@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Looking at the patch -<br>
<br>
-              addr[fn_bit >> 5];<br>
+              net_hdr_word(addr[fn_bit >> 5]);<br>
<br>
Should the above line be - (& missing in the above line??)<br>
<br>
+              net_hdr_word(&addr[fn_bit >> 5]);<br>
<br>
-Ketan<br>
<div><div><br>
On Mon, Jan 21, 2013 at 6:51 PM, Ketan Kulkarni <<a href="mailto:ketkulka@gmail.com" target="_blank">ketkulka@gmail.com</a>> wrote:<br>
> Well with this 3.7.3-1, I didnt see any crashes. I didnt change any<br>
> default config.<br>
> The router boots up well (in fact writing this mail through the same)<br>
> I also note I use IPv4 network only.<br>
><br>
> I collected dmesg after booting up and kept here (in case required) -<br>
> <a href="http://pastebin.com/p1aM1aV8" target="_blank">http://pastebin.com/p1aM1aV8</a><br>
><br>
> -Ketan<br>
><br>
><br>
> On Mon, Jan 21, 2013 at 2:31 PM, Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>> wrote:<br>
>> A build without that patch is now up here:<br>
>><br>
>> <a href="http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.3-1/" target="_blank">http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.3-1/</a><br>
>><br>
>> so 1/3 of the potential causes is not there....<br>
>><br>
>> On Mon, Jan 21, 2013 at 3:51 AM, Ketan Kulkarni <<a href="mailto:ketkulka@gmail.com" target="_blank">ketkulka@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi Dave,<br>
>>> Probably I can take a look later tonight by having serial cable - I<br>
>>> have that one handy.<br>
>>> What is the build and how to re-create the scenario?<br>
>>><br>
>><br>
>> Well, I hate to commit sources when stuff is obviously borked. If you<br>
>> want to try flashing with that you can figure out if it was us or the merge<br>
>> that went bad....<br>
>><br>
>><br>
>><br>
>><br>
>>><br>
>>> Thanks,<br>
>>> Ketan<br>
>>><br>
>>><br>
>>> On Mon, Jan 21, 2013 at 12:54 AM, Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>> wrote:<br>
>>> > Mine and Robert Bradley's latest attempt at killing the last ipv6<br>
>>> > instruction traps<br>
>>> > with a rollup patch from bugs 419 and 421...<br>
>>> ><br>
>>> > brick the router. It boots, the main green light goes on, then it dies.<br>
>>> > Naturally<br>
>>> > I left the serial cable at the office...<br>
>>> ><br>
>>> > Of course in the middle of this patch set revision I also updated to<br>
>>> > 3.7.3<br>
>>> > and openwrt head,<br>
>>> > so have a few more variables than usual than just us to cope with.<br>
>>> ><br>
>>> > I would not mind eyeballs on this to see if there is an obvious flaw,<br>
>>> > otherwise I will progressively bisect from what was known to work<br>
>>> > forward as fast as I can. (besides, the hope is to  submit this<br>
>>> > upstream)<br>
>>> ><br>
>>> > net_hdr_word is defined in the 902-unaligned_access_hacks patch in<br>
>>> > openwrt<br>
>>> > head...<br>
>>> ><br>
>>> > now off to find a small, sharp, pointy object...<br>
>>> ><br>
>>> > --<br>
>>> > Dave Täht<br>
>>> ><br>
>>> > Fixing bufferbloat with cerowrt:<br>
>>> > <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a><br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > Cerowrt-devel mailing list<br>
>>> > <a href="mailto:Cerowrt-devel@lists.bufferbloat.net" target="_blank">Cerowrt-devel@lists.bufferbloat.net</a><br>
>>> > <a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel" target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
>>> ><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Dave Täht<br>
>><br>
>> Fixing bufferbloat with cerowrt:<br>
>> <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br>Robert Bradley
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br>Dave Täht<br><br>Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a>