RadioTap Archive on
 help / color / Atom feed
From: David Young <>
To: Johannes Berg <>
	Simon Barber <>
Subject: Re: [RFC] capture file timestamping
Date: Tue, 25 Aug 2015 11:28:42 -0500
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Aug 25, 2015 at 12:07:09PM +0200, Johannes Berg wrote:
> Hi all,
> [Simon brought up a related topic a few years ago]
> We have a field for TSFT/mactime, which is defined as follows:
>     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.
> This is great, but not always feasible. Particularly when operating
> within multiple virtual interfaces and trying to record data from the
> hardware at the same time, the TSFT is either unobtainable or
> practically useless.

Can you explain why it is unobtainable or practically useless?

> Similarly, in actual monitor mode, there might not be a TSF timer -
> just a base hardware timer that is essentially free-running (though
> with the same frequency.)

I agree that it's not quite right to call it TSF time when there is not
actually any synchronization of stations.

> As Simon also found, the reference might not be the "first bit of the
> MPDU" (which I'd also say is actually somewhat vague with OFDM
> symbols), but something else entirely.

Hmm.  What's the reference for beacons and probe responses?

> There's also something that I'm not sure about - in 5/10 MHz channels,
> as I understand this is often achieved by running hardware timers at
> different frequencies - does that affect the timestamps hardware
> reports here?

Is it fair to say that you are generally concerned that not all hardware
can stamp received frames with something like a TSF time, but some
hardware can stamp frames with a time that is the "moral equivalent" for
certain purposes?

What are the use cases for the timestamps?  My use cases were these:

I. Measuring nanosecond intervals between several consecutive frames

        A. Using the measurements to verify settings of device registers

        B. Deriving from several intervals the meters distance
           between two 802.11 stations

II. Using the timestamps to place graphic representations of frames
    on a timeline

I can certainly imagine someone using hardware timestamps to put frames
back into the order they were received if the order was scrambled by,
for example, a multiprocessing network stack.


David Young    Urbana, IL    (217) 721-9981

  parent reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-25 10:07 Johannes Berg
     [not found] ` <>
2015-08-25 16:28   ` David Young [this message]
     [not found]     ` <>
2015-08-25 16:46       ` Johannes Berg
     [not found]         ` <>
2015-08-25 17:47           ` Guy Harris
     [not found]             ` <4E4FE63E-B636-4808-BBFF-6D2CE4EAFB2F-FrUbXkNCsVf2fBVCVOL8/>
2015-08-25 17:55               ` Johannes Berg
2015-08-26 22:48           ` Simon Barber
     [not found]             ` <>
2015-09-17 16:51               ` Johannes Berg

Reply instructions:

You may reply publicly 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 \ \ \ \ \ \

* 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