Re: [Madwifi-devel] Questions about timestamps reported by the HAL

[Derek S. <de...@in...>]

Hi,

> (b) In the comments it is mentioned that the above function is slow. I
> am wondering about how slow is it ?. ( Is it of the same order as the
> transmission time ? ).
It takes 5us (microseconds) per call. Measured on an arm embedded 
platform.
  I put a for loop into the code, so that when one of the proc files was 
altered, my for loop went berserk and did a million calls to gettsf64.
>From the shell, I had

    time cat /proc/net/madwfi/ath0/some-file

took 5 seconds to do a million calls.

================

> (d) There were posts sometime back on this list about the Rx TSF value
> reported in the context of ath_rx_tasklet. My understanding is that
> this timestamp is generated *after* the packet has been received by
> the interrupt handler in the  ath_intr_process_rx_descriptors. So, the
> Rx TSF does not report the reception time of the last bit of the
> packet, but is infact timestamped after the packet has been entirely
> received and handed over to the driver. Is my understanding correct ?
>
Rx TSF is the time when the last bit of the packet has been received.

You can deduce this information from looking at ping times, and looking at 
wireshark dumps of the radio traffic.

Don't know on some of your questions on timestamping - things like 
transmission are handled in hardware. The software (driver) is too slow to 
respond to requests for a packet. Well, put another way. The interpacket 
spacing in the 802.11 protocol are microseconds in length. Software in the 
driver is never going to reliably provide a packet on this microsecond 
level timescale. Consequently, packets for transmission have to be queued 
in hardware.

Derek.

On Sat, 24 Oct 2009, Devesh Agrawal wrote:

> Hi Everyone,
>
> I am trying to measure the total transmission time of each packet. I
> don't have an additional monitor node to timestamp the packets and so
> I am trying to implement this measurement at the sender itself based
> on the TSF values it reports.
>
> I came across the following questions when thinking about how I could
> implement such accurate packet level timestamping.
>
> (a) What exactly does the ath_hal_gettsf64 return. Are all the 64 bits
> of this uint64_t valid ?. Or does the HAL only fill in the lower K
> bits with the current micro-second clock value ?. (  I saw a comment
> in the code that only the bottom 27 bits are filled by the hardware
> timestamp. Hence my confusion ).
>
> (b) In the comments it is mentioned that the above function is slow. I
> am wondering about how slow is it ?. ( Is it of the same order as the
> transmission time ? ).
>
> (d) There were posts sometime back on this list about the Rx TSF value
> reported in the context of ath_rx_tasklet. My understanding is that
> this timestamp is generated *after* the packet has been received by
> the interrupt handler in the  ath_intr_process_rx_descriptors. So, the
> Rx TSF does not report the reception time of the last bit of the
> packet, but is infact timestamped after the packet has been entirely
> received and handed over to the driver. Is my understanding correct ?
>
> (e) Exactly when is the Tx timestamp (contained in bf->bf_tsf)
> generated ?. Does it report the hardware TSF value when the last bit
> of the packet was transmitted or does it report the hardware timestamp
> when the first bit of the packet was sent out. Or is it generated
> somewhere in the HAL (in software) ?
>
> (f) I am wondering what is the best way to accurately timestamp the
> beginning of each packet transmission. I want to do this because I
> want to timestamp when the packet actually started the transmission
> and not when it was en queued. Any suggestions on the best way to do
> this would be very welcome. One hack I thought of was to disable the
> hardware queuing by somehow setting the hardware queue size to 1. Will
> that work ?
>
> (c) I notice that setting CWmin = CWmax = 0 does not produce much
> benefit over a great (high SNR) and clear link (zero interfering
> links). On digging through the code more, I find that the
> txcont_configure_radio instead uses CWmin = CWmax = 1 and not CWmin =
> CWmax = 0. So which of these two ways actually corresponds to no backoffs.
>
> Thanks a lot.
>
>

-- 
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/

"The only thing IE should be used for is to download Fire Fox"

"My favorite language is call STAR. It's extremely concise. It has
  exactly one verb '*', which does exactly what I want at the moment."
     --Larry Wall