Hi Bharat, See my answers below. Regards ///jon
Bharat Joshi wrote: > Hi, > > I have a question on link-state events in TIPC. I understand that > a link state starts with Unknown-Unknown and becomes Working-Working > when the link is UP. > > I see a timer is created for timing out link state. This is set > to continuty interval which is around 250ms. > > Now I have enabled link debugs and see a link toggelling between > WW and WU with timeout events. Following debugs are seen: > > WW/TIM -> WU > WU/TRF-ACT -> WW > RR/ TIM > > I also see that when link is in working-working state and a > timeout event happens, we sent a 'State' message which when received > in Working-Unknown state by the peer, it moves to Working-Working > state. > > I am a little confused here. Is this mechanism used to verify if > link is up or not? > Yes, it is. A link endpoint remains in WW as long as it receives packets of any type from the peer endpint . If it hasn't received anything during a whole continuation interval, it sets the endpoint state to WU, meaning "own endpoint is working, but peer endpoint's state is unknown", and then sends out a 'state' message with the 'probe' bit set. This bit forces the other endpoint to respond immediately, so the link can be set back to WW. Note that the link is still usable when one of its endpoints is in WU, - packets can be sent and received as normal, and any packet reception will put the link back to WW. > Also It seems to me that 250 ms for continuty interval may be > small. What value people think could be a good value for this? > This value is only indirectly configurable. What you configure is "link tolerance", which is set by default to 1500 ms for Ethernet. The continuity interval is calculated as 1/4 of this. This is to allow the timer to expire several times, and hence send a number of probes within a tolerance interval, before the link is declared failed(=RU). If we relied on only one unresponde probe, the link would end up being reset unnecessarily, e.g. during periods of net congestion and high loss rate. > Thanks, > Bharat > > PS: I am not on the TIPC list so it would be great if you can reply to > this id as well. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > tipc-discussion mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tipc-discussion > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
