Derek Smithies a écrit : > [cut] > TSF jumps - yeah I looked into that on madwifi. For no apparent reason, > the TSF would jump to stupidly high values (hundred thousand years). After > chasing all the possible reasons on madwifi, 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? This is to understand if the TSF is able to jump by itself or if one node happens to send bogus information that is used by other nodes to have their TSF jumped ahead. > [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. In this case, we will have TBTT that are no longer multiple of the beacon interval (since 0x10000000000000000 is not a multiple of the beacon interval). In this case, both your formula & 802.11 standards are wrong (but hey... that can happen). - 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. For those reasons, I think the current formula (which does not compute delta) is "better" (better does not mean it is correct). I'm really open to discussion and experiments since I know you (Derek) really bring valuable information into the discussion. Regards, Benoit _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
