This is the current definition of TSFT: "Value in microseconds of the MAC's 64-bit 802.11 Time Synchronization Function timer when the first bit of the MPDU arrived at the MAC. For received frames only." My experience with TSFT is with Atheros cards, which record the timestamp at the end of the frame, not the start. Do you know the behaivour of any particular capture systems re: TSFT - where do they timestamp the frame? Furthermore for DSSS/CCK the definition above is reasonable, but for OFDM and HT (802.11n) the SIGNAL field (part of the PLCP header, not part of the MPDU) is part of the first data symbol. It would be much clearer to change the definition to state that the timestamp is at the start of this first SIGNAL/data symbol. Any objections to doing this, or preference to change the reference point to a different part of the frame? In my wireshark patch I've added options to interpret TSFT as the start of end of the frame. Simon
On Fri, Nov 16, 2012 at 10:26:31PM -0800, Simon Barber wrote: > This is the current definition of TSFT: > > "Value in microseconds of the MAC's 64-bit 802.11 Time > Synchronization Function timer when the first bit of the MPDU > arrived at the MAC. For received frames only." > > My experience with TSFT is with Atheros cards, which record the > timestamp at the end of the frame, not the start. Interesting. Is it consistent across the whole Atheros product line? > Furthermore for DSSS/CCK the definition above is reasonable, but for > OFDM and HT (802.11n) the SIGNAL field (part of the PLCP header, not > part of the MPDU) is part of the first data symbol. It would be much > clearer to change the definition to state that the timestamp is at > the start of this first SIGNAL/data symbol. Any objections to doing > this, or preference to change the reference point to a different > part of the frame? > > In my wireshark patch I've added options to interpret TSFT as the > start of end of the frame. I think we need 1) a methodology for an author to identify their device's reference point so that they can calibrate their driver to the standard and/or 2) a radiotap datum that identifies the reference point in use or 3) something entirely different. Dave -- David Young dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org Urbana, IL (217) 721-9981
On Sat, 2012-11-17 at 00:48 -0600, David Young wrote: > On Fri, Nov 16, 2012 at 10:26:31PM -0800, Simon Barber wrote: > > This is the current definition of TSFT: > > > > "Value in microseconds of the MAC's 64-bit 802.11 Time > > Synchronization Function timer when the first bit of the MPDU > > arrived at the MAC. For received frames only." > > > > My experience with TSFT is with Atheros cards, which record the > > timestamp at the end of the frame, not the start. > > Interesting. Is it consistent across the whole Atheros product line? Pretty much. > > Furthermore for DSSS/CCK the definition above is reasonable, but for > > OFDM and HT (802.11n) the SIGNAL field (part of the PLCP header, not > > part of the MPDU) is part of the first data symbol. It would be much > > clearer to change the definition to state that the timestamp is at > > the start of this first SIGNAL/data symbol. Any objections to doing > > this, or preference to change the reference point to a different > > part of the frame? > > > > In my wireshark patch I've added options to interpret TSFT as the > > start of end of the frame. > > I think we need 1) a methodology for an author to identify their > device's reference point so that they can calibrate their driver to the > standard and/or 2) a radiotap datum that identifies the reference point > in use or 3) something entirely different. FWIW, for the Atheros drivers we *just* added (1) to the Linux kernel, but for radiotap output we calculate the difference to the start of the frame, see here: http://git.kernel.org/?p=linux/kernel/git/jberg/mac80211-next.git;a=commit;h=f4bda337bbb6e245e2a07f344990adeb6a70ff35 (the patches for the drivers are separate, but simply change the _START flag to _END) I have no objections to (also) allowing this information to be in radiotap though, but I'm not sure we want to? Our (Intel's) device for example has the "on air rise" timestamp which is different again, so we could potentially end up with at least three different reference points? OTOH, I don't see more than these three making sense at all... johannes
On Sat, Nov 17, 2012 at 09:45:50AM +0100, Johannes Berg wrote: > On Sat, 2012-11-17 at 00:48 -0600, David Young wrote: > > On Fri, Nov 16, 2012 at 10:26:31PM -0800, Simon Barber wrote: > > > In my wireshark patch I've added options to interpret TSFT as the > > > start of end of the frame. > > > > I think we need 1) a methodology for an author to identify their > > device's reference point so that they can calibrate their driver to the > > standard and/or 2) a radiotap datum that identifies the reference point > > in use or 3) something entirely different. > > FWIW, for the Atheros drivers we *just* added (1) to the Linux kernel, > but for radiotap output we calculate the difference to the start of the > frame, see here: > > http://git.kernel.org/?p=linux/kernel/git/jberg/mac80211-next.git;a=commit;h=f4bda337bbb6e245e2a07f344990adeb6a70ff35 > > (the patches for the drivers are separate, but simply change the _START > flag to _END) Adjusting the NIC's TSFT in this way, so that the radiotap reference point is according to spec, sounds right to me. > I have no objections to (also) allowing this information to be in > radiotap though, but I'm not sure we want to? Given that the adjustment is easy, I'm pretty sure we should not waste radiotap header space to describe the TSFT. Wireshark doesn't already have more than two "interpretation modes" for radiotap headers, does it? That would be too bad. I realize that there may be already be a mode for a particular OS.... Dave -- David Young dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org Urbana, IL (217) 721-9981
On Sat, 2012-11-17 at 11:46 -0600, David Young wrote: > > > > In my wireshark patch I've added options to interpret TSFT as the > > > > start of end of the frame. > Given that the adjustment is easy, I'm pretty sure we should not waste > radiotap header space to describe the TSFT. > > Wireshark doesn't already have more than two "interpretation modes" for > radiotap headers, does it? That would be too bad. I realize that there > may be already be a mode for a particular OS.... As I understood it, Simon is saying that he's adding one, but since he's using Linux, which will have the adjustment in a matter of days, it probably won't be necessary after all. johannes
On Nov 17, 2012, at 9:46 AM, David Young <dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org> wrote: > Wireshark doesn't already have more than two "interpretation modes" for > radiotap headers, does it? That would be too bad. I realize that there > may be already be a mode for a particular OS.... That's the only preference setting Wireshark's radiotap dissection code has. The OS in question is OpenBSD, as per http://www.radiotap.org/rejected-fields/FCS%20in%20header OpenBSD's other collisions are 15 for hardware queue: http://www.radiotap.org/suggested-fields/hardware%20queue rather than TX flags: http://www.radiotap.org/suggested-fields/TX%20flags and RSSI: http://www.radiotap.org/suggested-fields/RSSI rather than RTS retries: http://www.radiotap.org/suggested-fields/RTS%20retries but the latter two are suggested fields rather than defined fields. We could, I guess, define a "standard radiotap" link-layer type header value, and have dissectors that look at flags above 13 always handle those in the standard fashion and have programs that process radiotap headers in files either have a preference to control how to interpret the existing radiotap link-layer header type or just wire in one of the choices. I don't know whether that's worth the effort.
Hi Simon, On Fri, Nov 16, 2012 at 10:26 PM, Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> wrote: > This is the current definition of TSFT: > > "Value in microseconds of the MAC's 64-bit 802.11 Time Synchronization > Function timer when the first bit of the MPDU arrived at the MAC. For > received frames only." > > My experience with TSFT is with Atheros cards, which record the timestamp at > the end of the frame, not the start. There is already a patch in mac80211-next which accounts for this and normalizes frame TSFT to beginning of frame. > Do you know the behaivour of any particular capture systems re: TSFT - where > do they timestamp the frame? > > Furthermore for DSSS/CCK the definition above is reasonable, but for OFDM > and HT (802.11n) the SIGNAL field (part of the PLCP header, not part of the > MPDU) is part of the first data symbol. It would be much clearer to change > the definition to state that the timestamp is at the start of this first > SIGNAL/data symbol. Any objections to doing this, or preference to change > the reference point to a different part of the frame? Keeping the TSFT at start of MPDU is cleaner from the user's point of view. > In my wireshark patch I've added options to interpret TSFT as the start of > end of the frame. I'm not sure which patch you're referring to, but it seems cleaner to handle normalizing TSFT to a single reference in the kernel. Thomas
Unfortunately this patch does not do a very accurate calculation, so it
makes the problem worse. It simply multiplies rate by the number of
bits to get a time. This does not take into account the limited
accuracy in rate (11n has fractional rates), nor does it consider the
rounding into blocks caused by FEC, or symbols. As a result the data is
made worse by the current code. Either the code should do an accurate
fix, or it should record the raw value and let the end user correct it
properly.
Simon
On Sat 17 Nov 2012 03:26:05 PM PST, Thomas Pedersen wrote:
> Hi Simon,
>
> On Fri, Nov 16, 2012 at 10:26 PM, Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> wrote:
>> This is the current definition of TSFT:
>>
>> "Value in microseconds of the MAC's 64-bit 802.11 Time Synchronization
>> Function timer when the first bit of the MPDU arrived at the MAC. For
>> received frames only."
>>
>> My experience with TSFT is with Atheros cards, which record the timestamp at
>> the end of the frame, not the start.
>
> There is already a patch in mac80211-next which accounts for this and
> normalizes frame TSFT to beginning of frame.
>
>> Do you know the behaivour of any particular capture systems re: TSFT - where
>> do they timestamp the frame?
>>
>> Furthermore for DSSS/CCK the definition above is reasonable, but for OFDM
>> and HT (802.11n) the SIGNAL field (part of the PLCP header, not part of the
>> MPDU) is part of the first data symbol. It would be much clearer to change
>> the definition to state that the timestamp is at the start of this first
>> SIGNAL/data symbol. Any objections to doing this, or preference to change
>> the reference point to a different part of the frame?
>
> Keeping the TSFT at start of MPDU is cleaner from the user's point of view.
>
>> In my wireshark patch I've added options to interpret TSFT as the start of
>> end of the frame.
>
> I'm not sure which patch you're referring to, but it seems cleaner to
> handle normalizing TSFT to a single reference in the kernel.
>
> Thomas
On Sat, 2012-11-17 at 23:20 -0800, Simon Barber wrote:
> Unfortunately this patch does not do a very accurate calculation, so it
> makes the problem worse. It simply multiplies rate by the number of
> bits to get a time. This does not take into account the limited
> accuracy in rate (11n has fractional rates), nor does it consider the
> rounding into blocks caused by FEC, or symbols. As a result the data is
> made worse by the current code. Either the code should do an accurate
> fix, or it should record the raw value and let the end user correct it
> properly.
If we can, I'd say we should fix the calculations.
The question is how we define it when the first bit of the MPDU can be
fractional in a symbol?
johannes
One problem with fixing the calculations is that quite a lot of
information is needed to do the calculation correctly. In Intel's case I
don't know if Ness information is available, and this makes upto a 16us
difference in the PLCP header length.
Calculating the start of the MPDU from the end accurately requires
knowing the FEC scheme, the MCS, the guard interval, the bandwidth. Is
the FEC scheme known, or are all current cards only supporting BCC?
Do you know if Intel supports extension spatial streams? If not the
number is always 0. And FEC - is it always BCC?
Simon
On 11/18/2012 03:07 AM, Johannes Berg wrote:
> On Sat, 2012-11-17 at 23:20 -0800, Simon Barber wrote:
>> Unfortunately this patch does not do a very accurate calculation, so it
>> makes the problem worse. It simply multiplies rate by the number of
>> bits to get a time. This does not take into account the limited
>> accuracy in rate (11n has fractional rates), nor does it consider the
>> rounding into blocks caused by FEC, or symbols. As a result the data is
>> made worse by the current code. Either the code should do an accurate
>> fix, or it should record the raw value and let the end user correct it
>> properly.
>
> If we can, I'd say we should fix the calculations.
>
> The question is how we define it when the first bit of the MPDU can be
> fractional in a symbol?
>
> johannes
>
On Tue, 2012-11-20 at 14:43 -0800, Simon Barber wrote: > One problem with fixing the calculations is that quite a lot of > information is needed to do the calculation correctly. In Intel's case I > don't know if Ness information is available, and this makes upto a 16us > difference in the PLCP header length. > > Calculating the start of the MPDU from the end accurately requires > knowing the FEC scheme, the MCS, the guard interval, the bandwidth. Is > the FEC scheme known, or are all current cards only supporting BCC? Good question, I don't really know. > Do you know if Intel supports extension spatial streams? If not the > number is always 0. And FEC - is it always BCC? I don't think our devices support extension spatial streams or anything but BCC. Overall though, I think there's an argument to be made here for simply introducing a new radiotap timestamp field that gives the timestamp at the end of the frame? This could be defined better and would be more accurate. I'm not sure I'd want to redefine the existing field in any way since there are probably a whole bunch of implementations out there that just stick whatever timestamp they have into the field, without regard for where it is in the frame, and without regard for aggregation. johannes