Hi,
I do not know the answer to your questions on timestamps..
I do know from looking at zillions of packets on wireshark dumps that the
time reported on each packet is the time at which the entire was received.
You can infer this from looking at a dump where large packets are used,
travelling at a slow (1mb/sec) rate.
The reported time interval betwen the data packet and the 802.11 ack is
tens to hundreds of microseconds. This is way shorter than the transmit
time for the data packet. From the hal provided methods to calculate the
transmit time, you get several milliseconds for the transmit time for the
data packet.
You can convince wireshark to display the mac timestamp in a separate
column in the display. Code analysis shows that the mac timestamp is from
the 64bit TSF generated from the HAL of the monitoring box.
To measure the transmit time, I suggest you sit down with a box running
wireshark, and the radio card in monitor mode.
This box running wireshark should not be doing any transmission work - we
don't want radio comms to get in the way of accurate timings.
So you will need three boxes.
A and B plus the monitoring box C.
Alter the sifs/slot/ack/cts every timevalue you can find, and look at the
average separation between packets.. and then think.
Derel/
On Wed, 24 Jun 2009, Ignacy Gawedzki wrote:
> Hi everyone,
>
> After a whole day of digging in the code (mostly madwifi-free), I end up with
> no answer, hence this post.
>
> The hardware apparently does set a timestamp on transmitted frame descriptors
> that can be retrieved by the driver later on. The first question is: do we
> know when this is supposed to happen? Is that timestamp set upon reception of
> the ACK for a unicast frame? It would be sensible, but I simply can't find
> that information anywhere.
>
> The second question is about the possibility of accurate measurement of the
> total transmission time, including waiting during busy channel time intervals,
> backoffs, *IFS, (re)transmissions. I would like to be able to measure as
> accurately as possible the interval of time between the instant when the
> hardware considers a frame for transmission (i.e. it is the first in the first
> to-be-served queue) and the instant the corresponding ACK is received (or the
> hardware gives up on attempting).
>
> I have the impression that there's nothing provided in the hardware for such
> timestampings (especially the first one), but wanted to ask the experts in
> here just to be sure.
>
> Thanks.
>
>
--
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"
|