als@bohra.cpg.oz (Anthony Shipman) (05/25/90)
I have just set up three machines to run with synchronised clocks using /etc/timed. This works well and the times are within +- 1 sec. But this means that the system time is fluctuating backwards and forwards by up to a second (in the steady state). The documentation I have warns that this might upset some programs that maintain an internal idea of the system time. What standard programs might be upset? Would cron be? Is there a danger of cron starting a job twice if the time jumps back 2 secs as the job starts? I remember someone on one of these news groups reporting a problem with cron starting a job twice sometimes. Does anyone have any experience they would like to impart? Thanks -- Anthony Shipman ACSnet: als@bohra.cpg.oz.au Computer Power Group 9th Flr, 616 St. Kilda Rd., St. Kilda, Melbourne, Australia D
roy@phri.nyu.edu (Roy Smith) (05/25/90)
In <103@bohra.cpg.oz> als@bohra.cpg.oz (Anthony Shipman) writes: > I have just set up three machines to run with synchronised clocks using > /etc/timed [...] Does anyone have any experience they would like to impart? Having used to run timed, I would say the best advice is to chuck it and use ntpd instead. If you are connected to the Internet, you can keep your clock within a fraction of a second of The Right Time, and if you're not, at least you can keep all of your machines on an ethernet within a very small fraction of a second of each other. The real problem with timed is that you have no control over who ends up being the master clock. On our net, it usually ended up being an Iris in another building 4 blocks away that I had no control over, and which generally had its clock set to some totally random time. I eventually got pissed at having people come into my office complaining that their $12 quartz-and-plastic Casio wristwatch kept better time than their $5000 workstation. Actually, before we even ran timed, I used to just have each of our diskless workstations run rdate when they booted. This at least started them all out with a clock that was within about a second of each other, which doesn't approach the precision you get with ntpd, but may be good enough for most purposes. Most of our machines are 4-Meg diskless workstations, on which memory is a critical resource. I havn't yet decided if running ntpd on all of them is worth it, but the choice is between ntpd and rdate-on-bootup-then-freerun, not between ntdp and timed. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy "Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
Anselmo-Ed@cs.yale.edu (Ed Anselmo) (05/25/90)
>>>>> On 25 May 90 14:11:39 GMT, roy@phri.nyu.edu (Roy Smith) said:
Roy> Most of our machines are 4-Meg diskless workstations, on which
Roy> memory is a critical resource. I havn't yet decided if running
Roy> ntpd on all of them is worth it, but the choice is between ntpd
Roy> and rdate-on-bootup-then-freerun, not between ntdp and timed.
You don't have to run ntpd on all the workstations. You can do
something like
0 * * * * sleep `expr $$ % 60`;/usr/local/etc/ntp -s -f ntpd-host1 ntp-host2
out of cron to keep the workstation clocks in sync with the machines
running ntpd.
--
Ed Anselmo anselmo-ed@cs.yale.edu {harvard,decvax}!yale!anselmo-edAnselmo-Ed@cs.yale.edu (Ed Anselmo) (05/25/90)
Me> You don't have to run ntpd on all the workstations. You can do
Me> something like
Me> 0 * * * * sleep `expr $$ % 60`;/usr/local/etc/ntp -s -f ntpd-host1 ntp-host2
Me> out of cron to keep the workstation clocks in sync with the machines
Me> running ntpd.
Proving that I am a true wannabe pseudo-wizard. You have to escape
the '%' with a backslash, lest cron treat it as a newline. No wonder
my clocks were drifting.
--
Ed Anselmo anselmo-ed@cs.yale.edu {harvard,decvax}!yale!anselmo-edkaul@icarus.eng.ohio-state.edu (Rich Kaul) (05/25/90)
In article <1990May25.141139.14193@phri.nyu.edu> roy@phri.nyu.edu (Roy Smith) writes:
Most of our machines are 4-Meg diskless workstations, on which
memory is a critical resource. I havn't yet decided if running
ntpd on all of them is worth it, but the choice is between ntpd
and rdate-on-bootup-then-freerun, not between ntdp and timed.
You might just have your server run ntpd to get the real time (from
whatever source) and then run rdate on the clients as often as you
like. We find every 4 hours seems to work, although you might want to
do it hourly. A simple little crontab entry like
7 * * * * /usr/ucb/rdate [timehost] 2>&1
would update all your little 4M hosts to sync up with your timehost at
7 minutes past the hour (you might stagger it a bit if you have a lot
of clients). We do something similar around here and it seems to work
well. At least I haven't been getting any more complaints about
drifting clocks!
-rich
-=-
Rich Kaul | "Every man is given the key to the door
kaul@icarus.eng.ohio-state.edu | of heaven; unfortunately, the same key
or ...!osu-cis!kaul | opens the door to hell."jik@athena.mit.edu (Jonathan I. Kamens) (05/26/90)
In article <1990May25.141139.14193@phri.nyu.edu>, roy@phri.nyu.edu (Roy Smith) writes: |> The real problem with timed is that you have no control over who |> ends up being the master clock. On our net, it usually ended up being an |> Iris in another building 4 blocks away that I had no control over, and |> which generally had its clock set to some totally random time. I |> eventually got pissed at having people come into my office complaining |> that their $12 quartz-and-plastic Casio wristwatch kept better time than |> their $5000 workstation. First of all, the procedure for "electing" a timed master does not happen unless the '-M' option is specified on at least one of the machines running timed. If none of your machines start timed with '-M', then you can control who gets to be the master, and this isn't a problem. Second, another problem with timed is that if there is more than one master, then all the masters keep themselves in sync by averaging all of their times (because they assume that none of them possesses the absolute correct time). This is a problem. The way we do things here at Athena is: 1. There is one master on each subnet. All the other machines are slaves only. 2. The timed sources are modified so that they do not do the clock averaging between masters; that is, timed on the masters assumes that they have the correct time, no matter what. 3. All of our masters run ntpd, which makes the assumption above valid. Therefore, timed's on masters never adjust their own time, does, and timed's on slaves get the correct time from the ntpd-synced masters. This works very well, unless the master on a subnet goes down. If this happens (it doesn't happen very often) and it isn't noticed immediately by the network monitor (or, at least, it isn't noticed by any humans *watching* the network monitor :-), the workstation clocks begin to drift until they eventually are too far off for Kerberos to work (Kerberos has a 5-minute window), and this alerts us to the problem so we can fix it. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (05/26/90)
I just run rdate from cron once a day. I admit I took some (possibly unneeded) precautions with cron getting confused. Have I just not noticed problems with doing this? -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us