On Thu, Oct 28, 2010 at 3:08 AM, Eduard GV <email@example.com>
On Wed, Oct 27, 2010 at 7:22 AM, Bruno Randolf wrote:
> 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).
> I don't know if that is enough to explain your factor of 10?Interesting. This is for sure one possible source of the problem. So
the beacon leaves the queue at NBTT (if the medium is idle). Is this
NBTT accessible from the driver? Maybe the variable nexttbtt?
2010/10/27 Vishal Sevani:
> We are using the hardware timestamp for our modified madwifi code and theTo get an idea, what were the range of values you measured?
> timestamp is taken from same clock, which is used by ath_hal_gettsf64
> function. It works quite accurately for us.
We have modfied madwifi code and are generating out own beacon packets. For verifying the accuracy we did following experiments, when the beacon pkt is added to the queue via ath_tx_txqaddbuf(), we insert that time into the beacon packet (say time t1). Then via the sniffer we note down the time difference between the hardware timestamp and the t1 contained in the packet. We get difference of about 400 microseconds. This difference is almost constant for all the packets, since we have disabled CCA.
But, yes your case is different from ours since you are following the normal flow for beacon transmission, whereas we have modified the flow to suit our protcol requirements.
Thank you all!