TSFT

TSFT

[Simon Barber]

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

Re: TSFT

[David Young]

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

Re: TSFT

[Johannes Berg]

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

Re: TSFT

[David Young]

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

Re: TSFT

[Johannes Berg]

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

Re: TSFT

[Guy Harris]

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.

Re: TSFT

[Thomas Pedersen]

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

Re: TSFT

[Simon Barber]

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

Re: TSFT

[Johannes Berg]

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

Re: TSFT

[Simon Barber]

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
>

Re: TSFT

[Johannes Berg]

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