This came up a few weeks back and I've run some tests in ad hoc mode both in madwifi (2.6.24. and MadWifi-ng 0.9.4) and ath5k (220.127.116.11). I am using a PRISM II card as my reference because it documents the timestamp resolution and says the timestamp is for the first symbol and so all my tests have been for 11b. I can confirm that Scott's findings where the descriptor timestamp is for the end of the frame. MadWifi and Prism II agree on the results
within the margin of measurement error.
I am timing just DATA/ACK exchanges and computing the SIFS interval. My problem is that ath5k does not agree. In my setup the PRISM II card is reporting SIFS values as being 10us +/- 1us whereas ath5k reports SIFS times of either 1us or 62us. I use the same calculation for this as I do with MadWifi, specifically:
sifs = ack_timestamp - ack_txtime - data_timestamp
There's a comment in the TSF extension code that sets the top 32 bits of the TSC value. This does not seem to be the problem - its the low order bits of the timestamp that are not being set correctly. There's not enough in this yet to debig the problem but someone here may already be further along than I and I thought to ask.
Bit of an update.
I've been working on investigating the hypothesis that the timestamp
is taken at the end of each packet. While doing so I realised I had
incorrectly coded my previous experiment when assuming that the
timestamp was for the previous packet.When I fixed that bug and re-ran the experiment it became obvious that
the timestamp was _not_ for the previous packet at all. As a side
note, it turned out that the bug in my code made me treat the
timestamp very similarly to it being the end of the packet :)
Continuing under the assumption that the timestamp was for the end of
the current packet I wrote some code to explore the interframe
spacing. If the hypothesis was correct then we should see the SIFS as
a large proportion of the interframe spaces.
It turns out that yes, when treating the timestamp as an end timestamp
and working back from there everything works out. To determine a start
timestamp (still focussed only on clause 18 HR/DSSS PHYs) we need to
calculate the TX time, which is a function of the MPDU length in
octets and the preamble/PLCP length.
Determining the MPDU length is easy for clause 18 PHYs. Determining
whether a frame was received with a short or long preamble though is
not possible, as far as I can tell. There is nothing in the receive
descriptors that tells us what PHY type a frame was received with,
e.g. HR/DSSS/short or HR/DSSS/long. This becomes even more tricky when
looking at clause 19 (802.11g) PHYs, but that's a problem for later.
Under controlled conditions (i.e. manually setting the preamble type
and locking mode and rate) I was able to measure the interframe
spacing extremely accurately. I was able to see the space between DATA
and ACK frames at bang on 10 microseconds, which is great. To the best
of my knowledge this is the first time such accurate measurement has
been performed with madwifi.
I think at this point we can be pretty confident that the timestamp is
the for the end of the packet. If anybody knows how to determine the
PHY type of a received frame I'd be grateful to hear from you.
Some possibly interesting graphs:
The following show the cumulative distribution of interframe spaces
within a trace taken of a 1400 byte ICMP ping flood with sender and
receiver locked to 2Mbit HR/DSSS/short. The sender always has packets
queued to send whereas the receiver is only ever replying with a
single packet once as it receives them. The three graphs show
differing zoom levels of the data:
We can see the SIFS spacing in the last graph very clearly.
On 21/07/2009, at 7:41 PM, Scott Raynel wrote:
> Thanks for the input guys. I will do a more thorough investigation of
> the timestamp over the next couple of days and get back to you.
WAND Network Research Group
Department of Computer Science
University of Waikato
Madwifi-devel mailing list