RE: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 2.1.1-89-g3cd32ed

[Adri Koppes <adrik@xxxxxxxxxxxxxxx>]

Hi Miroslav,

I agree the advantages of ntp_adjtime() outweigh the reduced slew rate.
I'd prefer the FreeBSD version to use only ntp_adjtime() with the kernel frequency discipline, if the slew rate is below 500PPM.
In my experience using adjtime() and ntp_adjtime() together can have unpredictable results.

With a slew rate over 500PPM, the use of ntp_adjtime() and adjtime() probably won't produce any better results than using only adjtime().
Besides, if your clock has a slew rate of 500PPM or more, something is probably very wrong with the internal clock.

Adri.


-----Original Message-----
From: Miroslav Lichvar [mailto:mlichvar@xxxxxxxxxx] 
Sent: vrijdag 18 september 2015 13:36
To: chrony-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 2.1.1-89-g3cd32ed

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.


--
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.