> For the archives: That's about the worst possible thing to do.
It's actually worse than it sounds. It jumps *backwards* every minute...
I really don't know what else to do, actually... Let it drift? (not a
rethorical question)... As for now the only visible problem seems to be
future dates on m
Zi Loff wrote:
> I'm running rdate every minute via cron as a temporary fix, until the
> new HP N40L I got for under 200 euros (no HD nor DVD) arrives. :)
So you jump the clock every minute?
For the archives: That's about the worst possible thing to do.
--
Christian "naddy" Weisgerber
On Tue, May 29, 2012 at 01:07:57PM +0100, Zi Loff wrote:
> I'm giving clockspeed a try. So far so good, but I'll only have definite
> results in a day or two. I'll post my findings.
Strike that. Clockspeed didn't work (terminates immediately without
giving feedback) and honestly I didn't bother t
Thanks for all the replies.
I'm giving clockspeed a try. So far so good, but I'll only have definite
results in a day or two. I'll post my findings.
Anyway, I'll start looking for newer hardware and arrange a proper burial
for this crappy and brave machine...
--
* Christian Weisgerber [2012-05-28 23:54]:
> Zi Loff wrote:
>
> > Is the clock drift just to large for ntpd/adjtime/adjfreq to handle
> > properly?
>
> I forgot what the maximum is that ntpd can handle, but yes, it looks
> like the drift is just too large.
nitpick: ntpd doesn't have a limit. a
On 05/28/12 15:25, Zi Loff wrote:
OK, let me try this again:
Old x86 desktop box (Pentium III @ 500MHz) running 5.0. Machine has been
on 24/7 for the past few years (minus the occasional PSU replacement),
serving mail and http under very light loads.
Its local clock is drifting. A lot.
Withou
Zi Loff wrote:
> Is the clock drift just to large for ntpd/adjtime/adjfreq to handle
> properly?
I forgot what the maximum is that ntpd can handle, but yes, it looks
like the drift is just too large.
> If so, is there any 'cure' on the software side?
You could try a different kern.timecounter.
2012/5/28 Zi Loff :
> Is the clock drift just to large for ntpd/adjtime/adjfreq to handle
> properly? If so, is there any 'cure' on the software side?
Yes.
Not with ntpd; you could run ntpdate from cron, but then your clock would
jump.
> And for extra points:
> Any clues on why this is happening?
OK, let me try this again:
Old x86 desktop box (Pentium III @ 500MHz) running 5.0. Machine has been
on 24/7 for the past few years (minus the occasional PSU replacement),
serving mail and http under very light loads.
Its local clock is drifting. A lot.
Without ntpd running:
# date; rdate -nv n
On Mon, May 28, 2012 at 12:46:45PM +0100, Zi Loff wrote:
> I have a mail server which syncs its clock to a local ntp server. This
> time server in turn syncs itself with a number of public servers and is
> working correctly, as far as I can tell (ntpd -dv shows offsets under
> 1ms).
>
> However,
I have a mail server which syncs its clock to a local ntp server. This
time server in turn syncs itself with a number of public servers and is
working correctly, as far as I can tell (ntpd -dv shows offsets under
1ms).
However, the mail server (an _old_ Pentium III @ 500Mhz) started
drifting fur
11 matches
Mail list logo
