On Wed, Jul 20, 2016 at 4:01 AM, Machani, Yaniv <yanivma@xxxxxx> wrote: > On Tue, Jul 19, 2016 at 19:01:54, Yeoh Chun-Yeow wrote: >> Johannes Berg >> Subject: Re: [PATCH v2 2/3] mac80211: mesh: improve path resolving >> time >> >> On Tue, Jul 19, 2016 at 9:43 PM, Bob Copeland <me@xxxxxxxxxxxxxxx> >> wrote: >> > On Tue, Jul 19, 2016 at 01:02:13PM +0000, Machani, Yaniv wrote: >> >> On Tue, Jul 19, 2016 at 15:44:56, Bob Copeland wrote: >> > >> > This wording seems to indicate that it is not per path. Perhaps >> > this should be clarified in the standard. (If the intent turns out >> > to be per path, then I guess we should fix it by storing last_preq >> > per path >> > instead.) >> > >> > >> > Ignoring the standard for a second, let's explore this: can you give >> > some idea on how many stations are in your target network, how >> > frequently a given pair of nodes unpeer, what sort of improvements >> > you see with the patch? It should then be pretty easy to run some >> > simulations to see the scenarios where this helps and where it hurts. >> > >> > > Bob, Chun-Yeow, > Thanks for your inputs. > > Let take a simple scenario, where you have a,b,c,d nodes connected to each other as shown below. > > A~ ~ ~~~~C- - - D > \ / > \ / > B > > A would like to pass data to D. > A-C matric is worse than A-B-C, so path is constructed via B. > We are in idle state, and PREQ are sent every dot11MeshHWMPpreqMinInterval. > Now, node B have been disconnected (ran out of battery/shut down/suddenly went out of range) > As A has a path to D via B, he cleans up his path table. > Now he needs to build a new path, in the WCS, he have just sent a PREQ. > And now he needs to wait dot11MeshHWMPpreqMinInterval seconds, until he can rebuild the path. Did you reduce the dot11MeshHWMPactivePathTimeout to see whether it produces positive impact to your network? Once the path to A - C - D has established, it needs to wait till the active path timer to expire before establishing a new path. This active path time is default to 5000 TUs (or 5s). > As we wouldn't like to flood the network with PREQ, we can assume that the dot11MeshHWMPpreqMinInterval is few seconds, for us, it seemed un-acceptable. > But your patch is indeed generating "more" PREQ frame. > In cases where you need to have a reliable data link, passing audio/video you usually can't afford few seconds w/o traffic. > >> In addition to Bob's comment, you probably can try to reduce the >> dot11MeshHWMPpreqMinInterval to 1 TU (1ms) instead of sticking to >> default value 10 TUs. Besides, you can also reduce the >> mesh_path_refresh_time which is currently default to 1000 ms and check >> whether you can improve on your network scenarios. >> > > We did tried to play with these values, but again, we don't want to flood the network. > We just want to recover ASAP. > >> When you mentioned "next hop peer disconnect", it could also be the >> time taken to re-established the mesh peering before your mesh STA can >> transmit the data to your peer mesh STA. >> > > Link establishment takes no more than few 100s of ms usually, > And in the example above, there is no new link establishment, just path generation. > Suggest that you simulate your scenario and validate the improvement first. --- 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
