rees@pisa.ifs.umich.edu (Jim Rees) (10/16/90)
You need to keep your node clocks synchronized to within 5 minutes of each other if you want NCS based services like the registry to work right. Nodes can easily drift 5 minutes apart in a few weeks, so you need some way to keep them synchronized. The best way is with xntp. It requires that you have TCP and needs some configuration. If you don't want to go to that much trouble, I have a program that simply sets one node's clock from another node on the same Domain network. It doesn't require TCP or any configuration other than the name of the node to acquire the clock from. You can get it by anonymous ftp from dabo.ifs.umich.edu, in 'date.tar.Z'. I haven't included the source because it uses unreleased calls.
hj412fr@duc220.uni-duisburg.de (Frik) (10/19/90)
Are there any compelling reasons for not using the timed daemon to synchronize clocks? I did that, and while possibly I have placed a time-bomb into the uid-generation mechanism, it has not showed up after several weeks of operation. Martin Anantharaman FB7, FG7 (Mechanik) Work: +49 (203) 379-3336 Universitaet -GH- Duisburg Home: +49 (203) 37 65 89 Lotharstr. 1 FAX: +49 (203) 379-3052 4100 Duisburg 1 E-Mail: hj412fr@duc220.uni-duisburg.de West Germany
aerostr@ecf.toronto.edu (W. Graham Elliott) (10/19/90)
In article <9010190839.AA03867@duc220.uni-duisburg.de> hj412fr@duc220.uni-duisburg.de (Frik) writes: >Are there any compelling reasons for not using the timed daemon to >synchronize clocks? I did that, and while possibly I have placed a >time-bomb into the uid-generation mechanism, it has not showed up >after several weeks of operation. I have been successfully running the timed daemon on a series of DN3xxx's and DN4xxx's since March. I have noticed no problems, so far. ------------------------------------------------------------------------- Graham Elliott aerostr@ecf.toronto.edu Institute for Aerospace Studies graham.elliott@canremote.UUCP University of Toronto, Canada
mcguire@math.uiowa.edu (Charlie McGuire) (10/19/90)
In article <9010190839.AA03867@duc220.uni-duisburg.de>, hj412fr@duc220.uni-duisburg.de (Frik) writes: |> Are there any compelling reasons for not using the timed daemon to |> synchronize clocks? I did that, and while possibly I have placed a |> time-bomb into the uid-generation mechanism, it has not showed up |> after several weeks of operation. I've been running timed for about 10 months on 8 nodes with no apparent problems. Charlie McGuire mcguire@math.uiowa.edu Systems Programmer mcguire@cs.uiowa.edu Dept of Computer Science The University of Iowa
thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (10/19/90)
> Are there any compelling reasons for not using the timed daemon to > synchronize clocks? Only if you run Mentor software. As soon as the time gets changed, Mentor (version 7.0) will no longer start programs. "It's not a bug, it's a FEATURE!" > I did that, and while possibly I have placed a > time-bomb into the uid-generation mechanism, it has not showed up > after several weeks of operation. I don't believe there's a time-bomb. Unless I'm horribly off-base, Apollo keeps (the equivalent of) two clocks. There's the base time, which is set at boot-time (actually, system shutdown?) that ticks merrily away, and there's the offset that timed (or '/bin/date' as root) have set up. Until you reboot, I don't believe that offset is used for creating UIDs. (Incidentally, confirmation or refutation of the above by an 'in-the-know' HP/Apollo person would be appreciated.) John Thompson (jt) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com As ever, my opinions do not necessarily agree with Honeywell's or reality's. (Honeywell's do not necessarily agree with mine or reality's, either)
roger@GW1.AGS.BNL.GOV (Roger A. Katz) (10/20/90)
ahhh, this might explain a problem i have been having.
I use timed, and can report no problems with its use. However I have
cron running on a node, and we have had an occurrance where cron started a
job two hours early. ie. job is to start at 17:00 started at 15:00, yet the
time of the node on which cron was running appeared correct.. useing /com/date
or lcnode or whatever to check the time. Does cron use the boot-time clock?
is there a command to let me see what time the boot-time clock is?
Email: roger@gw1.ags.bnl.gov Roger A. Katz
AGS Software Controls Group
Brookhaven National Laboratory
Upton, N.Y. 11973-5000
(516) 282-2732
I'm sure, I might be wrong, but I'm sure.rees@pisa.ifs.umich.edu (Jim Rees) (10/20/90)
In article <9010191740.AA08224@gw1.ags.bnl.gov>, roger@GW1.AGS.BNL.GOV (Roger A. Katz) writes:
I use timed, and can report no problems with its use. However I have
cron running on a node, and we have had an occurrance where cron started a
job two hours early. ie. job is to start at 17:00 started at 15:00, yet the
time of the node on which cron was running appeared correct..
Two hours is a long time. I would suspect something more like you have the
time zone set wrong. Or I suppose cron might get confused if the time was
way off when you booted the node. I usually try to get the time set within
ten minutes or so using offline "calendar," then fine-tune it with something
like xntp after booting.
Does cron use the boot-time clock?
"cron" is just an ordinary Unix program and uses the same clock that "date"
uses.
is there a command to let me see what time the boot-time clock is?
Not that I know of, but you could write one. Use uid_$gen() to generate a
uid, and extract the time out of the top 36 bits.e07@nikhefh.nikhef.nl (Eric Wassenaar) (10/29/90)
> > Are there any compelling reasons for not using the timed daemon to > > synchronize clocks? > > Only if you run Mentor software. As soon as the time gets changed, Mentor > (version 7.0) will no longer start programs. "It's not a bug, it's a FEATURE!" I am running the timed daemon on Mentor 7.0 idea-stations and board-stations without any problems with Mentor programs whatsoever. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl
thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (10/29/90)
Hi --
I'm cross-posting this to the apollo list and also to the Mentor one.
(Sorry if, like me, you're on both.) It seems relevent.
> <<forwarded message>>
> from: umix.cc.umich.edu!apollo-request
> subj: re: An easy way to keep your clocks synchronized
>
> > > Are there any compelling reasons for not using the timed daemon to
> > > synchronize clocks?
> >
> > Only if you run Mentor software. As soon as the time gets changed, Mentor
> > (version 7.0) will no longer start programs. "It's not a bug, it's a FEATURE!"
>
> I am running the timed daemon on Mentor 7.0 idea-stations and
> board-stations without any problems with Mentor programs whatsoever.
I believe that you've just been exceedingly lucky. I had the same situation
when I started using 'timed'. Because I had no problems with it at first, I
figured that I was safe. It wasn't until after I had set up timed on all the
10.2 nodes (we had mixed 9.7, 10.1, and 10.2 at the time), and waited a day or
two, that everybody started complaining about Mentor tools refusing to start.
If your calendars are close, and the clocks aren't drifting too far relative
to each other, you'll appear to be safe.
However, Mentor stated in CSB #79 (July 89) on page 20 that they check, as
part of their authorization-scheme, whether you've changed the date since
boot-time. Now, whether this is stupid is not under debate. :-)
However, as long as they _do_ do this check, I would not advise running
'timed', and in fact would advise _against_ it.
BTW: Does anyone at Mentor want to comment on whether the 10.3 version of
Mentor 7.0 (7-UP) still has this bug/feature? If I hear nothing, I guess
I'll play guinea-pig with a node and find out the hard way....
John Thompson (jt)
Honeywell, SSEC
Plymouth, MN 55441
thompson@pan.ssec.honeywell.com
As ever, my opinions do not necessarily agree with Honeywell's or reality's.
(Honeywell's do not necessarily agree with mine or reality's, either)