doc: update NEWS

Set refid in server/broadcast packets to 127.127.1.255 when a time
smoothing offset is applied to the timestamps. This allows the clients
and administrators to detect that the server is not serving its best
estimate of the true time.

.gitignore

@@ -2,6 +2,8 @@
 .vimrc
 *.o
 *.swp
+*.dSYM
+*.DS_Store
 RELEASES
 Makefile
 chrony.conf.5

Makefile.in

@@ -73,12 +73,14 @@ $(HASH_OBJ) : $(patsubst %.o,%.c,$(HASH_OBJ))
 	$(CC) $(CFLAGS) $(CPPFLAGS) @HASH_COMPILE@ -c $<
 
 distclean : clean
+	-rm -f .DS_Store
 	-rm -f Makefile
 	-rm -f chrony.conf.5 chrony.texi chronyc.1 chronyd.8
 
 clean :
 	-rm -f *.o *.s chronyc chronyd core *~ chrony.info chrony.html chrony.txt
 	-rm -rf .deps
+	-rm -rf *.dSYM
 
 getdate.c :
 	bison -o getdate.c getdate.y

NEWS

@@ -3,10 +3,12 @@ New in version 2.1
 
 Enhancements
 ------------
+* Add support for Mac OS X
 * Try to replace unreachable and falseticker servers/peers specified
   by name like pool sources
 * Add leaponly option to smoothtime directive to allow synchronised
   leap smear between multiple servers
+* Use specific reference ID when smoothing served time
 * Add smoothing command to report time smoothing status
 * Add smoothtime command to activate or reset time smoothing
 

README

@@ -27,11 +27,11 @@ operating parameters whilst it is running.
 What will chrony run on?
 ========================
 
-The software is known to work on Linux, FreeBSD, NetBSD and Solaris.
-Closely related systems may work too.  Any other system will likely
-require a porting exercise.  You would need to start from one of the
-existing system-specific drivers and look into the quirks of certain
-system calls and the kernel on your target system.
+The software is known to work on Linux, FreeBSD, NetBSD, Mac OS X and
+Solaris.  Closely related systems may work too.  Any other system will
+likely require a porting exercise.  You would need to start from one
+of the existing system-specific drivers and look into the quirks of
+certain system calls and the kernel on your target system.
 
 How do I set it up?
 ===================
@@ -128,6 +128,9 @@ Stephan I. Boettcher <stephan@nevis1.columbia.edu>
 Erik Bryer <ebryer@spots.ab.ca>
     Entries in contrib directory
 
+Bryan Christianson <bryan@whatroute.net>
+    Support for Mac OS X
+
 Juliusz Chroboczek <jch@pps.jussieu.fr>
     Fix install rule in Makefile if chronyd file is in use.
 

chrony.texi.in

@@ -24,7 +24,7 @@
 @page
 @vskip 0pt plus 1filll
 Copyright @copyright{} 1997-1999 Richard P. Curnow
-Copyright @copyright{} 2009-2014 Miroslav Lichvar
+Copyright @copyright{} 2009-2015 Miroslav Lichvar
 @end titlepage
 @c }}}
 @c {{{ Top node
@@ -35,7 +35,6 @@ Copyright @copyright{} 2009-2014 Miroslav Lichvar
 * Installation::                How to compile and install the software
 * Typical scenarios::           How to configure the software for some common cases
 * Usage reference::             Reference manual
-* FAQ::                         Answers to some common questions about chrony
 * GPL::                         The GNU General Public License
 @end menu
 @c }}}
@@ -119,8 +118,8 @@ different operating systems may provide different function calls to
 achieve this, and even where the same function is used it may have
 different quirks in its behaviour.
 
-The software is known to work on Linux, FreeBSD, NetBSD and Solaris.  Closely
-related systems may work too.  Porting the software to other systems
+The software is known to work on Linux, FreeBSD, NetBSD, Mac OS X and Solaris.
+Closely related systems may work too.  Porting the software to other systems
 (particularly to those supporting an @code{adjtime} system call) should not be
 difficult, however it requires access to such systems to test out the driver.
 @c }}}
