Hi Yile, > On Thu, Apr 12, 2012 at 5:08 PM, Thomas Pedersen <[email protected]> wrote: >> If B never sent a peering close when shutting down, A will tear down >> the peer link after ~15 failed transmissions.
On Thu, Apr 19, 2012 at 8:33 AM, Yile Ku <[email protected]> wrote: > So if we turn off a node it will take 15 seconds to > find another path..? 15 failed transmissions only equals 15 seconds if you are sending 1 data frame per second. In our tests with audio streams the path switch takes ~250ms, and that is with the default mesh configuration parameters. You could tune your network to do better than that. Cheers, Javier > On Thu, Apr 12, 2012 at 5:08 PM, Thomas Pedersen <[email protected]> wrote: >> >> Hi Yile, >> >> On Thu, Apr 12, 2012 at 3:26 PM, Yile Ku <[email protected]> wrote: >> > I have 4 nodes A,B,C, & D. I have A set to not directly connect to D. >> > Attached to D I have a web based camera. I have a laptop hooked to >> > node A that I can log into the camera using a browser. I can >> > connect to the camera okay going through node B. I shut off node B >> > and the video session dies. I assume that 802.11s would switch the >> > route of traffic to go through node C, but it doesn't appear to do >> > that. I tried settting the root node flag on both A and D but that >> > did not help. >> > >> > I tried pinging directly from A to the camera attached to D. Here is >> > a list of ping times: >> > 64 bytes from 192.168.0.224: seq=63 ttl=64 time=1.950 ms >> > 64 bytes from 192.168.0.224: seq=64 ttl=64 time=1.992 ms >> > 64 bytes from 192.168.0.224: seq=65 ttl=64 time=2.877 ms >> > 64 bytes from 192.168.0.224: seq=66 ttl=64 time=1.963 ms >> > 64 bytes from 192.168.0.224: seq=67 ttl=64 time=526.659 ms >> > 64 bytes from 192.168.0.224: seq=68 ttl=64 time=6.892 ms >> > 64 bytes from 192.168.0.224: seq=69 ttl=64 time=1.979 ms >> > 64 bytes from 192.168.0.224: seq=70 ttl=64 time=2.867 ms >> > 64 bytes from 192.168.0.224: seq=71 ttl=64 time=1.968 ms >> > 64 bytes from 192.168.0.224: seq=72 ttl=64 time=1.961 ms >> > 64 bytes from 192.168.0.224: seq=77 ttl=64 time=506.990 ms >> > 64 bytes from 192.168.0.224: seq=78 ttl=64 time=3.043 ms >> > 64 bytes from 192.168.0.224: seq=79 ttl=64 time=1.954 ms >> > 64 bytes from 192.168.0.224: seq=80 ttl=64 time=3.768 ms >> > 64 bytes from 192.168.0.224: seq=81 ttl=64 time=3.913 ms >> > 64 bytes from 192.168.0.224: seq=82 ttl=64 time=4.725 ms >> > 64 bytes from 192.168.0.224: seq=83 ttl=64 time=57.908 ms >> > 64 bytes from 192.168.0.224: seq=84 ttl=64 time=6.435 ms >> > 64 bytes from 192.168.0.224: seq=85 ttl=64 time=1.968 ms >> > 64 bytes from 192.168.0.224: seq=86 ttl=64 time=1.974 ms >> > 64 bytes from 192.168.0.224: seq=87 ttl=64 time=1.956 ms >> > 64 bytes from 192.168.0.224: seq=88 ttl=64 time=1.960 ms >> > 64 bytes from 192.168.0.224: seq=89 ttl=64 time=1.994 ms >> > 64 bytes from 192.168.0.224: seq=90 ttl=64 time=2.010 ms >> > 64 bytes from 192.168.0.224: seq=91 ttl=64 time=2.848 ms >> > 64 bytes from 192.168.0.224: seq=92 ttl=64 time=22.417 ms >> > 64 bytes from 192.168.0.224: seq=93 ttl=64 time=3.196 ms >> > 64 bytes from 192.168.0.224: seq=94 ttl=64 time=1.975 ms >> > 64 bytes from 192.168.0.224: seq=95 ttl=64 time=12.603 ms >> > 64 bytes from 192.168.0.224: seq=96 ttl=64 time=9.577 ms >> > 64 bytes from 192.168.0.224: seq=97 ttl=64 time=2.065 ms >> > 64 bytes from 192.168.0.224: seq=98 ttl=64 time=9.883 ms >> > 64 bytes from 192.168.0.224: seq=99 ttl=64 time=8.772 ms >> > 64 bytes from 192.168.0.224: seq=100 ttl=64 time=8.407 ms >> > 64 bytes from 192.168.0.224: seq=101 ttl=64 time=7.967 ms >> > 64 bytes from 192.168.0.224: seq=102 ttl=64 time=9.332 ms >> > 64 bytes from 192.168.0.224: seq=103 ttl=64 time=6.949 ms >> > ^C >> > --- 192.168.0.224 ping statistics --- >> > 104 packets transmitted, 72 packets received, 30% packet loss >> > round-trip min/avg/max = 1.917/32.764/526.659 ms >> > root@OpenWrt:/# ping 192.168.0.224 >> > PING 192.168.0.224 (192.168.0.224): 56 data bytes >> > 64 bytes from 192.168.0.224: seq=0 ttl=64 time=2.238 ms >> > 64 bytes from 192.168.0.224: seq=1 ttl=64 time=1.965 ms >> > 64 bytes from 192.168.0.224: seq=2 ttl=64 time=7.304 ms >> > 64 bytes from 192.168.0.224: seq=3 ttl=64 time=2.824 ms >> > 64 bytes from 192.168.0.224: seq=8 ttl=64 time=425.330 ms >> > 64 bytes from 192.168.0.224: seq=9 ttl=64 time=3.783 ms >> > 64 bytes from 192.168.0.224: seq=10 ttl=64 time=2.353 ms >> > 64 bytes from 192.168.0.224: seq=11 ttl=64 time=2.337 ms >> > >> > >> > The ping times vary greatly. why? >> >> This is likely related to the path refresh timer. While an mpath is >> refreshing, it is marked as deactivated. We try to pre-empt this and >> it seems to work most of the time, but perhaps starting the path >> refresh 1 second before deactivating is not enough time? See >> mesh_nexthop_lookup() and hwmp_rann_frame_process(). >> >> > Also how can I get it to switch fast from B to C when routing from A to >> > D? >> >> Does A never switch from B to C, or does it just take a while? >> If B never sent a peering close when shutting down, A will tear down >> the peer link after ~15 failed transmissions. Depending on the type of >> traffic, this might take a while. See ieee80211s_update_metric() in >> net/mac80211/status.c >> >> Patches welcome. >> >> Thomas >> _______________________________________________ >> Devel mailing list >> [email protected] >> http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel > > > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel > -- Javier Cardona cozybit Inc. http://www.cozybit.com _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
