Re: [RFC] capture file timestamping

[Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>]

On Tue, 2015-08-25 at 11:28 -0500, David Young wrote:

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

If you have two stations, for example, you need to have synchronisation
with the two different APs, so you can have two vastly different TSF
values. Maybe your device gives those to you, or maybe not. It may make
sense for some analysis to look at that, but if you need to look at
timing inside the device to be evident then this is 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.

It's not really a major defect though.

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

First symbol containing the first bit of the timestamp field, I
believe. Haven't double-checked now.

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

Yeah, you could put it that way.

> What are the use cases for the timestamps?  My use cases were these:
> 
> I. Measuring nanosecond intervals between several consecutive frames

I don't think I have ever seen nanoseconds, and we don't currently
allow that resolution. However, it's a good point - any new field
should probably take resolution into account.

>         A. Using the measurements to verify settings of device registers

This could be done I guess.

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

Possible, but I'm not sure it's all that feasible.

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

This is one.

One I ran into recently is that I needed to check the relative timings
of packets to verify the backoff function was working correctly, which
is really just very similar to your I-A case.

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

The timestamps added by the capture (e.g. tcpdump) are also notoriously
unreliable since there are processing delays - even without reordering.

I was trying to be a bit more generic, but in my case it mostly boils
down to this:
 a) the timestamps recorded by (e.g.) tcpdump in the pcap packet
    headers are unreliable
 b) the timestamps there are at the end of the frame,
    beginning is much more useful
 c) the timer I'm getting is an internal hardware timer and I can't
    easily derive either a TSF-based value, nor easily put it at the
    first bit/symbol of the MPDU (since it's earlier) [*]

johannes

[*] it's actually also somewhat unreliable, due to the reference it's
taken at, but that's something I can generally live with, it's in the
order of a few microseconds, not the milliseconds I sometimes see with
tcpdump