On Wed, Dec 07, 2016 at 09:55:41PM +0900, Masashi Honma wrote: > >It's called mesh_sync_offset_adjust_tbtt() which matches more closely > >"TBTT adjustment" than "neighbor offset synchronization"? > > I think so. Because there is not any code creating "TBTT Adjustment Request > frame" even though the frame is required by "TBTT adjustment". This mesh_sync_offset_adjust_tbtt is definitely doing offset synchronization, so probably "tbtt" should be renamed "tsf" here. > >The code > >looks more like offset synchronization though. Perhaps there's some > >confusing and it's kinda doing both? > > In theory, updating the flag with 1) looks not correct because it is not > clearly defined in spec. > > In practice, I could consider extending the meaning of the flag over the > spec to use it to avoid referring the updating TSF value by peer as Thomas > said. I have took the statistics how many TSF drift > (ifmsh->sync_offset_clockdrift_max) happens. The attached file shows the > stats. The horizontal axis shows TSF drift time(usec) and vertical axis > shows how many time the drift occurred. The graph shows almost drifts are > under 20usec. In contrast, 2) could causes more than 1000usec drift. So 1) > looks not so large enough to protect with the flag. Yes, offset synchronization is (given decent clocks) supposed to be only for small tweaks. We will do it up to .8 ms drift though -- above .8 ms, we just reset drift to zero and adopt the new timing offset. You can see this kind of large "drift" by restarting a station. Actually, looking at the code now it doesn't make a lot of sense to set this flag for offset sync because TOFFSET_KNOWN flag is completely cleared whenever that is set, so we have to be forgetting the current t_offset all the time? -- Bob Copeland %% http://bobcopeland.com/
