[Cerowrt-devel] was filled with hope for killing the last traps, now have brick

Dave Taht dave.taht at gmail.com
Mon Jan 21 13:20:30 EST 2013 

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 at 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 at 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 at 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 at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20130121/291234f7/attachment-0002.html>

More information about the Cerowrt-devel mailing list