RadioTap Archive on
 help / color / Atom feed
From: Simon Barber <>
To: Thomas Pedersen <thomas-W/>
Cc: ""
Subject: Re: TSFT
Date: Sat, 17 Nov 2012 23:20:29 -0800
Message-ID: <> (raw)
In-Reply-To: <>

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 


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 <> 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

  reply index

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-17  6:26 TSFT Simon Barber
     [not found] ` <>
2012-11-17  6:48   ` TSFT David Young
     [not found]     ` <20121117064848.GO21779-Gq8g4XVd89tWk0Htik3J/>
2012-11-17  8:45       ` TSFT Johannes Berg
     [not found]         ` <>
2012-11-17 17:46           ` TSFT David Young
     [not found]             ` <20121117174600.GQ21779-Gq8g4XVd89tWk0Htik3J/>
2012-11-17 18:43               ` TSFT Johannes Berg
2012-11-17 18:56               ` TSFT Guy Harris
2012-11-17 23:26   ` TSFT Thomas Pedersen
2012-11-18  7:20     ` Simon Barber [this message]
     [not found]       ` <>
2012-11-18 11:07         ` TSFT Johannes Berg
     [not found]           ` <>
2012-11-20 22:43             ` TSFT Simon Barber
     [not found]               ` <>
2012-11-21 10:42                 ` TSFT Johannes Berg

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \
    --cc=thomas-W/ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

RadioTap Archive on

Archives are clonable:
	git clone --mirror radiotap/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 radiotap radiotap/ \
	public-inbox-index radiotap

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone