4.2.4 is way way old. (ntp releases are infrequent to begin with and
the current version is 4.2.6 and that is already quite old.)
Besides, the problem went away when you deleted the drift file and
restarted ntpd. So I'd say that was likely to be your problem.
Looks like the general
Today drift is 60 and offsets are around 8. Looks good.
You know what's good?
from: ntp3.lordynet.org NetBSD-6.1, i386, ntpd 4.2.6p5:
$ cat /var/db/ntp/ntpd.drift
-9.722
from ntpq -crv
offset=-0.061
Your ntpd 4.2.4 is from 2008 through 2009 and offsets with
that version might not have been
If the oscillator drifts from last drift-file write, outside of +/- 15
ppm if I recall it, it fails to lock in again.
It would be good if it could bail out and do normal frequency
acquisition if that occurs.
That particular feature have bitten hard, and was a side-consequence
of other faults,
Hi--
On Nov 4, 2013, at 9:40 AM, Antonio Marcheselli pu...@me.la wrote:
Would it be wiser to delete the drift file at boot - by script - and let ntpd
resync and recreate a new drift file?
Normally, no.
The drift file lets ntpd perform a first-order correction of the average
intrinsic drift
On 04/11/2013 18:49, Charles Swiger wrote:
Hi--
On Nov 4, 2013, at 9:40 AM, Antonio Marcheselli pu...@me.la wrote:
Would it be wiser to delete the drift file at boot - by script - and let ntpd
resync and recreate a new drift file?
Normally, no.
The drift file lets ntpd perform a
Running ntpdate every hour instead of running ntpd won't work if there
are database servers or dovecot or other apps that require monotonic
time.
But if the system clock is always running slow this *probably* won't be
an issue, and it also again points to lost clock interrupts. Better to
solve
On 2013-11-03, Antonio Marcheselli pu...@me.la wrote:
On 03/11/2013 05:55, David Taylor wrote:
On 02/11/2013 20:41, unruh wrote:
On 2013-11-02, antonio.marchese...@gmail.com
antonio.marchese...@gmail.com wrote:
[]
How can I verify if the stepping has been disabled or not?
ntp.drift at the
On Nov 4, 2013, at 11:36 AM, Harlan Stenn st...@ntp.org wrote:
Running ntpdate every hour instead of running ntpd won't work if there
are database servers or dovecot or other apps that require monotonic
time.
Did you somehow know whether the existing 500+ ppm drift is stable?
But if the
On 2013-11-04, Antonio Marcheselli pu...@me.la wrote:
That is being considered. The server runs a maintenance procedure every
24hours when all the services are stopped momentarily. It could be the
right time for an ntpdate to run.
ntpd continuously disciplines the system clock (i.e.
On 04/11/2013 19:50, Charles Swiger wrote:
On Nov 4, 2013, at 11:36 AM, Harlan Stenn st...@ntp.org wrote:
Running ntpdate every hour instead of running ntpd won't work if there
are database servers or dovecot or other apps that require monotonic
time.
Did you somehow know whether the existing
On 2013-11-04, Charles Swiger cswi...@mac.com wrote:
Hi--
On Nov 4, 2013, at 9:40 AM, Antonio Marcheselli pu...@me.la wrote:
Would it be wiser to delete the drift file at boot - by script - and let
ntpd resync and recreate a new drift file?
Normally, no.
The drift file lets ntpd perform
Antonio,
On 11/04/2013 06:40 PM, Antonio Marcheselli wrote:
If the oscillator drifts from last drift-file write, outside of +/- 15
ppm if I recall it, it fails to lock in again.
It would be good if it could bail out and do normal frequency
acquisition if that occurs.
That particular feature
On 05/11/2013 01:57, Nomen Nescio wrote:
simple command AFIK. As ntpd can also be configured to broadcast time,
How? Could you point me out on relevant FAQ?
https://www.google.co.uk/search?q=ntp+broadcast may help.
--
Cheers,
David
Web: http://www.satsignal.eu
13 matches
Mail list logo
