On Wed, Dec 07, 2016 at 09:55:41PM +0900, Masashi Honma wrote:

quoted

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.

quoted

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/