Hi Chun-Yeow and Tosoni, Thank you for giving me the information I needed and it was helpful. I appreciate your time.
Best regards, Siva. Hi, Siva > > > t = 4 + 5 = 9 seconds? (Considering the timeout to be 5 seconds). > > It will expire at t = 6 seconds. > > As far as I know, the timer is kicked start when the PREQ is generated > (also depends on time that PREP is received) and decremented even if > you don't have data to send. So if the PREQ is generated at t=1, it > will expired at t=6 assuming active path timeout is 5 seconds. So if > you don't have the data to send at t=5, the path timeout is still > happen at t=6, > > You can check this using "iw <mesh interface> mpath dump" in the EXPTIME. > > > again, from your previous reply, but not unicast PREQ to D? > > Yes. It should be re-broadcast again to find an optimal path > (different path maybe use) once the path is timeout. Unicast PREQ or > individually addressed PREQ is used to reply to the RANN generated by > root mesh node for proactive mode as defined by the standard. > > > least metric value. My question is: does HWMP protocol guarantee best > metric > > (low metric value) path all the time? > How you collect the metric value? > > > Furthermore, how often is metric value updated or rather how often does > HWMP > > protocol reads the metric value? > The metric is updated whenever we received PREQ and PREP. > > Perhaps, others may comment as well. > > ---- > Chun-Yeow > > Hi list, Siva, > > > My question is: does HWMP protocol guarantee best metric (low metric > value) path all the time? > > "all the time" no, since the PREQ/PREP are exchanged only every ~5 seconds. > During the interval the path may degrade. > > Also, currently, the computed airtime metric does not follow exactly > 802.11-2012; It uses a simplified algorithm. That might lead to computing > suboptimal paths. > > JP Tosoni > > > >
_______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
