Javier, We are testing the mobility aspects of 802.11s, and we try and simulate a link failing. We want to simulate a single mobile node that is moving away from node B towards node C. At some point the connection to B fails and the traffic needs to be re-routed through node C. We have tried turning off node B, next we will try blocking peering with node B, but is this the best way to simulate a node connection failing due to loss of signal? We want to accurately measure the 're-routing' time due to a link failure.
Thx, Y- On Thu, Apr 19, 2012 at 10:34 AM, Javier Cardona <[email protected]> wrote: > 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 >
_______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
