Re: [RFC] capture file timestamping

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.

Dave

-- 
David Young
[email protected]    Urbana, IL    (217) 721-9981