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 subject. Trouble? Email listmas...@chrony.tuxfamily.org.
