On Wed, Dec 11, 2013 at 3:31 AM, Marco Porsch <[email protected]> wrote: > I am not perfectly sure if the TBTT Adjusting subfield is used correctly now. > It would be good to clarify what it is really used for. > > a) the TBTT Adjusting subfield shows that _the next beacon_ will be delayed > due to clock drift adjustment > b) the TBTT Adjusting subfield shows that _this beacon_ is delayed due to > clock drift adjustment > > a) makes more sense in my perspective: > - to a sleeping peer STA it hints that it should expect the next beacon to be > delayed (to adjust wakeup timers/timeouts) > - 13.13.2.2.3 says a peer STA "shall invalidate the T_offset value for this > neighbor STA and shall not perform [T_offset and T_ClockDrift calculation]". > On next beacon receipt with new timing and without the TBTT Adjusting > subfield it will start recording valid T_offset values again. In case b) it > would waste one valid T_offset value.
Agreed, except if we follow a) and the TSF adjustment (if the pre-tbtt interrupt delay is large enough) happens before the actual (now-delayed) TBTT, receiving peers will incorrectly interpret TSF adjustment as clock drift. It is unfortunate we have to punt TSF adjustment to the workqueue, but either way I think it makes sense for the adjust_tbtt callback to advertise TSF adjustment in the beacon right away. Thomas _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
