[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[pvatulik@chello.at: Re: ports/1384: named dies with error in ns_main.c (fwd)]

--- Begin Message ---


Hi Dustin Harris!

I had similar problems with ntpd and LinuX (2.2.16/glibc2.1/ntp-4.0.99j), 
, WinNT4.0 (SP5 + Novell Netware Client 4.61[this version is guessed]),
in my work. My NTPD lost synchronisation all the time. 

I searched all availables News archives for an answer, all I found where
old syscall problems. (More than 2 Years old). 

The answer for my problem was trivial - one of my collegues expirienced
the same faults on the same Computer-Model with WinNT4 + NW Client -
the Problem was the HP clock in the HP Kayak XA(1st series) Computer.

I tried the same configuration (mentioned above)
on a HP KAYACK XM600 Modell - which has got an ASUS Motherboard. 
and a different clock (sorry - got no specific hw-specs right here)
- the problems where gone. No sync losts anymore.

After that I enhanced the /etc/ntp.conf with the 
"driftfile /etc/ntp/drift" entry on the old XA, and watched the drift 
values changing every time - I calibrated the drift value to about.
-200.000 ppm (values may change with every clock - the HPs clock drift
is insane) - this fixed the problem, sync losts are very seldom now.
(this clock is NOT accurate!) - this fixed
the problem, sync losts are very seldom now. For contrast:
The clock on my ASUS p5a board has got a drift of 0.858 ppm and never
gets out of sync.

I conntacted HP - http://hp-linux.org/ - email: mailto:staff_(_at_)_hp-linux_(_dot_)_org,
and asked for support in this matter, but never received any response from
them. Maybe I should reissue this problem.

Sorry for this unspecific answer - I hope it could help you 
anyway. I'll open one of the older HPs tomorrow - and check the
clock vendors name.


Peter V.


On Thu, Aug 31, 2000 at 08:53:15AM -0700, Dustin Harris wrote:
> Rebuilding the kernel without "option NTP" fixed up the problem.  The
> following quote is from mark_(_dot_)_andrews_(_at_)_nominum_(_dot_)_com on 7/26/00 on
> comp.protocols.dns.bind and is what led me to attempt the kernel
> recompilation.
> 
>         Our current theory is that gettimeofday() sometimes returns
>         an out of range tv_usec.  We know this true on some BSD
>         based machines and have circumstantial evidence that Solaris
>         also has this problem.  The BSD machines in question have
>         selectable time keeping mechanisms and by telling the kernel
>         to use the alternate machanism the problem disappears.
> 
>         BIND 8.2.3 will panic just after the gettimeofday() call if
>         gettimeofday() returns a bad time so we should be able to
>         positively prove/disprove this theory.
> 
> Is this a bug in the kernel or did I somehow mess up compiling the kernel
> before?
> 
> Another data point, I could not get ntpd to work on the previous kernel.  It
> would appear that it could not actually change the time as it would follow a
> loop like the following:
> 
> Aug 30 06:11:22 zensai ntpd[28382]: synchronized to LOCAL(0), stratum=10
> Aug 30 06:12:06 zensai ntpd[28382]: synchronized to 128.223.60.21, stratum=2
> Aug 30 06:14:31 zensai ntpd[28382]: synchronized to 192.6.38.127, stratum=1
> Aug 30 06:34:34 zensai ntpd[28382]: time reset (step) 0.782979 s
> Aug 30 06:34:34 zensai ntpd[28382]: synchronisation lost
> Aug 30 06:40:24 zensai ntpd[28382]: synchronized to LOCAL(0), stratum=10
> Aug 30 06:41:08 zensai ntpd[28382]: synchronized to 128.223.60.21, stratum=2
> Aug 30 06:41:25 zensai ntpd[28382]: synchronized to 192.6.38.127, stratum=1
> Aug 30 06:59:28 zensai ntpd[28382]: time reset (step) 1.075916 s
> Aug 30 06:59:28 zensai ntpd[28382]: synchronisation lost
> 
> Any insight anyone could give would be helpful.  I would like to keep the
> time on my machine synchronized and run named. 
> 
> Thanks,
> --dustin
-- 


--- End Message ---















Visit your host, monkey.org