Hi 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 (2.6.30.4). 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. Steve 2009/7/22 Scott Raynel <scottray...@gmail.com> > 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: > > http://www.wand.net.nz/~smr26/graphs/ifs/2mbit.fixed.20000usecs.png<http://www.wand.net.nz/%7Esmr26/graphs/ifs/2mbit.fixed.20000usecs.png> > http://www.wand.net.nz/~smr26/graphs/ifs/2mbit.fixed.200usecs.png<http://www.wand.net.nz/%7Esmr26/graphs/ifs/2mbit.fixed.200usecs.png> > http://www.wand.net.nz/~smr26/graphs/ifs/2mbit.fixed.20usecs.png<http://www.wand.net.nz/%7Esmr26/graphs/ifs/2mbit.fixed.20usecs.png> > > We can see the SIFS spacing in the last graph very clearly. > > Cheers all > > 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. > > > > -- > Scott Raynel > WAND Network Research Group > Department of Computer Science > University of Waikato > New Zealand > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Madwifi-devel mailing list > madwifi-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > -- The highest human happiness is not the exploitation of the present but the preparation of the future.
_______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
