On Mon, Apr 25, 2016 at 4:33 PM, Juliusz Chroboczek
wrote:
>> A good question would be, what would the ideal time between tests be
>> for the network to stablize? 3 minutes? At least in one series I'd
>> started tests back to back, and didn't kick in the drop link
> A good question would be, what would the ideal time between tests be
> for the network to stablize? 3 minutes? At least in one series I'd
> started tests back to back, and didn't kick in the drop link stuff at
> the right times.
SOURCE_GC_TIME is 200
hold time is 3.5 * update_interval
so
and in other news the odroid c2's current kernel, and the rpi3 and
rpi2, now all do IPV6_SUBTREES correctly.
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Tee-hee! Don't overanalyze yet!, that was not a strictly repeatable
test, as yet. (if you want access to the testbed send me a ssh key)
A good question would be, what would the ideal time between tests be
for the network to stablize? 3 minutes? At least in one series I'd
started tests back to
> http://blog.cerowrt.org/post/failing_over_faster/
Why does the first stream fail at time 120? Broken firewall?
There's something wrong in the second stream -- you're falling back in
30s, which is a tad high. Can i please see your babeld.conf?
-- Juliusz
> http://blog.cerowrt.org/post/failing_over_faster/
Nice.
Could you please add a caption to the figures, and link the tags to
the images (I know, I can get the full-size figures by opening the target
of the tag).
-- Juliusz
___
Babel-users mailing
Thank ghu we aren't homenet! Wires are dead! :)
I will incorporate your comments later today. Until then, there's
pictures and data now up at:
http://blog.cerowrt.org/post/failing_over_faster/
I am quite puzzled as to how long it takes to fail over even in the
good cases. I guess I gotta take
> 8+ years ago, with ahcp and babel, and a network configured to use
> that with a single static ip address on both the ethernet and wifi, I
> could do that. My own networks were setup that way, anyway... I did it
> all the time. It was wonderful. I never had to think about it.
Dave, the plan is
>> Babeld is already monitoring netlink messages (see funciton filter_netlink
>> in kernel_netlink), but it looks like this mechanism is not working in
>> your particular case. I'll try to reproduce the issue, but I don't own
>> a Raspberry Pi.
> Maybe the typical problem with IFF_UP and
This ended up being a deeply philosophical digression into routing
behaviors that I think I'll have to blog about, with pictures, to
fully describe.
What I want is a world of ubiquitous always-on connectivity[1] - where
you can be at your desk with 20 connections nailed up, listening to an
audio
On Sun, Apr 24, 2016 at 11:12 PM, Juliusz Chroboczek
wrote:
>> http://stackoverflow.com/questions/7225888/how-can-i-monitor-the-nic-statusup-down-in-a-c-program-without-polling-the-ker
>
> Babeld is already monitoring netlink messages (see funciton filter_netlink
>
> http://stackoverflow.com/questions/7225888/how-can-i-monitor-the-nic-statusup-down-in-a-c-program-without-polling-the-ker
Babeld is already monitoring netlink messages (see funciton filter_netlink
in kernel_netlink), but it looks like this mechanism is not working in
your particular case. I'll
groovy. I will try it as soon as I can
This showed some potential for doing it faster than that:
http://stackoverflow.com/questions/7225888/how-can-i-monitor-the-nic-statusup-down-in-a-c-program-without-polling-the-ker
On Sun, Apr 24, 2016 at 1:21 PM, Juliusz Chroboczek
> # and we fail over in 32 seconds
What happens if you apply the following patch?
diff --git a/babeld.c b/babeld.c
index 3127e72..0183b32 100644
--- a/babeld.c
+++ b/babeld.c
@@ -744,7 +744,7 @@ main(int argc, char **argv)
if(timeval_compare(_interfaces_timeout, ) < 0) {
I am fiddling with a rasberry pi3 with a usb ethernet (making it a
100mbit router), the onboard wifi, and 2 usb wifi sticks...
with all the interfaces up I do a ping over ethernet
64 bytes from 172.26.64.231: icmp_seq=56 ttl=63 time=1.45 ms
64 bytes from 172.26.64.231: icmp_seq=57 ttl=63
15 matches
Mail list logo