Thread: [Madwifi-devel] understanding TSF values in beacons
Status: Beta
Brought to you by:
otaku
From: Eduard GV <edu...@gm...> - 2010-10-26 22:20:27
|
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? 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? Thanks! |
From: Bruno R. <br...@ei...> - 2010-10-27 02:19:31
|
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... I don't know if that is enough to explain your factor of 10? bruno |
From: Vishal S. <vis...@gm...> - 2010-10-27 07:06:56
|
On Wed, Oct 27, 2010 at 7:22 AM, Bruno Randolf <br...@ei...> 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 > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > |
From: Vishal S. <vis...@gm...> - 2010-10-27 07:05:59
|
---------- Forwarded message ---------- From: Vishal Sevani <vis...@gm...> Date: Wed, Oct 27, 2010 at 11:09 AM Subject: Re: [Madwifi-devel] understanding TSF values in beacons To: Bruno Randolf <br...@ei...> On Wed, Oct 27, 2010 at 7:22 AM, Bruno Randolf <br...@ei...> 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 > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > |
From: Eduard GV <edu...@gm...> - 2010-10-27 21:38:07
|
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 the > timestamp is taken from same clock, which is used by ath_hal_gettsf64 > function. It works quite accurately for us. To get an idea, what were the range of values you measured? Thank you all! |
From: Vishal S. <vis...@gm...> - 2010-10-28 11:17:27
|
On Thu, Oct 28, 2010 at 3:08 AM, Eduard GV <edu...@gm...> wrote: > 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 the > > timestamp is taken from same clock, which is used by ath_hal_gettsf64 > > function. It works quite accurately for us. > > To get an idea, what were the range of values you measured? > 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. Vishal > > > Thank you all! > |
From: Bruno R. <br...@ei...> - 2010-10-28 00:38:45
|
On Thu October 28 2010 06:38:01 Eduard GV wrote: > 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? Yes sc->sc_nexttbtt. The same value should also be in the HW register *_TIMER0. I'd rely on the HW value instead of the variable though... bruno |
From: Eduard GV <edu...@gm...> - 2010-11-11 15:21:37
|
2010/10/28 Bruno Randolf <br...@ei...>: > On Thu October 28 2010 06:38:01 Eduard GV wrote: >> 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? > > Yes sc->sc_nexttbtt. The same value should also be in the HW register > *_TIMER0. I'd rely on the HW value instead of the variable though... > After some tests, I'm pretty sure that the value of the hardware timer TIMER0 (reg 0x8028) is 10 TUs ahead of the TSF at the SWBA time (before the 32-bit TIMER0 reaches 0 for the first time). That is, SWBA interruption is launched 10 TUs (10240us?) before the actual TBT (target beacon time). That would explain the aforementioned factor of 10. Does it make sense? |
From: Bruno R. <br...@ei...> - 2010-11-12 01:37:05
|
On Fri November 12 2010 00:21:27 Eduard GV wrote: > 2010/10/28 Bruno Randolf <br...@ei...>: > > On Thu October 28 2010 06:38:01 Eduard GV wrote: > >> 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? > > > > Yes sc->sc_nexttbtt. The same value should also be in the HW register > > *_TIMER0. I'd rely on the HW value instead of the variable though... > > After some tests, I'm pretty sure that the value of the hardware timer > TIMER0 (reg 0x8028) is 10 TUs ahead of the TSF at the SWBA time > (before the 32-bit TIMER0 reaches 0 for the first time). That is, SWBA > interruption is launched 10 TUs (10240us?) before the actual TBT > (target beacon time). > > That would explain the aforementioned factor of 10. > > Does it make sense? Hmm, sorry, but I don't think so. SWBA is an alert for the driver, that a beacon is going to be sent soon. It's just an interrupt. In AP mode we prepare a beacon and put it into the beacon queue. NBTT (TIMER0) is when the HW acutally tries to send the beacon in the queue. Bruno |
From: Derek S. <de...@in...> - 2010-11-15 20:47:59
|
On Thu, 11 Nov 2010, Eduard GV wrote: > > After some tests, I'm pretty sure that the value of the hardware timer > TIMER0 (reg 0x8028) is 10 TUs ahead of the TSF at the SWBA time > (before the 32-bit TIMER0 reaches 0 for the first time). That is, SWBA > interruption is launched 10 TUs (10240us?) before the actual TBT > (target beacon time). > > That would explain the aforementioned factor of 10. > It does. SWBA interrupt happens 10ms or so before the beacon is to be sent out. The hardware generates this interrupt, and the interrupt handler has enough time to generate the beacon and place it in the appropriate transmit queue. I "measured" this by adding a new field to the beacon, and put into this field the value of the hardware tsf - all inside the swba interrupt. -With some persuasion, wireshark could report the time between the tsf in the packet and the time in this new field. The offset varied- which is understandable cause the beacon is transmitted at different times inside a 1ms long window, and the interrupt is processed sooner or later... The field you are looking for is:: int ath_hal_sw_beacon_response_time = 10; /* in TUs */ Derek. Derek Smithies Ph.D. IndraNet Technologies Ltd. ph +64 3 365 6485 Web: http://www.indranet-technologies.com/ "How did you make it work??" "Oh, the usual, get everything right". |