Re: Dual-core system will not create NTP peers'
Moshe,
What part of "keep the replies on the list" didn't you understand.
Reply to the list.
On Wed, Feb 20, 2008 at 08:04:36AM -0600, Moshe Yudkowsky wrote:
> Douglas A. Tutty wrote:
> >Keep the replies on the list.
> >On Wed, Feb 20, 2008 at 04:54:43AM -0600, Moshe Yudkowsky wrote:
> >>Running the system overnight, and doing an ntpdate every five minutes, I
> >>notice that I very consistently take a +7.5s offset -- seems like
> >>exactly 2.5% to the limit of my ability to measure.
> >Why do you run ntpdate?
> >
> >The ntp docs say that ntpdate will be removed soon since ntp has a -q
> >option that works better.
ntpd has the -g option to over-ride the 1000s limitation and the -q
option to allow the time to be set initially in one big jump (just like
ntpdate) instead of skewing for several days.
> >
> >Why not just run ntp continuously?
>
> I am running ntpdate because ntp will not sync when the clock skew is so
> large. ntpdate provided me with debugging information about what my
> problem is.
Try ntp. Read the ntp docs package. They say "after a suitable period
of mourning, the ntpdate program may be retired". After all, the ntp
program with iburst, -q and -g or -x if necessary gives a better
algorithm, error correction, and debugging than ntpdate.
>
> >Do you have more than one computer turned on locally? What type of
> >internet connection do you have? If the internet is only inermittant,
> >you could set up a local ntp server (if its clock is more reliable).
> >Or, if you happen to have a GPS, you could set that up as a time source.
>
> I have a lot of other computers, including an old AMD AthlonXP that
> keeps sync without any problems.
Well, then with the right ntp options, the time on your amd64 dual cpu
box will always be in sync with your other boxes.
Doug.
Reply to: