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. Plus the whole sleeping-receiver-STA-timeout-adjust-thing I mentioned earlier. Ugh, this whole timing stuff makes my head hurt o_0 >> 13.13.2.2.3 says: "The mesh STA checks if the transmitter of the >> Beacon frame or Probe Response frame is in the >> process of the TBTT adjustment (see 13.13.4.4.3). If the received >> frame contains the Mesh >> Configuration element and the TBTT Adjusting subfield in the Mesh >> Configuration field is 1, the >> mesh STA shall invalidate the Toffset value for this neighbor STA and >> shall not perform the >> following steps.". So it seems the TBTT Adjusting subfield referes to >> _this_ beacon? > > So here we are on the receiver side. This part is actually pretty clear from > 13.13.2.2.3. > _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
