On Thu, 4 Mar 2010, Benoit PAPILLAULT wrote:
Derek Smithies a écrit :
TSF jumps - yeah I looked into that on madwifi. For no apparent reason, the
I found that if you do the script
while true; do iwpriv ath0 debug_athreset 1; sleep 10; done
and leave it running for a couple of hours, the TSF would jump to
unreasonable numbers. Who knows why? There is no code in the hal or madwifi
driver for adjusting the TSF - so why does it go up to such stupidly high
values?
Does this script work if the IBSS network is only one node or do you need
several nodes?
I used a 3 node network. 2 nodes were running this script.
[cut]
When we (in adhoc) calculate the next beacon transmit time, we have three
pieces of information
1)Beacons are (according to the spec) transmitted at (n*Bintval) + delta
(delta, random number, typically 500 us. n is an integer)
2)we know the TSF value in the received beacon we are merging to
3)we know that the hardware has already done the merge of TSF, so that the
TSF on the receiving box is the same as the TSF of the incoming beacon.
Regarding the delta, you are right that the current code does not do the
correct computation according to what you said. Moreover, 802.11 standards is
also saying that TSF=0 is a TBTT, so according to the 802.11 standard, you
are correct as well. However, I see two points in real life :
- TSF can do a 64 bit rollover (ie jumps from 0xffffffffffffffff to 0x0).
This is easily doable since I can set the TSF to any value by doing a merge
with a beacon I injected manually with the timestamp I want.
This is an interesting denial of service attack.
On the madwifi code base, which does cause the TSF to Jump to stupidly
high values, the top 8 bits never goe over 0xfe.
I suspect the hardware will refuse to TSF merge here.
- If we are merging with a node that is sending beacons at TBTT which are not
a multiple of beacon interval (let's say it's a proprietary driver which do
not have access to the source code). If we use your formula, we won't be able
to send beacons in sync with this node. So shared beaconing is not going to
work.
I am not sure it will work even now. The delta value from my formulae is
around 500us. Since we specify the tbtt in TU values, the delta
componenent is "cancelled out". Consequently, it may be irrelevant.
However, I had a network setup with software that recorded the TSF of each
beacon that came into the box, and calculated the delta, and then did an
EWMA of the delta. Consequently, I was able to work out the average send
time of beacons from each box in the network.
Most boxes would send beacons 500 (or so) microseconds into the beacon
period. However, one box would send a beacon 1700 microseconds into the
beacon period. I never got far enough with testing the above formulae, and
proving it prevents those rogue boxes with late beacons.
..There is one other thing that you need to remember though.
ath5k timestamps packets at the end of receive, not at the beginning.
Other hardware may do the same.
Suppose there are two nodes where the hardware has just put the tsf in
sync.
node a sends a beacon at (n*Bintval) + delta.
node b receives the beacon, and timestamps it at a value of RTS, where
RTS = (n*Bintval) + delta + transmit time.
Since the transmit time of a beacon packet is a millisecond, the RTS is
one whole TU past the n*Bintval value.
node a is sending beacons at 0 TU into the beacon interval.
Consequenlty, node b will send beacons at 1 TU into the beacon interval.
node c receives a beacon from b, and is in TSF sync with a&b.
node c repeats the error of b, and ends up sending beacons at 2 TU into
the beacon interval.
Oops. Now these three nodes are not in beacon sync. Good job.
There are other test cases one can come up with. Suppose one is running
outdoors with long slot times. Conceivably, there will be beacons sent
more than 1 TU into the beacon interval. And the same thing will happen,
our beacons in our network will be close to being in sync, but will never
actually be in sync.
Since we cannot 100.00% trust the receive time stamp
(extending the 15 bit value to 64 bits works usually, but is done in a
tasklet, so could get it wrong on a busy system)
Since we do not know if the receiving box has timestamped at the beginning
or end of the packet
-->the receive timestamp is not the value we should be using. WE have to
use the formulae I described above&in previous emails.
>
For those reasons, I think the current formula (which does not compute delta)
is "better" (better does not mean it is correct).
Nope, I have just explained cases where the current formulae will fail.
We have to computer delta.
I'm really open to discussion and experiments.
Fantastic.
lets get this one right.
--
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_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
