On Wed, Oct 27, 2010 at 7:22 AM, Bruno Randolf <firstname.lastname@example.org>
On Wed October 27 2010 07:20:21 Eduard GV wrote:They are in microseconds (usec).
> I've been doing some time measurements based on the hardware timer.
> Maybe you can help me explain what I found.
> An AP is started and beacon frames (one per second) are the only traffic.
> 1 - I get the timestamp from ath_hal_gettsf64() when a beacon is
> enqueued (ath_hal_txstart is called)
> 2 - Similarly, I get the timestamp when the beacon is sent (ath_intr is
> called) 3 - The difference measured is near 11360 time units.
> With cwmin=0, cwmax=0, aifs=1 for the beacon queue, I expected values
> near 1000 usec (time needed to transmit 116 Bytes at 1Mbps). Are those
> time units provided by the ath_hal_gettsf64 in tens of usec?
I don't work with madwifi anymore, and I don't have a complete answer, but
> it is in usec (as I think it is), Why are these measurements 10 time
> bigger than expected?.
> I sniffed with wireshark in order to inspect the timestamp field
> included in beacon frames
> 1 - I get the timestamp when a beacon is enqueued (ath_hal_gettsf64)
> 2 - I get the timestamp field with wireshark
> 3 - The difference is greater than 500000!!
> I expected values near 30usec (IFS). Are the two timestamps set by the
> same clock? I assume yes, so is there any constant value being added
> to the timestamp field? Am I doing something wrong? Probably
> yes,...but what?
here is something to consider:
The beacon is not sent immediately when it's queued, but at the time in the
NBTT register (TIMER0, Next Beacon Target Time - in TU). The beacon is
generated and put into the queue by the driver at the time in SWBA (TIMER2 -
something like 1/8 TU units). Obviously SWBA is before NBTT. The hardware sets
the timestamp (TSF) field of the beacon when it is sent. It gives us the TSF
by ath_hal_gettsf64(). I assume both are based on the same timer but we have
no documentation on that. The HW might add some constant for transmission
delays, even the driver might configure that, but I'm not sure...
We are using the hardware timestamp for our modified madwifi code and
the timestamp is taken from same clock, which is used by
ath_hal_gettsf64 function. It works quite accurately for us. The time
difference of 500000 seems way too off, in any case it should be less
than the value of 11360 that u getting as time when for beacon
transmission at AP.
Are you sure you are looking at right field in the packet?? Also
you might need to no endian conversion, if the two systems use
different byte ordering. You sure you are doing that??
I don't know if that is enough to explain your factor of 10?