On Mon, Jul 10, 2017 at 08:03:19PM +1200, Bryan Christianson wrote:
> macOS 10.13 will implement the ntp_adjtime() system call, allowing better
> control over the system clock than is possible with the existing adjtime()
> system call.
> chronyd will support both the older and newer calls, enabling binary code to
> run without recompilation on macOS 10.9 through macOS 10.13

> -Certain systems (Linux, FreeBSD, NetBSD, Solaris) have operating system 
> support
> -for setting the rate of gain or loss to compensate for known errors. (On Mac 
> OS
> -X, *chronyd* must simulate such a capability by periodically slewing the 
> system
> -clock forwards or backwards by a suitable amount to compensate for the error
> -built up since the previous slew.)
> +With the exception of macOS 10.12 and earlier, all systems have operating 
> system

Would it better to say "all supported systems" ?

>  The *corrtimeratio* directive sets the ratio between the duration in which 
> the
>  clock is slewed for an average correction according to the source history and
> @@ -775,7 +775,7 @@ 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 (i.e. on Linux,
> -FreeBSD, NetBSD and Solaris).
> +FreeBSD, NetBSD, Solaris and macOS 10.13+).

Can you please use Oxford comma? The rest of the documentation is
using it (to the extend I understand it's supposed to be used).

> +For each system there is a maximum frequency offset of the clock that can be 
> set
> +by the driver. On Linux it is 100000 ppm, on FreeBSD, NetBSD and macOS 
> 10.13+ it
> +is 5000 ppm, and on Solaris it is 32500 ppm. Also, due to a kernel 
> limitation,
> +setting *maxslewrate* on FreeBSD, NetBSD, macOS 10.13+ to a value between 500
>  ppm and 5000 ppm will effectively set it to 500 ppm.

Is it really 5000 ppm on macOS 10.13? There is a testing program
test/kernel/adjtime, which should print the maximum slew rate. You
may need to modify it to try a larger offset than 1 second. On an
older macOS it was 42000 ppm.

I like that you reused the FreeBSD/NetBSD driver, but if adjtime()
behaves differently, then maybe it would be better to duplicate the
fast-slewing functionality in the macOS driver instead.

Miroslav Lichvar

To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
Trouble?  Email listmas...@chrony.tuxfamily.org.

Reply via email to