On Wed, Oct 27, 2010 at 7:22 AM, Bruno Randolf <br1@einfach.org> wrote:
On Wed October 27 2010 07:20:21 Eduard GV wrote:
> Hi,
>
> 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?

They are in microseconds (usec).

> Assuming
> 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?

I don't work with madwifi anymore, and I don't have a complete answer, but
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??

vishal





 
I don't know if that is enough to explain your factor of 10?

bruno

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Madwifi-devel mailing list
Madwifi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/madwifi-devel