A closer look at madwifi’s timestamps
July 22nd, 2009
So yesterday’s post to madwifi-devel generated a few interesting responses, both on and off list. Derek Smithies suggested that the timestamp may not actually be for the previous packet, but for the end of the current packet.
After looking into this today I realised that I had made a mistake while coding up my experiment which essentially meant that I had already been treating the timestamp as if it were the end timestamp without realising. After re-writing it I convinced myself that the timestamp was not for the previous packet at all.
With the timestamp at the end of the packet, we remove the unknown factor of when the timestamp was actually taken, which is great. This removes the question of how far through the packet’s preamble the timestamp was taken, and removes its dependence on SNR, etc.
However, we still need to accurately determine the transmission time of the packet in order to accurately determine the start time and from there the inter-frame spacing. For HR/DSSS frames this is fairly easy. PreambleLength + PLCPLength + (8*octets/datarate). However, determining whether the frame was sent with HR/DSSS/long or HR/DSSS/short is apparently not possible, so we do not know for an arbitrary packet what it’s preamble and PLCP lengths are. Under controlled conditions though in which we fixed all of these values, we were able to measure inter-frame spaces very accurately.



From the first graph we can easily see the 10 microsecond SIFS interval that separates ACK from DATA packets. The second graph zooms out a bit and we can start to see the DIFS + contention window backoff kicking in. Zooming right out in the third graph shows the major times when activity is happening – for example, we can see where higher layer queueing is starting to take effect.
From here I need to see if I can perform accurate TX time calculations for 802.11a and 802.11g PHYs. 802.11a should be fairly straight forward, however 802.11g poses problems as there are several modes it can operate in depending on the mix of stations in the BSS.
Entry Filed under: General
3 Comments Add your own
1. Albert Kunze | July 23rd, 2009 at 7:44 am
I would like to process the long training sequence in real time. Can I do this with madwifi.
2. KCN | December 11th, 2009 at 12:00 am
Hi,
I am doing experiments with half width (10 MHz) and quarter width (5 MHz) channels in madwifi.
This seems pretty easy to do with the open source HAL.
But, while doing this I noticed that ad-hoc mode madwifi has very bad performance. The data rate between two machines next to each other is typically a few kbps. This is true for latest madwifi trunk and also later madwifi-free branches. Is there any version of madwifi code (after open source HAL was integrated) which has shown any better performance in ad-hoc mode?
Your help is appreciated,
3. Scott | December 11th, 2009 at 12:05 am
I’m not sure sorry – you probably want to ask on the madwifi-users or madwifi-devel lists.
Leave a Comment
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Subscribe to the comments via RSS Feed