Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .


Whenever a packet is received, its descriptor contains a timestamp (rs_tstamp) which is the lower 15 bits of the hardware TSF at time of reception. In order to have a full timestamp, we need to find the whole 64 bits using the current hardware TSF (hw_tsf). The result of combining rs_tstamp and tsf is noted rs_tsf.


Whenever a packet is received, an interrupt is triggered. Interrupts can also be triggered by other conditions. RX packets are first processed in ath_uapsd_processtriggers() which loop on all received packets. At the end of the loop, we sampled the current hardware TSF (hw_tsf). We assume that the following hold true:

  • all RX timestamps are before hw_tsf (You cannot receive a packet whose timestamps would be in the future).
  • RX packet timestamps are always increasing.

As the rs_tstamp is a 15bit value with units usec this means we have 32.768usec (=32ms) of time to extend the timestamp and to detect a rollover. It is likely that we can meet this time constraint even under load, since we handle it in the interrupt bottom half.


We cannot detect multiple rollover of rs_tstamp.

Correct implementation

  • The easiest way to combine rs_tstamp and bf_tsf is:
rs_tsf = (hw_tsf & ~0x7fff) | rs_tstamp
  • Another way is to choose the closest combination. In theory, rs_tsf is equal to (hw_tsf & ~0x7fff) | rs_tstamp - N * 0x8000 where N >= 0. However, N cannot be reliably determined. So we choose N in order that rs_tsf is the closest combination to hw_tsf. This leads to the following pseudo code:
rs_tsf = (hw_tsf & ~TSTAMP_MASK) | rs_tstamp;
if (rs_tsf > hw_tsf) {
	if (rs_tsf - hw_tsf > (TSTAMP_MASK/2)) {
		rs_tsf -= (TSTAMP_MASK+1);
} else {
	if (hw_tsf - rs_tsf > (TSTAMP_MASK/2)) {
		rs_tsf += (TSTAMP_MASK+1);
  • Another way is to try to detect rollover when multiple RX packets are received at once.
  • In some cases, especially in IBSS mode, when a HW merge (automatic TSF update) can happen after a beacon is received, it seems that the RX timestamp is based on the old TSF (before the HW merge). When we handle the RXstamp extension, the TSF will already have been updated, and therefore the rs_tstamp and local TSF cannot be combined in a meaningful way.

Additional Problem

We don't know an exact definition of the time rs_tstamp is taken. it could be:

  • The time the PHY preamble of the frame was received.
  • The time the first data bit (MPDU) was received.
  • The time when the first bit of byte 24 (which contains the timestamp field of beacon and probe response frames) was received. This is what is defined as "Local Time" in 802.11 p 103.
  • something else.