Thread: [Madwifi-devel] clock adjustment
Status: Beta
Brought to you by:
otaku
From: Gaurav C. <gch...@gm...> - 2007-10-24 16:28:00
|
hello all.. can someone plz point me to the portion of the code where the STA adjust their clocks to match the one received in the beacon..? please reply.. its kind of urgent. thanks --gaurav |
From: Benoit P. <ben...@fr...> - 2007-10-25 11:05:40
|
Gaurav Chhawchharia a écrit : > hello all.. > can someone plz point me to the portion of the code where the STA > adjust their clocks to match the one received in the beacon..? > please reply.. its kind of urgent. > thanks > --gaurav AFAIK. TSF synchronisation is done in hardware. The only thing you can do in software is to reset the TSF on the next TBTT. Best regards, Benoit |
From: Gaurav C. <gch...@gm...> - 2007-10-25 15:03:46
|
Hi, the exact thing which i want to do is as follows: Working in ad-hoc mode, instead of adjusting the clock value only if the received timestamp in the beacon is older than current clock, i want the clock to be adjusted to the received timestamp irrespective of whether the timestamp is from an older clock or not. For this purpose I intend to receive beacon only from a particular node. Now I dont know much but I have a feeling that this could be done in the madwifi code. I have made the change for the ibss_merge condition. But that still doesnot take care of the timing. Please help. --Gaurav On 10/25/07, Benoit PAPILLAULT <ben...@fr...> wrote: > > Gaurav Chhawchharia a =E9crit : > > hello all.. > > can someone plz point me to the portion of the code where the STA > > adjust their clocks to match the one received in the beacon..? > > please reply.. its kind of urgent. > > thanks > > --gaurav > AFAIK. TSF synchronisation is done in hardware. The only thing you can > do in software is to reset the TSF on the next TBTT. > > Best regards, > Benoit > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > |
From: Benoit P. <ben...@fr...> - 2007-10-26 17:37:12
|
Gaurav Chhawchharia a écrit : > Hi, > the exact thing which i want to do is as follows: > > Working in ad-hoc mode, instead of adjusting the clock value only if > the received timestamp in the beacon is older than current clock, i > want the clock to be adjusted to the received timestamp irrespective > of whether the timestamp is from an older clock or not. For this > purpose I intend to receive beacon only from a particular node. > > Now I dont know much but I have a feeling that this could be done in > the madwifi code. I have made the change for the ibss_merge condition. > But that still doesnot take care of the timing. > > Please help. > > --Gaurav I'm working in adhoc mode at the moment as well and i'm just trying to make it work as far as TSF is concerned. In fact, what is not exactly clear is wether the synchronisation is entirely done in hardware (apparently no) or what software steps are required. As specified in the 802.11-1999 standards, sending beacons in IBSS is a shared task. This means that each STA has a random counter around TBTT and it sends a beacon only if it has not received one in the window defined by the random counter. This clearly means that if you do not update TBTT, you can have two STA whose clock will never be merged At least, the TBTT has to be programmed to have a proper synchronisation, but since TBTT refers to TSF value, we don't know if it should refer to the our TSF or the one in the received beacons. However, if i recall correctly from my changes, I wait for the TSF to be synchronised in order to properly update the TBTT. That's the only interaction I see and it's not really clear. Now what you could try is to simply reset your own TSF whenever you received a beacon. This way, the other STA will always be older and you would get synchronised. A race condition might happens if your "master" node does synchronisation the same way.... Best regards, Benoit |
From: Gaurav C. <gch...@gm...> - 2007-10-26 21:20:17
|
On 10/26/07, Benoit PAPILLAULT <ben...@fr...> wrote: > > > Now what you could try is to simply reset your own TSF whenever you > received a beacon. This way, the other STA will always be older and you > would get synchronised. A race condition might happens if your "master" > node does synchronisation the same way.... Actually to avoid the race condition mentioned by you, I wont allow the master (parent) to receive beacons from the slave (child). I am having a tree structure. In the ath_recv_mgmt, i will allow processing of the beacon or a probe response frame only if it has been received from the master. However, I think the synchronization maybe done even before the execution of the ath_recv_mgmt. This is because I ran an experiment as explained: Two nodes A & B are in the same adhoc network. Now A is master of B (B processes beacons and probe response frames only if it is received from A in ath_recv_mgmt. A ignores all beacons and probe responses from everywhere). B comes up first and after a while A comes up. So B has an older clock. Ideally, since A doesnot "receive" beacon or probe responses, it should not synchronize to B. However this is not the case. For a while, both the nodes continue to ping each other even while maintaining different tsf values. But after sometime (approx 120 secs after getting A up), A synchronizes to the clock of B (even though it is not supposed to be receiving beacons or probe response from B). Strange! So, maybe beacon is partially processed before ath_recv_mgmt is called. btw, i could not find the source where the ath_recv_mgmt is called. can you please tell me the sequence of function calls leading to the the processing of beacon (and probe response) frames. Also, apart from beacon and probe response are there any other frames which convey the tsf information in adhoc mode? Thanks. --Gaurav |
From: Benoit P. <ben...@fr...> - 2007-10-27 08:25:14
|
Gaurav Chhawchharia a écrit : > > Actually to avoid the race condition mentioned by you, I wont allow > the master (parent) to receive beacons from the slave (child). I am > having a tree structure. > > In the ath_recv_mgmt, i will allow processing of the beacon or a probe > response frame only if it has been received from the master. > > However, I think the synchronization maybe done even before the > execution of the ath_recv_mgmt. This is because I ran an experiment as > explained: Correct. Once again TSF is synchronised by the hardware. It takes two minutes probably because the TBTT of the receiving node is not "aligned" on the sending node. > > Two nodes A & B are in the same adhoc network. Now A is master of B (B > processes beacons and probe response frames only if it is received > from A in ath_recv_mgmt. A ignores all beacons and probe responses > from everywhere). B comes up first and after a while A comes up. So B > has an older clock. > Ideally, since A doesnot "receive" beacon or probe responses, it > should not synchronize to B. However this is not the case. For a > while, both the nodes continue to ping each other even while > maintaining different tsf values. But after sometime (approx 120 secs > after getting A up), A synchronizes to the clock of B (even though it > is not supposed to be receiving beacons or probe response from B). > Strange! > > So, maybe beacon is partially processed before ath_recv_mgmt is called. > > btw, i could not find the source where the ath_recv_mgmt is called. > can you please tell me the sequence of function calls leading to the > the processing of beacon (and probe response) frames. Here are my notes: ath_rx_tasklet() => ieee80211_input_all(ic, skb, rssi, rtsf); => ieee80211_input(vap->iv_bss, skb, rssi, rtsf); => ieee80211_input(ni, skb, rssi, rtsf); case IEEE80211_FC0_TYPE_MGT ic->ic_recv_mgmt(ni, skb, subtype, rssi, rtsf) = ath_recv_mgmt(ni, skb, subtype, rssi, rtsf) => sc->sc_recv_mgmt(ni, skb, subtype, rssi, rtsf); = ieee80211_recv_mgmt(ni, skb, subtype, rssi, rtsf); fill in scan.tstamp, copied in some cases in ni->ni_tstamp.data copy ni->ni_rtsf = rtsf ... if ni->ni_tstamp.tsf >= tsf(rstamp) then => ieee80211_ibss_merge(ni) > Also, apart from beacon and probe response are there any other frames > which convey the tsf information in adhoc mode? None that I am aware of. > > Thanks. > --Gaurav > Regards, Benoit |
From: Eric W A. <Eric.Anderson@Colorado.EDU> - 2007-10-28 18:49:45
Attachments:
signature.asc
|
Hi Gaurav & Benoit, The clock change is indeed done in hardware. If you're interested, we ta= lk a little bit about using this in the following paper: http://systems.cs.colorado.edu/~andersoe/papers/wart-mobieval.pdf I have= a patch available for scheduling code off of the clock if you want it. -Eric Benoit PAPILLAULT wrote: > Gaurav Chhawchharia a =E9crit : >> Hi, >> the exact thing which i want to do is as follows: >> >> Working in ad-hoc mode, instead of adjusting the clock value only if=20 >> the received timestamp in the beacon is older than current clock, i=20 >> want the clock to be adjusted to the received timestamp irrespective=20 >> of whether the timestamp is from an older clock or not. For this=20 >> purpose I intend to receive beacon only from a particular node. >> >> Now I dont know much but I have a feeling that this could be done in=20 >> the madwifi code. I have made the change for the ibss_merge condition.= =20 >> But that still doesnot take care of the timing. >> >> Please help. >> >> --Gaurav > I'm working in adhoc mode at the moment as well and i'm just trying to = > make it work as far as TSF is concerned. In fact, what is not exactly=20 > clear is wether the synchronisation is entirely done in hardware=20 > (apparently no) or what software steps are required. >=20 > As specified in the 802.11-1999 standards, sending beacons in IBSS is a= =20 > shared task. This means that each STA has a random counter around TBTT = > and it sends a beacon only if it has not received one in the window=20 > defined by the random counter. This clearly means that if you do not=20 > update TBTT, you can have two STA whose clock will never be merged >=20 > At least, the TBTT has to be programmed to have a proper=20 > synchronisation, but since TBTT refers to TSF value, we don't know if i= t=20 > should refer to the our TSF or the one in the received beacons. However= ,=20 > if i recall correctly from my changes, I wait for the TSF to be=20 > synchronised in order to properly update the TBTT. That's the only=20 > interaction I see and it's not really clear. >=20 > Now what you could try is to simply reset your own TSF whenever you=20 > received a beacon. This way, the other STA will always be older and you= =20 > would get synchronised. A race condition might happens if your "master"= =20 > node does synchronisation the same way.... >=20 > Best regards, > Benoit >=20 >=20 > -----------------------------------------------------------------------= -- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser.= > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel --=20 Eric W. Anderson University of Colorado= eri...@co... Dept. of Computer Science= phone: +1-720-984-8864 Systems Research Lab - ECCR 1B54= PGP key fingerprints: personal: 1BD4 CFCE 8B59 8D6E EA3E EBD5 4DC9 3E61 656C 462B academic: D3C5 D6FF EDED 9F1F C36D 53A3 74B7 53A6 3C74 5F12 |
From: Gaurav C. <gch...@gm...> - 2007-10-28 18:56:46
|
Hi Eric. Thanks a lot for your reply. I will have a look at your paper and please send me the patch. --Gaurav On 10/29/07, Eric W Anderson <Eri...@co...> wrote: > > Hi Gaurav & Benoit, > > The clock change is indeed done in hardware. If you're interested, we > talk a > little bit about using this in the following paper: > http://systems.cs.colorado.edu/~andersoe/papers/wart-mobieval.pdf I have > a > patch available for scheduling code off of the clock if you want it. > > -Eric > > Benoit PAPILLAULT wrote: > > Gaurav Chhawchharia a =E9crit : > >> Hi, > >> the exact thing which i want to do is as follows: > >> > >> Working in ad-hoc mode, instead of adjusting the clock value only if > >> the received timestamp in the beacon is older than current clock, i > >> want the clock to be adjusted to the received timestamp irrespective > >> of whether the timestamp is from an older clock or not. For this > >> purpose I intend to receive beacon only from a particular node. > >> > >> Now I dont know much but I have a feeling that this could be done in > >> the madwifi code. I have made the change for the ibss_merge condition. > >> But that still doesnot take care of the timing. > >> > >> Please help. > >> > >> --Gaurav > > I'm working in adhoc mode at the moment as well and i'm just trying to > > make it work as far as TSF is concerned. In fact, what is not exactly > > clear is wether the synchronisation is entirely done in hardware > > (apparently no) or what software steps are required. > > > > As specified in the 802.11-1999 standards, sending beacons in IBSS is a > > shared task. This means that each STA has a random counter around TBTT > > and it sends a beacon only if it has not received one in the window > > defined by the random counter. This clearly means that if you do not > > update TBTT, you can have two STA whose clock will never be merged > > > > At least, the TBTT has to be programmed to have a proper > > synchronisation, but since TBTT refers to TSF value, we don't know if i= t > > should refer to the our TSF or the one in the received beacons. However= , > > if i recall correctly from my changes, I wait for the TSF to be > > synchronised in order to properly update the TBTT. That's the only > > interaction I see and it's not really clear. > > > > Now what you could try is to simply reset your own TSF whenever you > > received a beacon. This way, the other STA will always be older and you > > would get synchronised. A race condition might happens if your "master" > > node does synchronisation the same way.... > > > > Best regards, > > Benoit > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Madwifi-devel mailing list > > Mad...@li... > > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > > -- > Eric W. Anderson University of Colorado > eri...@co... Dept. of Computer Science > phone: +1-720-984-8864 Systems Research Lab - ECCR 1B54 > > PGP key fingerprints: > personal: 1BD4 CFCE 8B59 8D6E EA3E EBD5 4DC9 3E61 656C 462B > academic: D3C5 D6FF EDED 9F1F C36D 53A3 74B7 53A6 3C74 5F12 > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > > > |
From: Benoit P. <ben...@fr...> - 2007-10-30 08:59:43
|
Gaurav Chhawchharia a écrit : > > AFAIK. TSF synchronisation is done in hardware. The only thing you can > do in software is to reset the TSF on the next TBTT. > > > Where in the code can i do this? > > Thanks, > Gaurav. > It's done there in ath/if_ath.c: http://madwifi.org/browser/madwifi/trunk/ath/if_ath.c#L4699 1/ intval |= HAL_BEACON_RESET_TSF; 2/ ath_hal_beaconinit(ah, nexttbtt, intval); Best regards, Benoit |