Re: [Madwifi-devel] clock adjustment

[Gaurav C. <gch...@gm...>]

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
>
>
>