> > Instead of stopping path discovery when a path is found continue > > attempting to find paths until we hit the > > dot11MeshHWMPmaxPREQretries limit. > > Let think about that if you have more nodes, you will probably flood > the networks with more mgmt frame than previous implementation. It > also increases the latency for data to be sent. Yes, it will cause more management packets to be sent. PREQs will flood out dot11MeshHWMPmaxPREQretries times and PREPs will be sent back but only along the best path. No it will not cause additional latency. Imagine a classic challenging topology for mesh routing: four or more nodes arranged into a U where we want to route from one end of the U to the other end. But the short direct hop is very bad and the links along the U are all excellent. Before what would happen is that we would first hear a PREP from the direct hop (because the packets don't have to travel as far). We'd then select that route because it has newer information than what we had previously. If we got a PREP from the long path we'd then switch to that because it is just as new and a better metric. But the longer that path the greater the chance that we'll lose either a PREQ or a PREP. And because the PHY doesn't retransmit management packets this happens rather often in practice. And if we periodically refresh paths as currently happens we have even more opportunities to select the wrong path. Of course using multiple hops sucks but it sucks even more to use a 5 Mbps link when 50 Mbps links are available. > > This is important because path messages are not reliable and it is > > relatively common to have a short bad path to the destination along > > with a longer but better path. With the original code rather often a > > path message along the long path would be lost so we would stick > > with the > bad path. > > With this change we have a greater chance to get messages over the > > longer path allowing us to select the long path if it's better. > > Try to take a look on the dot11MeshHWMPpreqMinInterval > (mesh_hwmp_preq_min_interval) and > (mesh_hwmp_active_path_timeout). I think that you can probably have > more aggressive path selection interval by modifying these two values. Not entirely sure what you mean about being more aggressive. If you mean sending out the PREQs more rapidly that is something I have gone back and forth on. My current thinking is to do a few attempts quickly to try and get a good path immediately and then lengthen the delay to try to compensate for noise bursts. > I don't think that flooding PREQ for resolved path not necessary a good > case> > for all. Thanks It's just as important to do multiple discoveries for an established path as for a brand new path. In either case if we send one PREQ out we'll often fail to choose the right path. > Chun-Yeow -- Jesse -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
