| Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 2.1.1-89-g3cd32ed |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Thu, Sep 17, 2015 at 11:04:07AM -0700, Bill Unruh wrote:
> I am not sure what the consequences of this are, but if it limits chronyd on
> Linux to 500PPM adjustment, it is a real step back. One of the advantages of
> chrony has always been that it could rapidly adjust the time by slewing, since
> it could slew up to a rate of 1/10. (ten seconds to slew a second) and could
> remove the coarse adjustment of the rate ( so if you clock was out by 300PPM
> on average, it could still use the full 500PPM adjustment width of the fine
> control. ) To go the silly ntpd rate limits of just 500PPM is to me a major
> change in chrony and to me a backward step. Of course I may be misinterpreting
> this.
On Linux there is no change, the maximum frequency offset is still
10%. The driver was just refactored to allow sharing some parts of the
code with other systems.
However, on FreeBSD and NetBSD, where adjtime() slewed by up to 5000
ppm, it's now only 500 ppm as their ntp_adjtime() doesn't allow more.
I think the advantages of using ntp_adjtime() outweigh the reduced
slew rate, but there is still a possibility to improve the driver to
use both adjtime() and ntp_adjtime() at the same time. adjtime() would
be used only to make quick (but coarse) phase corrections.
I'm now working on the Solaris driver and the good news is that
the ntp_adjtime() frequency can be set up to 32768 ppm, so going from
the 65000 ppm adjtime() slew rate won't be that big a difference.
--
Miroslav Lichvar
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.