On Sat, Mar 4, 2017 at 12:01 PM, Chun-Yeow Yeoh <yeohchuny...@gmail.com> wrote: > >> >> Well A-D is going to have a much smaller RTT than A-B-C-D. And, yes, using >> multiple hops is going to reduce throughput but I'd much rather use >> multiple >> 120 Mbps links than a link that only supports 12 Mbps. >> > > Airtime link metrics should choose the multiple links if it is good compared > to direct link. > >> That's why there are link and path metrics. > > I don't think that you don't get this. Every nodes sends out multiple PREQs. > Other nodes received it with rebroadcast again. Take note on this. > >> Improving the link metric isn't going to help with PREQ reliability >> problems. > > PREQ realiabilit? It is broadcast management frame and usually using lowest > transmission rate. So it is realiabe. > >> Sending more PREQs will. > > So reduce dot11MeshHWMPpreqMinInterval to send out more PREQ works for you?
Alright, I think that we have similar lengthy discussion last time. http://comments.gmane.org/gmane.linux.kernel.wireless.general/139453 I would suggest the following edition to the commit message: Instead of stopping path discovery when a path is established, continue the attempts to find alternative paths until we hit the dot11MeshHWMPmaxPREQretries limit. However, this is not a standard behavior and may easily increase the number of broadcast PREQ frame in your network. So this feature is turned off by default. and the remaining are removed due to misleading explanation. Then, in the mesh_path_timer, I think that only the following is needed: - if (mpath->flags & MESH_PATH_RESOLVED || - (!(mpath->flags & MESH_PATH_RESOLVING))) { + if (!multiple_discoveries && + (mpath->flags & MESH_PATH_RESOLVED || + (!(mpath->flags & MESH_PATH_RESOLVING)))) { Thanks --- Chun-Yeow