@@ -1791,33 +1790,37 @@ start with the @code{generatecommandkey} directive.
 @c {{{ leapsecmode
 @node leapsecmode directive
 @subsection leapsecmode
-This directive selects how @code{chronyd} handles leap seconds.  The Unix time
-doesn't include leap seconds.  When a leap second is applied to UTC, the system
-clock is off by one second and it needs to be corrected.
+A leap second is an adjustment that is occasionally applied to UTC to keep it
+close to the mean solar time.  When a leap second is inserted, the last day of
+June or December has an extra second 23:59:60.
 
-There are four options:
+For computer clocks that is a problem.  The Unix time is defined as number of
+seconds since 00:00:00 UTC on 1 January 1970 without leap seconds.  The system
+clock cannot have time 23:59:60, every minute has 60 seconds and every day has
+86400 seconds by definition.  The inserted leap second is skipped and the clock
+is suddenly ahead of UTC by one second.  The @code{leapsecmode} directive
+selects how that error is corrected.  There are four options:
 
 @table @code
 @item system
-The kernel steps the system clock backwards by one second at 0:00:00 UTC
-(before correction) when leap second is inserted or steps forward by one second
-at 23:59:59 UTC when leap second is deleted.  This is the default mode when the
-system driver supports leap seconds (currently Linux only).
+When inserting a leap second, the kernel steps the system clock backwards by
+one second when the clock gets to 00:00:00 UTC.  When deleting a leap second,
+it steps forward by one second when the clock gets to 23:59:59 UTC.  This is
+the default mode when the system driver supports leap seconds (currently Linux
+only).
 @item step
-This is similar to the system mode, except the clock is stepped by
-@code{chronyd} instead of the kernel.  This is the default mode when the system
-driver doesn't support leap seconds.
+This is similar to the @code{system} mode, except the clock is stepped by
+@code{chronyd} instead of the kernel.  It can be useful to avoid bugs in the
+kernel code that would be executed in the @code{system} mode.  This is the
+default mode when the system driver doesn't support leap seconds.
 @item slew
-The clock is corrected by slew starting at 0:00:00 UTC when leap second is
-inserted or 23:59:59 UTC when leap second is deleted.  This may be preferred
-over the system or step mode when applications running on the system are
-sensitive to jumps in the system time and it's acceptable that the clock will
-be off for a longer time.  On Linux with the default @code{maxslewrate} the
-correction takes 12 seconds.  Note that unless the @code{smoothtime} directive
-is used (@pxref{smoothtime directive}), there will still be a jump in the time
-that @code{chronyd} serves to NTP clients.  With the @code{smoothtime}
-directive, the leap second status will not be passed to NTP clients and the
-leap second will be "smeared" instead.
+The clock is corrected by slewing started at 00:00:00 UTC when a leap second is
+inserted or 23:59:59 UTC when a leap second is deleted.  This may be preferred
+over the @code{system} and @code{step} modes when applications running on the
+system are sensitive to jumps in the system time and it's acceptable that the
+clock will be off for a longer time.  On Linux with the default
+@code{maxslewrate} value (@pxref{maxslewrate directive}) the correction takes
+12 seconds.
 @item ignore
 No correction is applied to the clock for the leap second.  The clock will be
 corrected later in normal operation when new measurements are made and the
@@ -1830,19 +1833,40 @@ An example of the command is
 leapsecmode slew
 @end example
 
-An example enabling the leap smear for NTP clients with the @code{smoothtime}
-directive could be
+When serving time to NTP clients that can't be configured to correct their
+clocks for a leap second by slewing or they would correct them at slightly
+different rates when it's necessary to keep them close together, the
+@code{slew} mode can be combined with the @code{smoothtime} directive
+(@pxref{smoothtime directive}) to enable a server leap smear.
+
+When smearing a leap second, the leap status is suppressed on the server and
+the served time is corrected slowly be slewing instead of stepping. The clients
+don't need any special configuration as they don't know there is any leap
+second and they follow the server time which eventually brings them back to
+UTC.  Care must be taken to ensure they use for synchronization only NTP
+servers which smear the leap second in exactly the same way.
+
+This feature needs to be used carefully, because the server is intentionally
+not serving its best estimate of the true time.
+
+A recommended configuration to enable a server leap smear is:
 
 @example
 leapsecmode slew
-smoothtime 400 0.001
+maxslewrate 1000
+smoothtime 400 0.001 leaponly
 @end example
 
-With this configuration the NTP clients would not know there was any leap
-second.  The server time they follow would be slowly corrected in about 16
-hours after the leap second was applied to UTC.  This configuration should not
-be used if the clients poll also other NTP servers, because they could reject
-this server as a falseticker or could fail to select a source completely.
+The first directive is necessary to disable the clock step which would reset
+the smoothing process.  The second directive limits the slewing rate of the
+local clock to 1000 ppm, which improves the stability of the smoothing process
+when the local correction starts and ends.  The third directive enables the
+server time smoothing process.  It will start when the clock gets to 00:00:00
+UTC and it will take 17 hours 34 minutes to finish.  The frequency offset will
+be changing by 0.001 ppm per second and will reach maximum of 31.623 ppm.  The
+@code{leaponly} option makes the duration of the leap smear constant and allows
+the clients to safely synchronise with multiple identically configured leap
+smearing servers.
 @c }}}
 @c {{{ leapsectz
 @node leapsectz directive
@@ -3041,25 +3065,34 @@ it and keep their clocks close together even when large offset or frequency
 corrections are applied to the server's clock, for example after being offline
 for a longer time.
 
-If a large offset has been accumulated, it may take a very long time to smooth
-it out.  This directive should be used only when the clients are not configured
-to poll also another NTP server, because they could reject this server as a
-falseticker or fail to select a source completely.
+BE WARNED - the server is intentionally not serving its best estimate of the
+true time.  If a large offset has been accumulated, it may take a very long
+time to smooth it out.  This directive should be used only when the clients are
+not configured to poll also another NTP server, because they could reject this
+server as a falseticker or fail to select a source completely.
 
-The smoothing process is independent from any slewing applied to the local
-system clock, but the accumulated offset and frequency for smoothing will be
-reset when the clock is corrected by stepping, e.g. by the @code{makestep}
-directive or command.  The process can be reset without stepping the clock
-by the @code{smoothtime reset} command (@pxref{smoothtime command}).
+The smoothing process is implemented with a quadratic spline function with two
+or three pieces. It's independent from any slewing applied to the local system
+clock, but the accumulated offset and frequency will be reset when the clock is
+corrected by stepping, e.g. by the @code{makestep} directive or command.  The
+process can be reset without stepping the clock by the @code{smoothtime reset}
+command (@pxref{smoothtime command}).
 
-The directive takes two arguments, the maximum frequency offset of the smoothed
-time to the tracked NTP time (in ppm) and the maximum rate at which the
-frequency offset is allowed to change (in ppm per second).  The smoothing
-process is activated automatically when 1/10000 of the estimated skew of the
-local clock falls below the maximum rate of frequency change.  It can be
-activated explicitly by the @code{smoothtime activate} command, which is
-particularly useful when the clock is synchronized only with manual input
-since the skew can't be small enough to activate the process.
+The first two arguments of the directive are the maximum frequency offset of
+the smoothed time to the tracked NTP time (in ppm) and the maximum rate at
+which the frequency offset is allowed to change (in ppm per second).
+@code{leaponly} is an optional third argument which enables a mode where only
+leap seconds are smoothed out and normal offset/frequency changes are ignored.
+The @code{leaponly} option is useful in a combination with the
+@code{leapsecmode slew} option (@pxref{leapsecmode directive}) to allow clients
+use multiple time smoothing servers safely.
+
+The smoothing process is activated automatically when 1/10000 of the estimated
+skew of the local clock falls below the maximum rate of frequency change.  It
+can be also activated manually by the @code{smoothtime activate} command,
+which is particularly useful when the clock is synchronized only with manual
+input and the skew is always larger than the threshold.  The @code{smoothing}
+command (@pxref{smoothing command}) can be used to monitor the process.
 
 An example suitable for clients using @code{ntpd} and 1024 second polling
 interval could be
@@ -3474,10 +3507,11 @@ directive in the configuration file.
 @c {{{ authhash
 @node authhash command
 @subsubsection authhash
-This command sets the hash function used for authenticating user commands.
-For successful authentication the hash function has to be the same as the one
-set for the command key in the keys file on the server.  It needs to be set
-before the @code{password} command is used.  The default hash function is MD5.
+This command selects the hash function used for authenticating user commands.
+For successful authentication the hash function has to be the same as the
+function specified for the command key in the keys file on the server
+(@pxref{keyfile directive}).  It needs to be selected before the
+@code{password} command is used.  The default hash function is MD5.
 
 An example is
 
@@ -4173,7 +4207,10 @@ should enter the password and press return.
 The password can be encoded as a string of characters not containing a space
 with optional @code{ASCII:} prefix or as a hexadecimal number with @code{HEX:}
 prefix.  It has to match @code{chronyd's} currently defined command key
-(@pxref{commandkey directive}).
+(@pxref{commandkey directive}).  If the command key was specified with a
+different hash function than MD5, it's necessary to select the hash function
+with the @code{authhash} command (@pxref{authhash command}) before entering the
+password.
 
 The password command is run automatically on start if @code{chronyc} was
 started with the `-a' option.
@@ -4757,332 +4794,6 @@ command is issued.
 @c }}}
 @c }}}
 @c }}}
-@c {{{ Ch:FAQ
-@node FAQ
-@chapter Frequently asked questions
-
-@c {{{ Chapter top
-@menu
-* Administrative issues::
-* Chrony compared to other programs::
-* Configuration issues::
-* Computer is not synchronising::
-* Issues with chronyc::
-* Real-time clock issues::
-* Microsoft Windows::
-* NTP-specific issues::
-* Linux-specific issues::
-* Solaris-specific issues::
-@end menu
-@c }}}
-@c {{{ S:Administrative issues
-@node Administrative issues
-@section Administrative issues
-
-@subsection Where can I get chrony source code?
-Tarballs are available via the @code{Download} link on the chrony web site.
-For the current development from the developers' version control system see the
-@code{Git} link on the web site.
-
-@subsection Are there any packaged versions of chrony?
-We are aware of packages for Arch, CentOS, Debian, Fedora, Gentoo, Mageia,
-OpenSuse, Slackware, Ubuntu, FreeBSD and NetBSD.  We are not involved with how
-these are built or distributed.
-
-@subsection Where is the home page?
-It is currently at
-@uref{http://chrony.tuxfamily.org, http://chrony.tuxfamily.org}.
-
-@subsection Is there a mailing list?
-Yes, it's currently at @email{chrony-users@@chrony.tuxfamily.org}.  There is a
-low-volume list called chrony-announce which is just for announcements of new
-releases or similar matters of high importance.  You can join the lists by
-sending a message with the subject subscribe to
-@email{chrony-users-request@@chrony.tuxfamily.org} or
-@email{chrony-announce-request@@chrony.tuxfamily.org} respectively.
-
-For those who want to contribute to the development of chrony, there is a
-developers' mailing list.  You can subscribe by sending mail with the subject
-subscribe to @email{chrony-dev-request@@chrony.tuxfamily.org}.
-
-@subsection What licence is applied to chrony?
-Starting from version 1.15, chrony is licensed under the GNU General Public
-License, Version 2.  Versions prior to 1.15 were licensed under a custom
-BSD-like license.
-@c }}}
-@c {{{ S:Chrony compared to other programs
-@node Chrony compared to other programs
-@section Chrony compared to other programs
-@subsection How does chrony compare to ntpd?
-Chrony can usually synchronise the system clock faster and with better time
-accuracy, but it doesn't implement all NTP features, e.g. broadcast/multicast
-mode, or authentication based on public-key cryptography.  For a more detailed
-comparison, see section @code{Comparison with ntpd} in the manual.
-
-If your computer connects to the 'net only for few minutes at a time, you turn
-your Linux computer off or suspend it frequently, the clock is not very stable
-(e.g. it is a virtual machine), or you want to use NTP on an isolated network
-with no hardware clocks in sight, chrony will probably work much better for
-you.
-
-The original reason chrony was written was that ntpd (called xntpd at the
-time) could not to do anything sensible on a PC which was connected to
-the 'net only for about 5 minutes once or twice a day, mainly to
-upload/download email and news.  The requirements were
-
-@itemize @bullet
-@item slew the time to correct it when going online and NTP servers become
-visible
-@item determine the rate at which the computer gains or loses time and use this
-information to keep it reasonably correct between connects to the 'net.  This
-has to be done using a method that does not care about the intermittent
-availability of the references or the fact the computer is turned off between
-groups of measurements.
-@item maintain the time across reboots, by working out the error and drift rate
-of the computer's real-time clock and using this information to set the system
-clock correctly at boot up.
-@end itemize
-
-Also, when working with isolated networks with no true time references at all
-ntpd was found to give no help with managing the local clock's gain/loss rate
-on the NTP master node (which was set from watch).  Some automated support was
-added to chrony to deal with this.
-
-@c }}}
-@c {{{ S:Configuration issues
-@node Configuration issues
-@section Configuration issues
-
-@subsection I have several computers on a LAN.  Should be all clients of an external server?
-The best configuration is usually to make one computer the master, with the
-others as clients of it.  Add a @code{local} directive to the master's
-chrony.conf file.  This configuration will be better because
-
-@itemize @bullet
-@item the load on the external connection is less
-@item the load on the external NTP server(s) is less
-@item if your external connection goes down, the computers on the LAN will
-maintain a common time with each other.
-@end itemize
-
-@subsection Must I specify servers by IP address if DNS is not available on chronyd start?
-No.  Starting from version 1.25, @code{chronyd} will keep trying to resolve the
-hostnames specified in the @code{server} and @code{peer} directives in
-increasing intervals until it succeeds.  The @code{online} command can be
-issued from @code{chronyc} to try to resolve them immediately.
-
-@subsection How can I make chronyd more secure?
-If you don't need to serve time to NTP clients or peers, you can add
-@code{port 0} to the @file{chrony.conf} file to completely disable the NTP
-server functionality and prevent NTP requests from reaching @code{chronyd}.
-Starting from version 2.0, the NTP server port is open only when client access
-is allowed by the @code{allow} directive or command, an NTP peer is configured,
-or the @code{broadcast} directive is used.
-
-If you don't need to use @code{chronyc} remotely, you can add the following
-directives to the configuration file to bind the command sockets to the
-loopback interface.  This is done by default since version 2.0.
-
-@example
-bindcmdaddress 127.0.0.1
-bindcmdaddress ::1
-@end example
-
-If you don't need to use @code{chronyc} at all, you can disable the command
-sockets by adding @code{cmdport 0} to the configuration file.
-
-On Linux, if @code{chronyd} is compiled with support for Linux capabilities
-(available in the libcap library), you can specify an unprivileged user with
-the `-u' option or @code{user} directive in the @file{chrony.conf} file to drop
-root privileges after start.  The configure option @code{--with-user} can be
-used to drop the privileges by default.
-
-@subsection How can I improve the accuracy of the system clock with NTP sources?
-Select NTP servers that are well synchronised, stable and close to your network.
-It's better to use more than one server, three or four is usually recommended as
-the minimum, so @code{chronyd} can detect falsetickers and combine measurements
-from multiple sources.
-
-There are also useful options which can be set in the @code{server} directive,
-they are @code{minpoll}, @code{maxpoll}, @code{polltarget}, @code{maxdelay},
-@code{maxdelayratio} and @code{maxdelaydevratio}.
-
-The first three options set the minimum and maximum allowed polling interval,
-and how should be the actual interval adjusted in the specified range.  Their
-default values are 6 (64 seconds) for @code{minpoll}, 10 (1024 seconds) for
-@code{maxpoll} and 6 (samples) for @code{polltarget}.  The default values
-should be used for general servers on the internet.  With your own NTP servers
-or if have permission to poll some servers more frequently, setting these
-options for shorter polling intervals may significantly improve the accuracy of
-the system clock.
-
-The optimal polling interval depends on many factors, including the ratio
-between the wander of the clock and the network jitter (sometimes expressed in
-NTP documents as the Allan intercept), the temperature sensitivity of the
-crystal oscillator and the maximum rate of change of the temperature.
-
-An example of the directive for an NTP server on the internet that you are
-allowed to poll frequently could be
-
-@example
-server foo.example.net minpoll 4 maxpoll 6 polltarget 16
-@end example
-
-An example using very short polling intervals for a server located in the
-same LAN could be
-
-@example
-server ntp.local minpoll 2 maxpoll 4 polltarget 30
-@end example
-
-The maxdelay options are useful to ignore measurements with larger delay (e.g.
-due to congestion in the network) and improve the stability of the
-synchronisation.  The @code{maxdelaydevratio} option could be added to the
-example with local NTP server
-
-@example
-server ntp.local minpoll 2 maxpoll 4 polltarget 30 maxdelaydevratio 2
-@end example
-
-@c }}}
-@c {{{ S:Computer is not synchronising
-@node Computer is not synchronising
-@section Computer is not synchronising
-
-This is the most common problem.  There are a number of reasons, see the
-following questions.
-
-@subsection Behind a firewall?
-If there is a firewall between you and the NTP server you're trying to use,
-the packets may be blocked.  Try using a tool like wireshark or tcpdump to see
-if you're getting responses from the server.  If you have an external modem,
-see if the receive light blinks straight after the transmit light (when the
-link is quiet apart from the NTP traffic.)  Try adding @code{log measurements}
-to the @file{chrony.conf} file and look in the measurements.log file after
-chrony has been running for a short period.  See if any measurements appear.
-
-@subsection Do you have a non-permanent (i.e. intermittent) Internet connection?
-Check that you're using chronyc's @code{online} and @code{offline} commands
-appropriately.  Again, check in measurements.log to see if you're getting any
-data back from the server.
-
-@subsection In measurements.log, do the '7' and '8' flag columns always show zero?
-Do you have a @code{local stratum X} directive in the @file{chrony.conf} file?  If X
-is lower than the stratum of the server you're trying to use, this situation
-will arise.  You should always make X quite high (e.g. 10) in this directive.
-@c }}}
-@c {{{ S:Issues with chronyc
-@node Issues with chronyc
-@section Issues with chronyc
-
-@subsection I keep getting the error @code{506 Cannot talk to daemon}
-When accessing @code{chronyd} remotely, make sure that the @file{chrony.conf}
-file (on the computer where @code{chronyd} is running) has a @code{cmdallow}
-entry for the computer you are running @code{chronyc} on and an appropriate
-@code{bindcmdaddress} directive.  This isn't necessary for localhost.
-
-Perhaps @code{chronyd} is not running.  Try using the ps command (e.g. on
-Linux, 'ps -auxw') to see if it's running.  Or try 'netstat -a' and see if the
-ports 123/udp and 323/udp are listening.  If @code{chronyd} is not running, you
-may have a problem with the way you are trying to start it (e.g. at boot time).
-
-Perhaps you have a firewall set up in a way that blocks packets on port
-323/udp.  You need to amend the firewall configuration in this case.
-
-@subsection Is the chronyc<->chronyd protocol documented anywhere?
-Only by the source code :-)  See cmdmon.c (@code{chronyd} side) and client.c
-(@code{chronyc} side).
-@c }}}
-@c {{{ S:Real-time clock issues
-@node Real-time clock issues
-@section Real-time clock issues
-
-@subsection What is the real-time clock (RTC)?
-This is the clock which keeps the time even when your computer is turned off.
-It works with 1 second resolution.  @code{chronyd} can monitor the rate at
-which the real-time clock gains or loses time, and compensate for it when you
-set the system time from it at the next reboot.  See the documentation for
-details.
-
-@subsection I want to use chronyd's real-time clock support.  Must I disable hwclock?
-The hwclock program is often set-up by default in the boot and shutdown scripts
-with many Linux installations.  If you want to use chronyd's real-time clock
-support, the important thing is to disable hwclock in the shutdown procedure.
-If you don't, it will over-write the RTC with a new value, unknown to
-@code{chronyd}. At the next reboot, @code{chronyd} will compensate this (wrong)
-time with its estimate of how far the RTC has drifted whilst the power was off,
-giving a meaningless initial system time.
-
-There is no need to remove hwclock from the boot process, as long as
-@code{chronyd} is started after it has run.
-
-@subsection I just keep getting the '513 RTC driver not running' message
-For the real time clock support to work, you need the following three things
-@itemize @bullet
-@item a kernel that is supported (e.g. 2.2 onwards)
-@item enhanced RTC support compiled into the kernel
-@item an @code{rtcfile} directive in your chrony.conf file
-@end itemize
-@c }}}
-@c {{{ S:Microsoft Windows
-@node Microsoft Windows
-@section Microsoft Windows
-
-@subsection Does chrony support Windows?
-No.  The @code{chronyc} program (the command-line client used for configuring
-@code{chronyd} while it is running) has been successfully built and run under
-Cygwin in the past.  @code{chronyd} is not portable, because part of it is very
-system-dependent.  It needs adapting to work with Windows' equivalent of the
-adjtimex() call, and it needs to be made to work as an NT service.
-
-@subsection Are there any plans to support Windows?
-We have no plans to do this.  Anyone is welcome to pick this work up and
-contribute it back to the project.
-@c }}}
-@c {{{ S:NTP-specific issues
-@node NTP-specific issues
-@section NTP-specific issues
-
-@subsection Can chrony be driven from broadcast NTP servers?
-No, this NTP mode is not implemented yet.
-
-@subsection Can chronyd transmit broadcast NTP packets (e.g. to synchronise other computers on a private LAN)?
-Yes.  Starting from version 1.17, chrony has this capability.
-
-@subsection Can chrony keep the system clock a fixed offset away from real time?
-This is not possible as the program currently stands.
-
-@subsection What happens if the network connection is dropped without using chronyc's 'offline' command first?
-In this case @code{chronyd} will keep trying to access the server(s) that it
-thinks are online.  Eventually it will decide that they are unreachable and no
-longer consider itself synchronised to them.  If you have other computers on
-your LAN accessing the computer that is affected this way, they too will become
-'unsynchronised', unless you have the 'local' directive set up on the master
-computer.
-
-The 'auto_offline' option to the 'server' entry in the chrony.conf file may be
-useful to avoid this situation.
-@c }}}
-@c {{{ S:Linux-specific issues
-@node Linux-specific issues
-@section Linux-specific issues
-
-@subsection I get "Could not open /dev/rtc, Device or resource busy" in my syslog file
-Some other program running on the system may be using the device.
-@c }}}
-@c {{{ S:Solaris-specific issues
-@node Solaris-specific issues
-@section Solaris-specific issues
-
-@subsection On Solaris 2.8, I get an error message about not being able to open kvm to change dosynctodr
-(The dosynctodr variable controls whether Solaris couples the equivalent of its
-BIOS clock into its system clock at regular intervals).  The Solaris port of
-chrony was developed in the Solaris 2.5 era.  Some aspect of the Solaris kernel
-has changed which prevents the same technique working.  We no longer have root
-access to any Solaris machines to work on this, and we are reliant on somebody
-developing the patch and testing it.
-@c }}}
-@c }}}
 @c {{{ apx:GNU General Public License
 @node GPL
 @appendix GNU General Public License

client.c

@@ -3,7 +3,7 @@
 
  **********************************************************************
  * Copyright (C) Richard P. Curnow  1997-2003
- * Copyright (C) Miroslav Lichvar  2009-2014
+ * Copyright (C) Miroslav Lichvar  2009-2015
  * 
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of version 2 of the GNU General Public License as
@@ -2745,7 +2745,7 @@ static void
 display_gpl(void)
 {
     printf("chrony version %s\n"
-           "Copyright (C) 1997-2003, 2007, 2009-2014 Richard P. Curnow and others\n"
+           "Copyright (C) 1997-2003, 2007, 2009-2015 Richard P. Curnow and others\n"
            "chrony comes with ABSOLUTELY NO WARRANTY.  This is free software, and\n"
            "you are welcome to redistribute it under certain conditions.  See the\n"
            "GNU General Public License version 2 for details.\n\n",

cmdmon.c

@@ -3,7 +3,7 @@
 
  **********************************************************************
  * Copyright (C) Richard P. Curnow  1997-2003
- * Copyright (C) Miroslav Lichvar  2009-2014
+ * Copyright (C) Miroslav Lichvar  2009-2015
  * 
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of version 2 of the GNU General Public License as

configure

@@ -404,6 +404,13 @@ case $SYSTEM in
         SYSDEFS=""
         echo "Configuring for $SYSTEM"
     ;;
+    Darwin-* )
+        EXTRA_OBJECTS="sys_macosx.o"
+        EXTRA_LIBS="-lresolv"
+        EXTRA_CLI_LIBS="-lresolv"
+        add_def MACOSX
+        echo "Configuring for MacOS X (" $SYSTEM "MacOS X version" $VERSION ")"
+    ;;
     SunOS-i86pc* )                                          
         # Doug Woodward <dougw@whistler.com> reported that this configuration
         # works for Solaris 2.8 / SunOS 5.8 on x86 platforms

doc/faq.adoc

@@ -0,0 +1,273 @@
+:toc:
+:numbered:
+
+Frequently Asked Questions
+==========================
+
+== Chrony compared to other programs
+
+=== How does +chrony+ compare to +ntpd+?
+
++chrony+ can usually synchronise the system clock faster and with better time
+accuracy, but it doesn't implement all NTP features, e.g. broadcast/multicast
+mode, or authentication based on public-key cryptography.  For a more detailed
+comparison, see the http://chrony.tuxfamily.org/comparison.html[comparison
+page] on the chrony website and section
+http://chrony.tuxfamily.org/manual.html#Comparison-with-ntpd[Comparison with
+ntpd] in the manual.
+
+If your computer connects to the 'net only for few minutes at a time, you turn
+your Linux computer off or suspend it frequently, the clock is not very stable
+(e.g. it is a virtual machine), or you want to use NTP on an isolated network
+with no hardware clocks in sight, +chrony+ will probably work much better for
+you.
+
+The original reason +chrony+ was written was that ntpd (called xntpd at the
+time) could not to do anything sensible on a PC which was connected to the 'net
+only for about 5 minutes once or twice a day, mainly to upload/download email
+and news.  The requirements were
+
+* slew the time to correct it when going online and NTP servers
+  become visible
+* determine the rate at which the computer gains or loses time and
+  use this information to keep it reasonably correct between connects
+  to the 'net.  This has to be done using a method that does not care
+  about the intermittent availability of the references or the fact
+  the computer is turned off between groups of measurements.
+* maintain the time across reboots, by working out the error and
+  drift rate of the computer's real-time clock and using this
+  information to set the system clock correctly at boot up.
+
+Also, when working with isolated networks with no true time references at all
+ntpd was found to give no help with managing the local clock's gain/loss rate
+on the NTP master node (which was set from watch).  Some automated support was
+added to +chrony+ to deal with this.
+
+== Configuration issues
+
+=== I have several computers on a LAN. Should be all clients of an external server?
+
+The best configuration is usually to make one computer the master, with
+the others as clients of it.  Add a +local+ directive to the master's
+'chrony.conf' file.  This configuration will be better because
+
+* the load on the external connection is less
+* the load on the external NTP server(s) is less
+* if your external connection goes down, the computers on the LAN
+  will maintain a common time with each other.
+
+=== Must I specify servers by IP address if DNS is not available on chronyd start?
+
+No.  Starting from version 1.25, +chronyd+ will keep trying to resolve
+the hostnames specified in the +server+ and +peer+ directives in
+increasing intervals until it succeeds.  The +online+ command can be
+issued from +chronyc+ to try to resolve them immediately.
+
+=== How can I make chronyd more secure?
+
+If you don't need to serve time to NTP clients or peers, you can add +port 0+
+to the 'chrony.conf' file to completely disable the NTP server functionality
+and prevent NTP requests from reaching +chronyd+. Starting from version 2.0,
+the NTP server port is open only when client access is allowed by the +allow+
+directive or command, an NTP peer is configured, or the +broadcast+ directive
+is used.
+
+If you don't need to use +chronyc+ remotely, you can add the following
+directives to the configuration file to bind the command sockets to the
+loopback interface.  This is done by default since version 2.0.
+
+----
+bindcmdaddress 127.0.0.1
+bindcmdaddress ::1
+----
+
+If you don't need to use +chronyc+ at all, you can disable the command sockets
+by adding +cmdport 0+ to the configuration file.
+
+On Linux, if +chronyd+ is compiled with support for Linux capabilities
+(available in the libcap library), you can specify an unprivileged user with
+the +-u+ option or +user+ directive in the 'chrony.conf' file to drop root
+privileges after start.  The configure option +--with-user+ can be used to drop
+the privileges by default.
+
+=== How can I improve the accuracy of the system clock with NTP sources?
+
+Select NTP servers that are well synchronised, stable and close to your
+network.  It's better to use more than one server, three or four is usually
+recommended as the minimum, so +chronyd+ can detect falsetickers and combine
+measurements from multiple sources.
+
+There are also useful options which can be set in the +server+ directive, they
+are +minpoll+, +maxpoll+, +polltarget+, +maxdelay+, +maxdelayratio+ and
++maxdelaydevratio+.
+
+The first three options set the minimum and maximum allowed polling interval,
+and how should be the actual interval adjusted in the specified range.  Their
+default values are 6 (64 seconds) for +minpoll+, 10 (1024 seconds) for
++maxpoll+ and 6 (samples) for +polltarget+.  The default values should be used
+for general servers on the internet.  With your own NTP servers or if have
+permission to poll some servers more frequently, setting these options for
+shorter polling intervals may significantly improve the accuracy of the system
+clock.
+
+The optimal polling interval depends on many factors, including the ratio
+between the wander of the clock and the network jitter (sometimes expressed in
+NTP documents as the Allan intercept), the temperature sensitivity of the
+crystal oscillator and the maximum rate of change of the temperature.
+
+An example of the directive for an NTP server on the internet that you are
+allowed to poll frequently could be
+
+----
+server foo.example.net minpoll 4 maxpoll 6 polltarget 16
+----
+
+An example using very short polling intervals for a server located in the same
+LAN could be
+
+----
+server ntp.local minpoll 2 maxpoll 4 polltarget 30
+----
+
+The maxdelay options are useful to ignore measurements with larger delay (e.g.
+due to congestion in the network) and improve the stability of the
+synchronisation.  The +maxdelaydevratio+ option could be added to the example
+with local NTP server
+
+----
+server ntp.local minpoll 2 maxpoll 4 polltarget 30 maxdelaydevratio 2
+----
+
+== Computer is not synchronising
+
+This is the most common problem.  There are a number of reasons, see the
+following questions.
+
+=== Behind a firewall?
+
+If there is a firewall between you and the NTP server you're trying to use, the
+packets may be blocked.  Try using a tool like wireshark or tcpdump to see if
+you're getting responses from the server.  If you have an external modem, see
+if the receive light blinks straight after the transmit light (when the link is
+quiet apart from the NTP traffic.)  Try adding +log measurements+ to the
+'chrony.conf' file and look in the 'measurements.log' file after +chrony+ has
+been running for a short period. See if any measurements appear.
+
+=== Are NTP servers specified with the +offline+ option?
+
+Check that you're using +chronyc+\'s +online+ and +offline+ commands
+appropriately.  Again, check in 'measurements.log' to see if you're getting any
+data back from the server.
+
+== Issues with +chronyc+
+
+=== I keep getting the error +506 Cannot talk to daemon+
+
+When accessing +chronyd+ remotely, make sure that the 'chrony.conf' file (on
+the computer where +chronyd+ is running) has a 'cmdallow' entry for the
+computer you are running +chronyc+ on and an appropriate 'bindcmdaddress'
+directive.  This isn't necessary for localhost.
+
+Perhaps +chronyd+ is not running.  Try using the +ps+ command (e.g.  on Linux,
++ps -auxw+) to see if it's running.  Or try +netstat -a+ and see if the ports
+123/udp and 323/udp are listening.  If +chronyd+ is not running, you may have a
+problem with the way you are trying to start it (e.g.  at boot time).
+
+Perhaps you have a firewall set up in a way that blocks packets on port
+323/udp.  You need to amend the firewall configuration in this case.
+
+=== Is the +chronyc+ / +chronyd+ protocol documented anywhere?
+
+Only by the source code :-) See 'cmdmon.c' (+chronyd+ side) and 'client.c'
+(+chronyc+ side).
+
+== Real-time clock issues
+
+=== What is the real-time clock (RTC)?
+
+This is the clock which keeps the time even when your computer is turned off.
+It works with 1 second resolution.  +chronyd+ can monitor the rate at which the
+real-time clock gains or loses time, and compensate for it when you set the
+system time from it at the next reboot.  See the documentation for details.
+
+=== I want to use +chronyd+'s real-time clock support. Must I disable hwclock?
+
+The hwclock program is often set-up by default in the boot and shutdown scripts
+with many Linux installations.  If you want to use +chronyd+'s real-time clock
+support, the important thing is to disable hwclock in the shutdown procedure.
+If you don't, it will over-write the RTC with a new value, unknown to
++chronyd+.  At the next reboot, +chronyd+ will compensate this (wrong) time
+with its estimate of how far the RTC has drifted whilst the power was off,
+giving a meaningless initial system time.
+
+There is no need to remove hwclock from the boot process, as long as +chronyd+
+is started after it has run.
+
+=== I just keep getting the +513 RTC driver not running+ message
+
+For the real time clock support to work, you need the following three
+things
+
+* a kernel that is supported (e.g. 2.2 onwards)
+* enhanced RTC support compiled into the kernel
+* an +rtcfile+ directive in your 'chrony.conf' file
+
+== Microsoft Windows
+
+=== Does +chrony+ support Windows?
+
+No.  The +chronyc+ program (the command-line client used for configuring
++chronyd+ while it is running) has been successfully built and run under
+Cygwin in the past.  +chronyd+ is not portable, because part of it is
+very system-dependent.  It needs adapting to work with Windows'
+equivalent of the adjtimex() call, and it needs to be made to work as a
+service.
+
+=== Are there any plans to support Windows?
+
+We have no plans to do this.  Anyone is welcome to pick this work up and
+contribute it back to the project.
+
+== NTP-specific issues
+
+=== Can +chrony+ be driven from broadcast NTP servers?
+
+No, this NTP mode is not implemented yet.
+
+=== Can chronyd transmit broadcast NTP packets (e.g. to synchronise other computers on a private LAN)?
+
+Yes.  Starting from version 1.17, +chrony+ has this capability.
+
+=== Can +chrony+ keep the system clock a fixed offset away from real time?
+
+This is not possible as the program currently stands.
+
+=== What happens if the network connection is dropped without using +chronyc+'s +offline+ command first?
+
++chronyd+ will keep trying to access the server(s) that it thinks are online.
+When the network is connected again, it will take some time (on average half of
+the current polling interval) before new measurements are made and the clock is
+corrected. If the servers were set to offline and the +online+ command was
+issued when the network was connected, +chronyd+ would make new measurements
+immediately.
+
+The +auto_offline+ option to the +server+ entry in the 'chrony.conf' file may
+be useful to switch the servers to the offline state automatically.
+
+== Linux-specific issues
+
+=== I get +Could not open /dev/rtc, Device or resource busy+ in my syslog file
+
+Some other program running on the system may be using the device.
+
+== Solaris-specific issues
+
+=== I get an error message about not being able to open kvm to change dosynctodr
+
+(The dosynctodr variable controls whether Solaris couples the equivalent
+of its BIOS clock into its system clock at regular intervals).  The
+Solaris port of +chrony+ was developed in the Solaris 2.5 era.  Some
+aspect of the Solaris kernel has changed which prevents the same
+technique working.  We no longer have root access to any Solaris
+machines to work on this, and we are reliant on somebody developing the
+patch and testing it.

