mcneill@eplrx7.uucp (Keith McNeill) (04/02/91)
I have an isolated (e.g. not hooked up to the internet) network that I would
like to synchronize the time on. We do not have a radio clock.
Over the long easter weekend I set up our 4 Sun disk servers with xntpd to
attempt to synchronize their clocks. They all started out (Friday) with
fairly uniform time (couple of seconds off each other). By Monday their
clocks drifted so that the servers were several minutes off each other.
My setup:
in my rc.local file I have
tickadj -Aqs; xntpd
on one of my servers /etc/ntp.conf looks like:
-----
peer 138.196.252.10 # zip
peer 138.196.252.42 # pix
peer 138.196.80.2 # mds
driftfile /etc/ntp.drift
-----
Question: Do I want to set dosynctodr = 0, as tickadj -s will do?
Am I missing something?
Thanks,
Keith
--
Keith McNeill | Du Pont Company
eplrx7!mcneill@uunet.uu.net | Engineering Physics Laboratory
(302) 695-9353/7395 | P.O. Box 80357
| Wilmington, Delaware 19880-0357
--
The UUCP Mailerdebbieg@smokey.sandiego.NCR.COM (04/03/91)
Keith, I also run a local isolated network with 4 servers (not SUNs). What I do is set up 1 server as the main server. It synchronizes to its local clock as a stratum 1 clock. Its config file looks like: server 127.127.1.1 #local clock fudge 127.127.1.1 time1 0.00 flag1 1 The second server synchronizes to server 1 plus to its own local clock at stratum 2 in case the main server dies. peer 132.242.114.201 #main server 127.127.1.2 #local clock fudge 127.127.1.2 time1 0.00 flag1 1 The third server syncs to servers 1,2 plus its own clock at stratum 3. The fourth server syncs to servers 1,2,3 plus its own clock at stratum 4. All other hosts on the network sync to servers 2,3,4. Plus in the rc file (on servers and hosts), I run ntpdate specifying all 4 servers before starting xntpd. (Note - it is important to set the time to that of already running servers especially if you reboot the main server.) I hesitate to post this as I know it is not the intended use of NTP, however, it does seem to work really well to keep an isolated network of systems sync'ed to each other. Debbie Debbie Galeazzi NCR Corporation E&M - San Diego, California Debbie.Galeazzi@SanDiego.NCR.COM
debbieg@smokey.sandiego.NCR.COM (04/03/91)
> > I have an isolated (e.g. not hooked up to the internet) network that I would > like to synchronize the time on. We do not have a radio clock. > > Over the long easter weekend I set up our 4 Sun disk servers with xntpd to > attempt to synchronize their clocks. They all started out (Friday) with > fairly uniform time (couple of seconds off each other). By Monday their > clocks drifted so that the servers were several minutes off each other. > > Keith, (My reply to you bounced, so I just posted.) I also run a local isolated network with 4 servers (not SUNs). What I do is set up 1 server as the main server. It synchronizes to its local clock as a stratum 1 clock. Its config file looks like: server 127.127.1.1 #local clock fudge 127.127.1.1 time1 0.00 flag1 1 The second server synchronizes to server 1 plus to its own local clock at stratum 2 in case the main server dies. peer 132.242.114.201 #main server 127.127.1.2 #local clock fudge 127.127.1.2 time1 0.00 flag1 1 The third server syncs to servers 1,2 plus its own clock at stratum 3. The fourth server syncs to servers 1,2,3 plus its own clock at stratum 4. All other hosts on the network sync to servers 2,3,4. Plus in the rc file (on servers and hosts), I run ntpdate specifying all 4 servers before starting xntpd. (Note - it is important to set the time to that of already running servers especially if you reboot the main server.) I hesitate to post this as I know it is not the intended use of NTP, however, it does seem to work really well to keep an isolated network of systems sync'ed to each other. Debbie Debbie Galeazzi NCR Corporation E&M - San Diego, California Debbie.Galeazzi@SanDiego.NCR.COM
rbthomas@frogpond.rutgers.edu (Rick Thomas) (04/03/91)
Thanks Debbie,
Your posting gives a good solution with useful "how-to" instructions
for a serious problem faced by lots of people who (for whatever reason)
do not have general internet access.
The icing on the cake is to get the software from NIST that will allow
a unix host to dial in to the NIST clock server once in a while and
adjust the "local stratum 1" clock to keep reasonably near to standard time.
To get a copy this software, write or phone NIST at
Office of Standard Reference Materials
Chemistry Building, Room B311
NIST
Gathersburg, MD 20899
(301)-957-OSRM (OSRM=6776)
Ask for the "Automated Computer Time Service" software. It comes on
PC/MS-DOS 5.25-in floppys. You will have to figure out for yourself
how to upload it to your unix box.
Enjoy!
Rick
========================================================================
Rick Thomas, Manager
Supercomputer Remote Access Center, Rm D117
Rutgers University, College of Engineering
Brett and Bowser Roads
Piscataway, NJ 08855-0909
Phone: (908) 932-4301
Internet: rbthomas@jove.rutgers.edu
UUCP: {any backbone site}!rutgers!rbthomas
Alternate UUCP: {convex|c1apple|karna}!kingtut!rbthomas
"Soap and education are not as sudden as a massacre,
but they are more deadly in the long run." -- Mark Twain
========================================================================per@erix.ericsson.se (Per Hedeland) (04/09/91)
In article <9104021624.aa17693@ncrcom.DaytonOH.NCR.COM> debbieg@smokey.sandiego.NCR.COM writes: >I hesitate to post this as I know it is not the intended use of NTP, >however, it does seem to work really well to keep an isolated network >of systems sync'ed to each other. I think your hesitation is unwarranted; I quite agree that NTP is really very useful even without access to the Real Time (tm), and your suggestion of using ntpdate solves (I think - haven't tried it yet) the remaining problem I had, how to achieve reliable redundancy in a setup like this. Also, from a number of recent submissions here, it seems there is quite some interest in this, and I certainly hope I don't offend anyone by sharing some of my experiences... I was already using the principle you suggested, i.e. N "masters" with escalating stratum for their local clocks, and I also believe I have a good grip on the other half of the problem - the Fine Art of tweaking the 'time1' value to achieve a) correction of difference wrt whatever reference for real time is available and b) minimum of "steady state" drift away from real time. If anyone's interested, I have a script that, given an observed difference wrt real time, does the calculations and tweaking with the aid of a couple of small programs and at(1). Regarding a) above I don't believe it is advisable to ever manipulate the system clock directly when xntpd is running - there are certainly situations where an xntpd synced to the local clock will abandon it in favor of other servers at higher strata, subsequently reversing the change made to the local clock. It would be nice to know exactly which these situations are, presumably relevant factors include number of other servers, their agreement with each other vs disagreement with the local clock, difference in stratum levels, mode (active/passive etc). I *think* there is an alternate solution for the reliable redundancy problem in there somewhere, but I haven't found it. As for getting real time from some dialup service (I have local access to one of those too), I (obviously) don't know much about the internals of xntpd, but it seems to me that writing a clock driver for this is less than ideal - a program that won't do DNS lookups because of the disruption that blocking on such can cause would presumably not appreciate waiting for a dialing sequence to complete, and inserting a separate process or somesuch to do the dialing asynchronously will probably cause a lot of precision to be lost. What I did was to write a simple program to dial up the service and compute the difference wrt the local clock, and then (if it was deemed too big) feed the difference to the abovementioned script. This can of course all be automated, which I have done with good results - the local clock is typically within +/- 20ms of the time reported by the dialup service, with few adjustments required. --Per Hedeland per@erix.ericsson.se or per%erix.ericsson.se@uunet.uu.net or ...uunet!erix.ericsson.se!per