Re: [Madwifi-devel] Accuracy of the timestamp in receive descriptors

[Scott R. <sco...@gm...>]

Thanks for the input guys. I will do a more thorough investigation of  
the timestamp over the next couple of days and get back to you.

On 21/07/2009, at 7:17 PM, Benoit PAPILLAULT wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Derek Smithies a écrit :
>> Hi, On Tue, 21 Jul 2009, Scott Raynel wrote:
>>
>>> Hi all,
>>>
>>> Before I begin, I've only posted this on madwifi-devel (as
>>> opposed to ath5k-devel) as I'm not sure about whether this may
>>> affect ath5k. Now, it may be that I'm repeating commonly held
>>> knowledge here, but I certainly wasn't aware of it and am
>>> thinking that it may affect things like ad-hoc merging, etc.
>>>
>>> Executive Summary: The receive timestamp in each descriptor is
>>> not for the current packet, it is for the previous.
>>>
>> An alternative theory is that the receive timestamp is the time
>> provided by the hal/hardware at the end of the packet. Thus, the
>> receive timestamp that we get from the hal is the time at which the
>> entire packet has been read.
>>
>> You can get a hint as to this with a wireshark dump of a
>> connection. Set up nodes A and B. on Node A, ping node B with a
>> 1400 byte long ping packet.
>>
>> on node A, run the command:: ping -s 1400 node_b
>>
>> on node C, with a madwifi running in monitor mode, capture the
>> packets. put the packet dump into wireshark. Add a custom column to
>> the display, to show the time between packets. sort the display
>> based on this custom column. In fact, you can add multiple columns
>> to the wireshark display, and report on absolute time, delta time,
>> and other mac timestamp, and so on. The mac timestamp is the
>> timestamp from the hal - which you can now see.
>>
>> There is always a relatively short time (sub millisecond) between
>> the big data packet and the subsequent ack. Even though the big
>> data packet will have taken many milliseconds to send.
>>
>> Scott - your theory about the capture time being for the subsequent
>> packet can be worked through by sending two distinct streams of
>> data, separated by seconds.
>>
>> by adding node_d and using some madwifi 'magic' you can get two
>> distinct streams of data. if node_d does:
>>
>> iwpriv ath0 txcontrate 54 iwpriv ath0 txcont 1 sleep 10 iwpriv ath0
>> txcont 0
>>
>> in the time that one node is doing txcont, there is no radio
>> traffic anywhere. You can see this in the wireshark display. In
>> this way, we have two distinct streams of data on the air.
>>
>> The mac timestamp follows exactly the time of day, and does not
>> have a "off by one" type error. An off by one error would be
>> evident if the hal timestamp was for the previous packet.
>>
>> If the hal timestamp was for the previous packet, adhoc merging
>> would never work reliably. Since the work of Benoit (think it was
>> his)  at around r3000, adhoc merging has been reliable and stable.
>>
>> Derek. -- Derek Smithies Ph.D. IndraNet Technologies Ltd. ph +64 3
>> 365 6485 Web: http://www.indranet-technologies.com/
> I agree with Derek. But it needs an experiment to be confirmed (and
> something very detailled, like you did Scott!).
>
> Regards,
> Benoit
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkpla3MACgkQOR6EySwP7oLJSACglsVBhugZDDsmdTdn7a0r4F1L
> zOQAnRKgR4b3+K5GFpaBFvXrAK+aRAdo
> =IcqQ
> -----END PGP SIGNATURE-----
>

--
Scott Raynel
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand