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
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 particu
On 2013-11-04, Charles Swiger wrote:
> Hi--
>
> On Nov 4, 2013, at 9:40 AM, Antonio Marcheselli 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 co
On 04/11/2013 19:50, Charles Swiger wrote:
On Nov 4, 2013, at 11:36 AM, Harlan Stenn 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 drif
On 2013-11-04, Antonio Marcheselli 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. attempts to stee
On Nov 4, 2013, at 11:36 AM, Harlan Stenn 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 system clock i
On 2013-11-03, Antonio Marcheselli 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
>>> wrote:
>> []
How can I verify if the stepping has been disabled or not?
ntp.drift at the moment is -500.000
>>>
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 th
On 04/11/2013 18:49, Charles Swiger wrote:
Hi--
On Nov 4, 2013, at 9:40 AM, Antonio Marcheselli 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
Hi--
On Nov 4, 2013, at 9:40 AM, Antonio Marcheselli 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 of the loc
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, b
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 mu
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 consensus
13 matches
Mail list logo
