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 moment is -500.000
Which is way out of spec and cannot be corrected by ntpd.
Yes, it can be
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 moment is -500.000
Which is way out of spec and cannot
On 03/11/2013 09:09, Hal Murray wrote:
In article LGhdu.13365$vx.189@fx24.am4,
I think there was a bug in some old version of ntpd that caused it to
get confused and set the drift to the max and then get stuck there.
Interesting. My ntpd version is 4.2.4p4
Do you reckon it could be my
Same server, same network, what happened??
Ntpd is intended to run continuously, here I've seen uptimes
of +200 days. Older releases of ntpd don't behave at all well
if repeatedly restarted so above method is same as I use when
restarting after an outage, especially if the battery backed
RTC is
On 2013-11-03, Antonio Marcheselli pu...@me.la wrote:
My guess is you're not meant to do it that way but then I'm
no expert at configuring debian.
As pointed out by John, it's how the manufacturer implemented the system.
Are you completely unable to resolve ip address to hostname
eg.
On 11/03/2013 12:43 AM, David Woolley wrote:
On 02/11/13 21:48, David Lord wrote:
Ntpd writes to its drift file and also ntp.log. The drift file
is critical and is used and updated at intervals by ntpd.
The drift file is an optimisation. ntpd should work without it, but
will take longer
Now after just an hour the drift is -30, and all offsets are near zero.
Same server, same network, what happened??
You stated tht the drift file said 500.0 before. Maybe that is what the
designers of your distro stuck in there. If they did it is complete
incompetence. ntp would almost
What would cause more problems would be a drift file that was present,
but read-only, as ntpd would skip its frequency calibration and trust
the frozen value in that file, then suffer wild swings as it begins to
discover the value was wildly wrong.
No worries, the RO partition is only for
Antonio Marcheselli writes:
Interesting. My ntpd version is 4.2.4p4
Do you reckon it could be my case?
Verey possibly so. 4.2.4 was EOL'd in December of 2009, when 4.2.6 was
released. As soon as we can fix some IPv6 and broadcast/multicast bugs,
4.2.8 will be released, and at that time 4.2.6
On 03/11/2013 22:30, Harlan Stenn wrote:
Antonio Marcheselli writes:
Interesting. My ntpd version is 4.2.4p4
Do you reckon it could be my case?
Verey possibly so. 4.2.4 was EOL'd in December of 2009, when 4.2.6 was
released. As soon as we can fix some IPv6 and broadcast/multicast bugs,
Antonio Marcheselli wrote:
Same server, same network, what happened??
Ntpd is intended to run continuously, here I've seen uptimes
of +200 days. Older releases of ntpd don't behave at all well
if repeatedly restarted so above method is same as I use when
restarting after an outage, especially
On 11/03/2013 06:26 PM, Magnus Danielson wrote:
On 11/03/2013 12:43 AM, David Woolley wrote:
On 02/11/13 21:48, David Lord wrote:
Ntpd writes to its drift file and also ntp.log. The drift file
is critical and is used and updated at intervals by ntpd.
The drift file is an optimisation. ntpd
12 matches
Mail list logo
