> 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. > 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. I don't think that flooding PREQ for resolved path not necessary a good case for all. Thanks ---- Chun-Yeow -- 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
