<div dir="ltr"><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Dave Taht</b> <span dir="ltr"><<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>></span><br>Date: Tue, Mar 17, 2015 at 7:41 AM<br>Subject: Re: Dave's wishlist [was: Source-specific routing merged]<br>To: Juliusz Chroboczek <<a href="mailto:jch@pps.univ-paris-diderot.fr">jch@pps.univ-paris-diderot.fr</a>><br>Cc: "<a href="mailto:babel-users@lists.alioth.debian.org">babel-users@lists.alioth.debian.org</a>" <<a href="mailto:babel-users@lists.alioth.debian.org">babel-users@lists.alioth.debian.org</a>>, Gabriel Kerneis <<a href="mailto:gabriel@kerneis.info">gabriel@kerneis.info</a>>, Steven Barth <<a href="mailto:cyrus@openwrt.org">cyrus@openwrt.org</a>>, Henning Rogge <<a href="mailto:hrogge@gmail.com">hrogge@gmail.com</a>>, Paul McKenney <<a href="mailto:paulmck@linux.vnet.ibm.com">paulmck@linux.vnet.ibm.com</a>>, Felix Fietkau <<a href="mailto:nbd@nbd.name">nbd@nbd.name</a>><br><br><br><div dir="ltr"><div><div>My quest is always for an extra "9" of reliability. Anyplace where you can make something more robust (even if it is out at the .9999999999) level, I tend to like to do in order to have the highest MTBF possible in combination with all the other moving parts on the spacecraft (spaceship earth).<br></div><br></div>One of the reasons why I love paul mckenney so much is that he deeply cares about stuff that happens only one in a billion times.<br><br>From this blog post of his: <a href="http://paulmck.livejournal.com/37782.html" target="_blank">http://paulmck.livejournal.com/37782.html</a><br><div><div><br>"I quickly learned that the bug is difficult to reproduce, requiring 
something like 100 hours of focused rcutorture testing.  Bisection based
 on 100-hour tests would have consumed the remainder of 2014 and a 
significant fraction of 2015, so something better was required.  In 
fact, something <i>way</i> better was required because there was only a 
very small number of failures, which meant that the expected test time 
to reproduce the bug might well have been 200 hours or even 300 hours 
instead of my best guess of 100 hours."<div><div class="gmail_extra"><br></div><div class="gmail_extra">so, thus, I get picky on system daemons.<br><br></div><div class="gmail_extra"><div class="gmail_quote"><span class="">On Tue, Mar 17, 2015 at 4:45 AM, Juliusz Chroboczek <span dir="ltr"><<a href="mailto:jch@pps.univ-paris-diderot.fr" target="_blank">jch@pps.univ-paris-diderot.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 1) Did the issue with procd ever get resolved? (sighup I think it was)<br>
<br>
Gabriel, Steven?  Can procd be configured not to send SIGHUP, or shall<br>
I add an option to babeld to ignore it?  (Currently babeld terminates on<br>
SIGHUP, and I like it that way, since it prevents a babeld from sticking<br>
around after you log off.)<br></blockquote><div><br></div></span><div>this basically logjammed on this issue. Either procd needed to be modified to be able to<br></div><div>send an arbitrary signal, or babel changed to take sighup as a reload.<br><br></div><div>I'd done the simple patch to babel.<br><br></div><div>But I understand your use case also (stop routing on hup via remote access), and have never poked into procd. Perhaps it could be changed to take a var for the actual signal number it uses per daemon, but I will argue that has overhead the openwrt devs would be loathe to take. But: I will look. Babel can't be the only thing that needs a different signal to reload...<br><br></div><div>a third way out is just to patch babel for openwrt...<br></div><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 2) got the new vars into openwrt, or shall I do?<br></blockquote><div><br></div></span><div>rtt branch had 2 new vars as best as I recall, and I envisioned the babels package being retired, which as best as I recall has extra vars like src-eq.<br><br></div><div>Secondly the command lines would get complex on me, and I figured just re-writing the conf file was saner than command line args. Get a sigWHATEVER reload (or mmap) the conf file, checksum it against the previous version, do nothing if it didn't change.<br></div><div> <br></div><div>Thirdly, having an openwrt specific uci and/or ubus parser that could be compiled in would be more reliable than a script, simpler and faster. I can try to find funding for doing that... (in like 1.7's timeframe!!) I looked over the libubus and libuci interfaces and staggered away confused. <br><br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Gabriel?<br>
<br>
> ecn<br>
<br>
No, since I don't understand why you think that setting ECN on Babel<br>
packets makes sense.  (It might make sense to set ECN on some Babel<br>
packets -- the ones that are marked as "urgent" -- but I'm interested in<br>
hearing your reasoning.)<br></blockquote><div><br></div></span><div>fq_codel is the default on openwrt. ECN is enabled on that. Basic ECN marking is 2 characters of new code. (tracking it harder, but that's boilerplate code now). hnetd is presently very dumb about coalescing /60s out of /64s...  I'd like to be trying much faster update schedules on ethernet as per some of the discussion on homenet.<br><br>But, let me take this subject to another thread than this.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> atomic route updates<br>
<br>
Ausgeschlossen.  </blockquote><div><br></div><div>Nothing is impossible.<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Last time I tried, I got a number of complaints that it<br>
broke operational networks.<br></blockquote><div><br></div></span><div>As the new FIB table patches have landed in linux 4.0 and later, it has done some odd things with RCU that I am not sure would be a good thing with the present delete+add routes system everything like quagga+ babel seems to use.<br><br>I'd written about it here while discussing the amazing new FIB patches (7x reductions in lookup time or more), but was not aware that henning had actually got atomic route updates that worked. <br><br><a href="http://lists.openwall.net/netdev/2015/03/11/136" target="_blank">http://lists.openwall.net/netdev/2015/03/11/136</a><br><br></div><div>So, perhaps autodetection of some sort here, also, would be of help.<br></div><div> <br></div><div>And figuring out why it used to break.<br><br></div><div>And ooh! atomic route changes! no packet loss at all! Look at that extra 9!<br><br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It's also less important than it used to be, since the hysteresis<br>
algorithm in 1.5.0 dramatically reduced the number of route switches --<br>
current versions of Babel should not be loosing a measurable number of<br>
packets due to non-atomic switches.<br></blockquote><div><br></div></span><div>How many 9s do you want?<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> IPV6_SUBTREES autodetection<br>
<br>
That should definitely be a runtime option.  Matthieu?<br>
<br>
Not so sure about autodetection, Steven, Henning, do you have any ideas?<span><font color="#888888"><br></font></span></blockquote><div><br></div></span><div>My thought here was to try to insert and then retrieve a route that would fail if IPV6_SUBTREES was not defined in the kernel.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><font color="#888888">
-- Juliusz<span class="HOEnZb"><font color="#888888"><br>
</font></span></font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div>Dave Täht<br>Let's make wifi fast, less jittery and reliable again!<br><br><a href="https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb" target="_blank">https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb</a><br></div>
</font></span></div></div></div></div></div>
</div><br><br clear="all"><br>-- <br><div class="gmail_signature">Dave Täht<br>Let's make wifi fast, less jittery and reliable again!<br><br><a href="https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb" target="_blank">https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb</a><br></div>
</div>