logging.h

@@ -94,6 +94,7 @@ typedef enum {
   LOGF_Sys,
   LOGF_SysGeneric,
   LOGF_SysLinux,
+  LOGF_SysMacOSX,
   LOGF_SysNetBSD,
   LOGF_SysSolaris,
   LOGF_SysSunOS,

make_release

@@ -59,15 +59,9 @@ if [ $(wc -l < INSTALL) -gt 100 -o $(wc -l < INSTALL) -lt 85 ]; then
   exit 3
 fi
 
-awk '/^[1-9] Frequently asked questions$/{p=1}
-     /^Appendix A GNU General Public License$/{exit}; p' chrony.txt | \
- tail -n +4 | sed 's/^[1-9]\.\([1-9]\)/\1/' | sed 's/^----/--/' | \
- sed 's/^====/==/' > FAQ
-
-if [ $(wc -l < FAQ) -gt 400 -o $(wc -l < FAQ) -lt 200 ]; then
-  echo "FAQ generated incorrectly?"
-  exit 3
-fi
+a2x --lynx -f text doc/faq.adoc || exit 1
+mv doc/faq.text FAQ
+rm -rf doc
 
 rm -f config.h config.log make_release .gitignore
 

ntp.h

@@ -109,4 +109,9 @@ typedef struct {
 #define NTP_LVM(leap, version, mode) \
   ((((leap) << 6) & 0xc0) | (((version) << 3) & 0x38) | ((mode) & 0x07))
 
+/* Special NTP reference IDs */
+#define NTP_REFID_UNSYNC 0x0UL
+#define NTP_REFID_LOCAL 0x7F7F0101UL /* 127.127.1.1 */
+#define NTP_REFID_SMOOTH 0x7F7F01FFUL /* 127.127.1.255 */
+
 #endif /* GOT_NTP_H */

ntp_core.c

@@ -789,8 +789,8 @@ transmit_packet(NTP_Mode my_mode, /* The mode this machine wants to be */
 
   /* Get current smoothing offset when sending packet to a client */
   if (SMT_IsEnabled() && (my_mode == MODE_SERVER || my_mode == MODE_BROADCAST)) {
-    smooth_time = 1;
     smooth_offset = SMT_GetOffset(&local_transmit);
+    smooth_time = fabs(smooth_offset) > LCL_GetSysPrecisionAsQuantum();
 
     /* Suppress leap second when smoothing and slew mode are enabled */
     if (REF_GetLeapMode() == REF_LeapModeSlew &&
@@ -801,6 +801,14 @@ transmit_packet(NTP_Mode my_mode, /* The mode this machine wants to be */
     smooth_offset = 0.0;
   }
 
+  if (smooth_time) {
+    our_ref_id = NTP_REFID_SMOOTH;
+    UTI_AddDoubleToTimeval(&our_ref_time, smooth_offset, &our_ref_time);
+    UTI_AddDoubleToTimeval(local_rx, smooth_offset, &local_receive);
+  } else {
+    local_receive = *local_rx;
+  }
+
   if (are_we_synchronised) {
     leap = (int) leap_status;
   } else {
@@ -824,17 +832,10 @@ transmit_packet(NTP_Mode my_mode, /* The mode this machine wants to be */
   message.root_delay = UTI_DoubleToInt32(our_root_delay);
   message.root_dispersion = UTI_DoubleToInt32(our_root_dispersion);
 
-  message.reference_id = htonl((NTP_int32) our_ref_id);
+  message.reference_id = htonl(our_ref_id);
 
   /* Now fill in timestamps */
 
-  if (smooth_time) {
-    UTI_AddDoubleToTimeval(&our_ref_time, smooth_offset, &our_ref_time);
-    UTI_AddDoubleToTimeval(local_rx, smooth_offset, &local_receive);
-  } else {
-    local_receive = *local_rx;
-  }
-
   UTI_TimevalToInt64(&our_ref_time, &message.reference_ts, 0);
 
   /* Originate - this comes from the last packet the source sent us */

ntp_sources.c

@@ -369,7 +369,7 @@ process_resolved_name(struct UnresolvedSource *us, IPAddr *ip_addrs, int n_addrs
   int i, added;
 
   for (i = added = 0; i < n_addrs; i++) {
-    DEBUG_LOG(LOGF_NtpSources, "%s resolved to %s", us->name, UTI_IPToString(&ip_addrs[i]));
+    DEBUG_LOG(LOGF_NtpSources, "(%d) %s", i + 1, UTI_IPToString(&ip_addrs[i]));
 
     address.ip_addr = ip_addrs[i];
     address.port = us->port;
@@ -399,6 +399,8 @@ name_resolve_handler(DNS_Status status, int n_addrs, IPAddr *ip_addrs, void *any
 
   assert(us == resolving_source);
 
+  DEBUG_LOG(LOGF_NtpSources, "%s resolved to %d addrs", us->name, n_addrs);
+
   switch (status) {
     case DNS_TryAgain:
       break;

reference.c

@@ -120,11 +120,6 @@ static LOG_FileID logfileid;
 
 /* ================================================== */
 
-/* Reference ID supplied when we are locally referenced */
-#define LOCAL_REFERENCE_ID 0x7f7f0101UL
-
-/* ================================================== */
-
 /* Exponential moving averages of absolute clock frequencies
    used as a fallback when synchronisation is lost. */
 
@@ -1109,12 +1104,10 @@ REF_SetManualReference
  double skew
 )
 {
-  uint32_t manual_refid = 0x4D414E55; /* MANU */
-
   /* We are not synchronised to an external source, as such.  This is
-   only supposed to be used with the local source option, really
-   ... */
-  REF_SetReference(0, LEAP_Unsynchronised, 1, manual_refid, NULL,
+     only supposed to be used with the local source option, really.
+     Log as MANU in the tracking log, packets will have NTP_REFID_LOCAL. */
+  REF_SetReference(0, LEAP_Unsynchronised, 1, 0x4D414E55UL, NULL,
                    ref_time, offset, 0.0, frequency, skew, 0.0, 0.0);
 }
 
@@ -1200,7 +1193,7 @@ REF_GetReferenceParams
     *is_synchronised = 1;
 
     *stratum = local_stratum;
-    *ref_id = LOCAL_REFERENCE_ID;
+    *ref_id = NTP_REFID_LOCAL;
     /* Make the reference time be now less a second - this will
        scarcely affect the client, but will ensure that the transmit
        timestamp cannot come before this (which would cause test 7 to
@@ -1222,7 +1215,7 @@ REF_GetReferenceParams
 
     *leap_status = LEAP_Unsynchronised;
     *stratum = NTP_MAX_STRATUM;
-    *ref_id = 0;
+    *ref_id = NTP_REFID_UNSYNC;
     ref_time->tv_sec = ref_time->tv_usec = 0;
     /* These values seem to be standard for a client, and
        any peer or client of ours will ignore them anyway because
@@ -1336,7 +1329,7 @@ REF_GetTrackingReport(RPT_TrackingReport *rep)
   LCL_GetOffsetCorrection(&now_raw, &correction, NULL);
   UTI_AddDoubleToTimeval(&now_raw, correction, &now_cooked);
 
-  rep->ref_id = 0;
+  rep->ref_id = NTP_REFID_UNSYNC;
   rep->ip_addr.family = IPADDR_UNSPEC;
   rep->stratum = 0;
   rep->leap_status = our_leap_status;
@@ -1368,7 +1361,7 @@ REF_GetTrackingReport(RPT_TrackingReport *rep)
 
   } else if (enable_local_stratum) {
 
-    rep->ref_id = LOCAL_REFERENCE_ID;
+    rep->ref_id = NTP_REFID_LOCAL;
     rep->ip_addr.family = IPADDR_UNSPEC;
     rep->stratum = local_stratum;
     rep->ref_time = now_cooked;

sys.c

@@ -46,6 +46,10 @@
 #include "sys_netbsd.h"
 #endif
 
+#if defined (MACOSX)
+#include "sys_macosx.h"
+#endif
+
 /* ================================================== */
 
 void
@@ -68,6 +72,10 @@ SYS_Initialise(void)
   SYS_NetBSD_Initialise();
 #endif
 
+#if defined(MACOSX)
+  SYS_MacOSX_Initialise();
+#endif
+
 }
 
 /* ================================================== */
@@ -91,6 +99,10 @@ SYS_Finalise(void)
 #if defined(__NetBSD__)
   SYS_NetBSD_Finalise();
 #endif
+
+#if defined(MACOSX)
+  SYS_MacOSX_Finalise();
+#endif
 }
 
 /* ================================================== */

sys_macosx.c

@@ -0,0 +1,314 @@
+/*
+  chronyd/chronyc - Programs for keeping computer clocks accurate.
+
+ **********************************************************************
+ * Copyright (C) Richard P. Curnow  1997-2001
+ * Copyright (C) J. Hannken-Illjes  2001
+ * Copyright (C) Bryan Christianson 2015
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ **********************************************************************
+
+  =======================================================================
+
+  Driver file for the MacOS X operating system.
+
+  */
+
+#include "config.h"
+
+#ifdef MACOSX
+
+#include <sys/sysctl.h>
+#include <sys/time.h>
+
+#include <nlist.h>
+#include <fcntl.h>
+#include <assert.h>
+#include <sys/time.h>
+
+#include <stdio.h>
+#include <signal.h>
+
+#include "sys_macosx.h"
+#include "localp.h"
+#include "logging.h"
+#include "util.h"
+
+/* ================================================== */
+
+/* This register contains the number of seconds by which the local
+   clock was estimated to be fast of reference time at the epoch when
+   gettimeofday() returned T0 */
+
+static double offset_register;
+
+/* This register contains the epoch to which the offset is referenced */
+
+static struct timeval T0;
+
+/* This register contains the current estimate of the system
+   frequency, in absolute (NOT ppm) */
+
+static double current_freq;
+
+/* This register contains the number of seconds of adjustment that
+   were passed to adjtime last time it was called. */
+
+static double adjustment_requested;
+
+/* Kernel parameters to calculate adjtime error. */
+
+static int kern_tickadj;
+static long kern_bigadj;
+
+/* ================================================== */
+
+static void
+clock_initialise(void)
+{
+  struct timeval newadj, oldadj;
+
+  offset_register = 0.0;
+  adjustment_requested = 0.0;
+  current_freq = 0.0;
+
+  if (gettimeofday(&T0, NULL) < 0) {
+    LOG_FATAL(LOGF_SysMacOSX, "gettimeofday() failed");
+  }
+
+  newadj.tv_sec = 0;
+  newadj.tv_usec = 0;
+
+  if (adjtime(&newadj, &oldadj) < 0) {
+    LOG_FATAL(LOGF_SysMacOSX, "adjtime() failed");
+  }
+}
+
+/* ================================================== */
+
+static void
+clock_finalise(void)
+{
+  /* Nothing to do yet */
+}
+
+/* ================================================== */
+
+static void
+start_adjust(void)
+{
+  struct timeval newadj, oldadj;
+  struct timeval T1;
+  double elapsed, accrued_error;
+  double adjust_required;
+  struct timeval exact_newadj;
+  long delta, tickdelta;
+  double rounding_error;
+  double old_adjust_remaining;
+
+  /* Determine the amount of error built up since the last adjustment */
+  if (gettimeofday(&T1, NULL) < 0) {
+    LOG_FATAL(LOGF_SysMacOSX, "gettimeofday() failed");
+  }
+
+  UTI_DiffTimevalsToDouble(&elapsed, &T1, &T0);
+  accrued_error = elapsed * current_freq;
+
+  adjust_required = - (accrued_error + offset_register);
+
+  UTI_DoubleToTimeval(adjust_required, &exact_newadj);
+
+  /* At this point, we need to round the required adjustment the
+     same way the kernel does. */
+
+  delta = exact_newadj.tv_sec * 1000000 + exact_newadj.tv_usec;
+  if (delta > kern_bigadj || delta < -kern_bigadj)
+    tickdelta = 10 * kern_tickadj;
+  else
+    tickdelta = kern_tickadj;
+  if (delta % tickdelta)
+	delta = delta / tickdelta * tickdelta;
+  newadj.tv_sec = 0;
+  newadj.tv_usec = (int)delta;
+  UTI_NormaliseTimeval(&newadj);
+
+  /* Add rounding error back onto offset register. */
+  UTI_DiffTimevalsToDouble(&rounding_error, &newadj, &exact_newadj);
+
+  if (adjtime(&newadj, &oldadj) < 0) {
+    LOG_FATAL(LOGF_SysMacOSX, "adjtime() failed");
+  }
+
+  UTI_TimevalToDouble(&oldadj, &old_adjust_remaining);
+
+  offset_register = rounding_error - old_adjust_remaining;
+
+  T0 = T1;
+  UTI_TimevalToDouble(&newadj, &adjustment_requested);
+}
+
+/* ================================================== */
+
+static void
+stop_adjust(void)
+{
+  struct timeval T1;
+  struct timeval zeroadj, remadj;
+  double adjustment_remaining, adjustment_achieved;
+  double elapsed, elapsed_plus_adjust;
+
+  zeroadj.tv_sec = 0;
+  zeroadj.tv_usec = 0;
+
+  if (adjtime(&zeroadj, &remadj) < 0) {
+    LOG_FATAL(LOGF_SysMacOSX, "adjtime() failed");
+  }
+
+  if (gettimeofday(&T1, NULL) < 0) {
+    LOG_FATAL(LOGF_SysMacOSX, "gettimeofday() failed");
+  }
+
+  UTI_DiffTimevalsToDouble(&elapsed, &T1, &T0);
+  UTI_TimevalToDouble(&remadj, &adjustment_remaining);
+
+  adjustment_achieved = adjustment_requested - adjustment_remaining;
+  elapsed_plus_adjust = elapsed - adjustment_achieved;
+
+  offset_register += current_freq * elapsed_plus_adjust - adjustment_remaining;
+
+  adjustment_requested = 0.0;
+  T0 = T1;
+}
+
+/* ================================================== */
+
+/* Positive offset means system clock is fast of true time, therefore
+   slew backwards */
+
+static void
+accrue_offset(double offset, double corr_rate)
+{
+  stop_adjust();
+  offset_register += offset;
+  start_adjust();
+}
+
+/* ================================================== */
+
+/* Positive offset means system clock is fast of true time, therefore
+   step backwards */
+
+static int
+apply_step_offset(double offset)
+{
+  struct timeval old_time, new_time, T1;
+
+  stop_adjust();
+
+  if (gettimeofday(&old_time, NULL) < 0) {
+    LOG_FATAL(LOGF_SysMacOSX, "gettimeofday() failed");
+  }
+
+  UTI_AddDoubleToTimeval(&old_time, -offset, &new_time);
+
+  if (settimeofday(&new_time, NULL) < 0) {
+    DEBUG_LOG(LOGF_SysMacOSX, "settimeofday() failed");
+    return 0;
+  }
+
+  UTI_AddDoubleToTimeval(&T0, offset, &T1);
+  T0 = T1;
+
+  start_adjust();
+
+  return 1;
+}
+
+/* ================================================== */
+
+static double
+set_frequency(double new_freq_ppm)
+{
+  stop_adjust();
+  current_freq = new_freq_ppm * 1.0e-6;
+  start_adjust();
+
+  return current_freq * 1.0e6;
+}
+
+/* ================================================== */
+
+static double
+read_frequency(void)
+{
+  return current_freq * 1.0e6;
+}
+
+/* ================================================== */
+
+static void
+get_offset_correction(struct timeval *raw,
+                      double *corr, double *err)
+{
+  stop_adjust();
+  *corr = -offset_register;
+  start_adjust();
+  if (err)
+    *err = 0.0;
+}
+
+/* ================================================== */
+
+void
+SYS_MacOSX_Initialise(void)
+{
+  int result;
+  size_t len;
+  struct clockinfo clockinfo;
+  int mib[2];
+
+  mib[0] = CTL_KERN;
+  mib[1] = KERN_CLOCKRATE;
+
+  len = sizeof(clockinfo);
+  result = sysctl(mib, 2, &clockinfo, &len, NULL, 0);
+
+  if(result < 0) {
+    LOG_FATAL(LOGF_SysMacOSX, "Cannot read clockinfo");
+  }
+  kern_tickadj = clockinfo.tickadj;
+  kern_bigadj = clockinfo.tick;
+
+  clock_initialise();
+
+  lcl_RegisterSystemDrivers(read_frequency, set_frequency,
+                            accrue_offset, apply_step_offset,
+                            get_offset_correction,
+                            NULL /* set_leap */,
+                            NULL /* set_sync_status */);
+}
+
+/* ================================================== */
+
+void
+SYS_MacOSX_Finalise(void)
+{
+  clock_finalise();
+}
+
+/* ================================================== */
+
+#endif

sys_macosx.h

@@ -0,0 +1,37 @@
+/*
+  chronyd/chronyc - Programs for keeping computer clocks accurate.
+
+ **********************************************************************
+ * Copyright (C) Richard P. Curnow  1997-2001
+ * Copyright (C) J. Hannken-Illjes  2001
+ * Copyright (C) Bryan Christianson 2015
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ **********************************************************************
+
+  =======================================================================
+
+  Header file for MacOS X driver
+
+  */
+
+#ifndef GOT_SYS_MACOSX_H
+#define GOT_SYS_MACOSX_H
+
+void SYS_MacOSX_Initialise(void);
+
+void SYS_MacOSX_Finalise(void);
+
+#endif

sysincl.h

@@ -29,9 +29,9 @@
 #ifndef GOT_SYSINCL_H
 #define GOT_SYSINCL_H
 
-#if defined (SOLARIS) || defined(SUNOS) || defined(LINUX) || defined(__NetBSD__)
+#if defined (SOLARIS) || defined(SUNOS) || defined(LINUX) || defined(__NetBSD__) || defined (MACOSX)
 
-#if !defined(__NetBSD__) && !defined(__FreeBSD__)
+#if !defined(__NetBSD__) && !defined(__FreeBSD__) && !defined(MACOSX)
 #include <alloca.h>
 #endif
 #include <assert.h>
@@ -39,7 +39,7 @@
 #include <errno.h>
 #include <fcntl.h>
 #include <float.h>
-#if !defined(__FreeBSD__)
+#if !defined(__FreeBSD__) && !defined(MACOSX)
 #include <malloc.h>
 #endif
 #include <math.h>

test/simulation/test.common

@@ -18,7 +18,7 @@ export PATH=../../:$PATH
 export CLKNETSIM_PATH=clknetsim
 
 # Known working clknetsim revision
-clknetsim_revision=3eb3a8d9acf60c31f5acc66617175fc748ef367e
+clknetsim_revision=1e56224dee1db69c0027e9bd63c2a202d4765959
 clknetsim_url=https://github.com/mlichvar/clknetsim/archive/$clknetsim_revision.tar.gz
 
 # Only Linux is supported

util.c

@@ -3,7 +3,7 @@
 
  **********************************************************************
  * Copyright (C) Richard P. Curnow  1997-2003
- * Copyright (C) Miroslav Lichvar  2009, 2012-2014
+ * Copyright (C) Miroslav Lichvar  2009, 2012-2015
  * 
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of version 2 of the GNU General Public License as