Ticket #1025 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

TX timestamp (TSF) jumping in monitor mode

Reported by: georg@boerde.de Assigned to: scottr
Priority: minor Milestone: version 0.9.3
Component: madwifi: driver Version: trunk
Keywords: TSF monitor Cc:
Patch is attached: 1 Pending:

Description

I'm trying to calculate the transmit time for a frame by comparing the TX timestamp with the timestamp of the following ACK frame using a second monitor VAP.

The problem is the following: TX timestamps (both kernel skb timestamp and TSF) reported are not in order, e.g.: 

Packet          skb time     TSF
RX ping         0.439128     0xfc68b245
TX ping-reply   0.437567     0xfc681a2b
RX ACK          0.439651     0xfc68b455

The timestamps of the TX packet are off by some milliseconds. While the skb time is probably set _before_ the packet is enqueued in the driver, the TSF is received from the hardware in the TX processq context and should be correct.

I first looked at the processing of ts_tstamp in the TX stats, which seems to be a 16 bit value, which is put into the 15 bit function ath_extend_tsf() and leads to forward and backward jumps in the sequence of TX TSF values. This issue is fixed by the attached patch.

The second problem is that the ds_txstat.ts_tstamp value returned by HAL (or the hardware) is not the TSF but some other value, which is incremented at a much slower rate (I measured something in the range of 1ms per tick, instead of 1µs for TSF). As there is no documentation regarding the hardware/HAL value returned in that field, and it is not based on TSF, I have no idea how to interpret it.

The attached patch fixes only the first part of the issue, the question about the correct TX TSF remains.

Attachments

madwifi-r1823-txtsf.patch (1.1 kB) - added by georg@boerde.de on 11/28/06 16:33:38.
TX TSF expansion overrun fix
madwifi_tx_tsf_r1864.patch (1.2 kB) - added by scottr on 12/20/06 23:55:29.
Possible fix for TX TSF problem

Change History

11/28/06 16:33:38 changed by georg@boerde.de

  • attachment madwifi-r1823-txtsf.patch added.

TX TSF expansion overrun fix

12/14/06 22:24:06 changed by scottr

  • priority changed from major to minor.
  • status changed from new to assigned.
  • version set to trunk.
  • owner set to scottr.
  • milestone set to version 0.9.x - progressive release candidate phase.

Hi,

I have also been doing a lot of work with monitor mode interfaces and have noticed the discrepancy between RX and TX TSF values. While it looks like your attached patch is good, I think it would be better to wait until we come up with a complete solution. I'm currently looking at determining the resolution of the TX timestamps returned in the descriptors.

I'm not going to mark this ticket for 0.9.3 as we want to get a release out some time soon.

Cheers.

12/18/06 23:20:44 changed by scottr

Hi,

After some experimentation, I've come up with the following conclusions:

1) Yes, the TX timestamp is 16 bits, as opposed to the 15 bit RX timestamp. 2) The TX timestamp seems to have a resolution of 1ms, as opposed to the 1us resolution of the RX timestamp. This was measured by timing how long it took for the field to wrap during a ping flood. This came out at approximately 16,000 jiffies. So, the counter was incrementing at a rate of 16,000 / 65536 = 0.25 jiffies per tick. With 1 jiffy == 250us (HZ), that's 1ms per tick.

I'm currently working out how to incorporate the 1ms resolution timestamp into the TSF returned by the HAL.

Cheers,

12/20/06 23:55:29 changed by scottr

  • attachment madwifi_tx_tsf_r1864.patch added.

Possible fix for TX TSF problem

12/20/06 23:58:05 changed by scottr

Hi,

I've attached a patch that appears to work quite well when sorting a trace by hardware timestamps. The patch simply shifts the ts_tstamp left 10 bits, rather than multiplying by 10 (which gave wrong results when sorting the trace).

Please try the patch and let me know if it fixes things for you. If we don't get any more information from Sam and the patch works for people then we'll commit it.

Cheers.

12/21/06 11:50:13 changed by scottr

  • status changed from assigned to closed.
  • resolution set to fixed.
  • milestone changed from version 0.9.x - progressive release candidate phase to version 0.9.3.

After talking to Sam, it appears that yes, the ts_tstamp contains the timestamp in TU's, which are bits 25-10 of the TSF, so the current patch fixes things. Committed in r1865.

12/22/06 13:49:17 changed by georg@boerde.de

When I'm correctly reading the new diff, the lower bits of the TSF field are just zeroed out? I've written something similar based on my speculations on the ML, which is obsolete now ;)

Is there any way to get the precise timestamp with 1µs resolution, or are TUs all we can work with?

12/22/06 20:09:59 changed by scottr

You're right. The lower bits are zeroed. TUs are all we have to work with for TX frames, I'm afraid. Cheers.

Add/Change #1025 (TX timestamp (TSF) jumping in monitor mode)