On Thu, Dec 12, 2013 at 9:05 AM, Marco Porsch <[email protected]> wrote: > On 12/12/2013 05:50 PM, Marco Porsch wrote: >> On 12/11/2013 10:00 PM, Thomas Pedersen wrote: >>> On Wed, Dec 11, 2013 at 12:57 PM, Thomas Pedersen <[email protected]> >>> wrote: >>>> 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. >>> >>> Sorry I misunderstood your question, you were asking about the meaning >>> of the TBTT Adjusting subfield. >> >> Sorry, I should have mentioned earlier that I see a) and b) from the >> perspective of the transmitter, not that of the receiver. So on the >> transmitters side I see a) as announce-before-doing and b) as >> announce-while-doing. >> >> And my guess is that the standard intends a) while the current patch >> implements b). > > I see, this is all a bit mind-boggling. I'll make a little example of the > difference between a) and b) below. > > o = transmitted on time (last TBTT + beacon interval) > d = delayed (last TBTT + beacon interval + X) > > Transmitter | a) | b) | Receiver's tasks according to > 13.13.2.2.3 > -----------------------------+----+----+--------------------------------------------- > tx beacon 1 (subfield clear) | o | o | record new T_offset and calculate > T_ClockDrift > tx beacon 2 (subfield set) | o | d | invalidate T_offset > tx beacon 3 (subfield set) | d | d | invalidate T_offset > tx beacon 4 (subfield clear) | d | o | record new T_offset but do nothing > else > tx beacon 5 (subfield clear) | o | o | record new T_offset and calculate > T_ClockDrift > > Mind that the last delayed (d) beacon actually has the newly aquired, > now-steady TBTT. So in case b) one beacon (beacon 3) is wasted, as the > receiver still invalidates T_offset instead of recording it.
OK thanks for the example, I see your point. I guess we could accomplish a) by simply scheduling a beacon rebuild in adjust_tbtt, this work _should_ then be run after the beacon interrupt returns (the old beacon has been returned). In 13.13.4.4.3 however, it looks like the adjusting STA should immediately set the adjusting TBTT subfield in the upcoming beacon: "The mesh STA shall set the TBTT Adjusting field in the Mesh Configuration element to 1 in order to announce that the TBTT adjustment procedure is ongoing. " and "Upon completion of the TBTT adjustment, the mesh STA shall update the status number as described in 13.13.4.2.4 and shall set the TBTT Adjusting field in the Mesh Configuration element to 0. " Since these sections don't mention anything about _next_ beacon, twiddling that bit in pre-tbtt seems to accomplish this. It still makes sense to pre-empt the TBTT adjust advertisement by a beacon, except if the pre-tbtt delay is large enough, the tsf adjust work may (or may not!) take place before the real tbtt :/. Shall we at least be consistent for now and advertise TBTT adjust state for _this_ beacon? The _next_ beacon advertisement can always be introduced in a later patch, but it seems to require some more work. > Plus the whole sleeping-receiver-STA-timeout-adjust-thing I mentioned earlier. I don't think this is really an issue, since the max allowable TSF adjustment is 0.04% (!) of the beacon period, and the default awake window is like 10TU? > Ugh, this whole timing stuff makes my head hurt o_0 Glad I'm not the only one :) -- Thomas _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
