On 11/9/11 4:12 AM, Julien Ridoux wrote:
Hi all,
I have written a set of patches to support feed-forward clock synchronisation
algorithms. To cut a long story short, this work provides support for
alternatives to the NTP daemon. The RADclock daemon we developed is one of
these alternatives.
This work is supported by the FreeBSD Foundation and a short project
description can be found here:
http://www.freebsdfoundation.org/press/2011Aug-newsletter.shtml#Project4
The patches will be committed on the weekend of Nov 19th and suggestions and
comments would be very appreciated.
The patches against r227382 can be found at this URL:
http://www.cubinlab.ee.unimelb.edu.au/~jrid/ffclock_fbsd_r227382.tar.gz
The patches introduce 3 new system calls and it is then necessary to run 'make
sysent' in sys/kern and sys/compat/freebsd32.
The feed-forward support can be compiled by adding the FFCLOCK option to the
kernel configuration file.
For more information, a fairly high level description of the feed-forward
approach for clock synchronisation is given in this ACM Queue article.
http://queue.acm.org/detail.cfm?id=1773943
All relevant technical papers, the latest stable RADclock version and more can
be found here:
http://www.synclab.org/radclock/
Please let me know your thoughts,
Not a specific thought, more a general thought on new modules
coming into the system and adding syscalls...
whether we should make new modules add syscalls dynamically
and hten export the allocated syscall number via sysctl,
or whether static allocation is still good enough..
Thanks,
Julien
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
