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

Re: Problems with ntp, ntpdate and chrony



Hello Donald,

thank you for your answer!
Reading your mail I found the problems of my configuration :-)

> I am using this combo (ntpdate + ntp) on an Alpha XLT (Alcor) without 
> any problems, although I am running "Testing" + 2.2.19 kernel here.

Now I have it working too!

> I checked my files, and they are almost identical to yours.  The main 
> differences are the actual external time-servers, and the ntpdate 
> startup line in /etc/init.d/ntpdate is written a bit differently from 
> yours...it calls a $NTPSERVERS variable stored in 
> /etc/default/ntp-servers.  Here is my line:  " /usr/sbin/ntpdate -u -b 
> -s $NTPSERVERS".  Note that mine uses the option "-u".  The 
> /etc/ntp.conf file is identical to yours.

The -u options tells ntpdate to use an unprivileged port.
After using -u, ntpdate worked!

I read the man page one and the help to ntp once more:
The answers from the ntp daemons came on port 123/udp.
But my firewall did not let any packet in from ports
bellow 1024 :-)

> Dunno what could be giving you the problem, but here are some things I 
> had to "learn" in order to get my setup working.
> 
> 1.  NTPDATE and NTP have different functions.  NTPDATE is a "true" 
> client that will sync your system clock to an external standard no 
> matter how large the difference in times.  NTP is more of a "server" in 
> that will provide time-synch services to OTHER computers and will keep 
> in synch with an external time source.  Its method of synching to an 
> external source is different and quite a bit slower.  NTP makes use of 
> the system clock's "drift".  It is generally not too good if there are 
> large differences between your system clock and the external time source 
> and may take several hours/days to get in reasonable synch.

I do not stop my computer if not necessary; so I call ntpdate at startup
and than start the ntpd. The drift of the internal clock seens to be quite
big: about 400 sec in one week...

> 2.  If you are NOT setting up a local "time-server" for your LAN, you 
> really don't need NTP.  NTPDATE will update a single system just fine. 
> If your system has a LOT of drift, you can run NTPDATE periodically via 
> a cron job.  This is usually not necessary if you re-boot (run NTPDATE) 
> daily.  A lot of this will depend upon the time precision you require.

It is possible that I want to use it as a ntp server for my LAN in the
near future...

> 3.  If you are setting up a local time-server, the usual method is to 
> run NTPDATE first to get the system clock "in the ball-park", then start 
> NTP and let it keep the synch.  On my machine, NTPDATE is run first at 
> startup in the /etc/rcS/ series of scripts, then NTP is started in the 
> /etc/rc2.d/ (run-level 2) series of scripts.

Yes!

> 4.  NTPDATE and NTP cannot be run at the same time!  I would suggest 
> concentrating on getting NTPDATE working before you add in NTP to the 
> overall problem set.

So I did.

> 5.  Some external time-servers used for synching are "private" and you 
> may not have access to them.  There is a good listing for these at 
> http://www.eecis.udel.edu/~mills/ntp/servers.htm.  I reviewed the 
> listing for my area and selected Stratum-2 time-servers that were marked 
> "public".  In any case, it is good practice (courtesy) to let the 
> sys-admin know you are using their time-server.

Thank you very much for this link, I found some good servers there!

> 6.  I had a LOT of initial frustrations getting NTPDATE to work, before 
> I finally determined that the external time-server I was trying to use 
> was down!  This is an obviouly simple thing, but I overlooked it for 
> quite a while!  Check it out with a ping to see if it is really there 
> <g>.  The IP numbers you used worked for me today...

> That is a complete data-dump from here.  I wanted a local time-server 
> for my home LAN, and set this up.  Strangely, I had a great deal of 
> problems getting this going on my IPMasq router (an i386 machine) but 
> when I moved it to the Alpha, it started working immedialtely.  I never 
> figured that one out ... maybe something to do with the dual 
> NICS...dunno!  All the stuff I "learned" above was on the i386 machine. 
>   I have had absolutely NO problems with the setup on the Alpha.
> 
> Sorry for the length....
> 
> Cheers,
> -Don Spoon-
> 

Once more, thank you very much for your complete answer!
Now will have a look at the systemtime tomorrow morning
so I will see if everything is alright!

Best regards,

Christoph



Reply to: