mcdonald@LOKI-GW.EDSG.HAC.COM (louis mcdonald) (07/26/88)
====================================
Wanted: Apollo Wizard Answer
====================================
Does anyone know of a good way to keep all
the calendars on an apollo network in sync?
I do not want to shut down a node to rest the
onboard clock. I would like to, from one node,
start a job that hops from node to node to
set the clock to the correct time.
There is nothing worse than seeing a network where
one node thinks it is 8:00 am PST July 25, 1988
and another thinks it is 9:00 pm PDT July 21, 1988.
This is create for file creation, modification times...
================================+========================================
Louis McDonald | HACNet: Athena::Exos%"mcdonald@loki"
Hughes Aircraft 213-616-3134 | Arpanet: mcdonald%loki@hac2arpa.hac.com
/ \ +----------------------------------------
\__|_/ | Smail: P.O. Box 902; EO/E53/E270
| | El Segundo, CA 90245
__/ ___ o _ +----------------------------------------
(_) \___(___)__(__|__|_/_)__/ | These are my opinions and not Hughes'
================================+========================================
When your software is not working; who you gonna call: `Code Buster'
================================+========================================wesommer@ATHENA.MIT.EDU (Bill Sommerfeld) (07/27/88)
I think you can get a daemon that synchronizes clocks for you. There's a protocl known as "NTP" (Network Time Protocol); and there's an implementation of NTP which runs under BSD4.3 UNIX; however, I'm not sure where the "official sources" are. It should run unmodified on SR10, but I haven't tried it yet. If not, it would be pretty easy to write. You need one or more central nodes, preferably with a WWV clock, running a time of day server. There's an RFC out on this (don't know the number). RFC958 documents the protocol; RFC957 and 956 are related RFC's. - Bill
rees@MAILGW.CC.UMICH.EDU (Jim Rees) (07/27/88)
There's a protocl known as "NTP" (Network Time Protocol); and there's
an implementation of NTP which runs under BSD4.3 UNIX; however, I'm
not sure where the "official sources" are. It should run unmodified
on SR10, but I haven't tried it yet.
I've been told that the bsd4.3 time daemon (timed) uses the adjtime()
system call, which is not implemented in sr10. I suspect that you could
fix it to use settimeofday(), which is not as good since it doesn't
guarantee that time increases monotonically. But it's still better than
having skewed clocks (clock-kabobs?).
-------jec@iuvax.cs.indiana.edu (James E. Conley) (07/27/88)
The problem as far as I know is that you have to reboot to change
the TOD clock. The date(1) command under DOMAIN/IX doesn't do the job,
and the CALENDAR utility only seems to run under the MD.
III Usenet: iuvax!jec
UUU I UUU ARPANet: jec@iuvax.cs.indiana.edu
U I U Phone: (812) 335-7729
U I U U.S. Mail: Indiana University
U I U Dept. of Computer Science
UUUIUUU 021-E Lindley Hall
I Bloomington, IN. 47405
III (Home of Bob Knight and the Indiana Hoosiers)dennis@gandalf.nosc.mil (Dennis Cottel) (07/27/88)
Jim Rees writes: >I've been told that the bsd4.3 time daemon (timed) uses the adjtime() >system call, which is not implemented in sr10. But I thought the big deal about SR10 was that it had all the functions of BSD4.3 and SYSVR3! An arbitrary BSD program is supposed to port and run with no changes, right? Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 553-1645 dennis@NOSC.MIL sdcsvax!noscvax!dennis
guy@gorodish.Sun.COM (Guy Harris) (07/29/88)
> At sr10, you can reset the node time without shutting down. If you don't > have sr10, you can't. I think you can get a daemon that synchronizes > clocks for you. If not, it would be pretty easy to write. You need > one or more central nodes, preferably with a WWV clock, running a time > of day server. There's an RFC out on this (don't know the number). Well, there are several time protocols: RFC868 describes the "Time protocol", which is a protocol that permits a client to request a server's notion of the current time, in seconds since 00:00 1 January 1900 GMT. It's a very simple protocol, and is provided both as a TCP-based and UDP-based service. This sounds like the one you're referring to. From a previous article here: "RFC958 documents the protocol; RFC957 and 956 are related RFC's." This refers to the Network Time Protocol, which the introduction to RFC958 describes as "a protocol for synchronizing a set of network clocks using a set of distributed clients and servers." The Berkeley time daemon uses its own protocol; I don't know if there's an RFC for it or not. It's described in a section of the 4.3BSD System Manager's Manual. > The timezone is a little trickier. It's stored in a completely separate > way. Unfortunately, I think you still need to shut down to change the > timezone, even at sr10. This is a lot better than Unix in the old days, > which required you to recompile all your programs to change the timezone. The *VERY* old days. Ever since V7, the name and GMT offset of the current time zone, as well as an indication of whether DST was observed or not, has been fetched at run time from some source. It came from the kernel in V7, so you either had to recompile the system or have some program to patch the kernel; 4.2BSD added a system call to change this information. It came from the environment in S3 and S5. Unfortunately, neither of those permitted you to change the DST *rules*. 4.2BSD had more than the US rules in it; the kernel would tell you which rule set to use. However, you had only a few rule sets to choose from, and the rule sets were compiled in. S5R3.1 allows you to specify the *current* year's rules in an environment variable, and POSIX proposes a slight improvement over this. The best way to do it is to fetch it from a file; public-domain code to implement this has been posted to the net, and has been adopted by a number of UNIX vendors.
gallen@apollo.COM (Gary Allen) (07/30/88)
In article <61901@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: [......] >The *VERY* old days. Ever since V7, the name and GMT offset of the current >time zone, as well as an indication of whether DST was observed or not, has >been fetched at run time from some source. It came from the kernel in V7, so >you either had to recompile the system or have some program to patch the >kernel; 4.2BSD added a system call to change this information. It came from >the environment in S3 and S5. Hey Guy, Watch what you're calling *VERY* old :-) Gary Allen Apollo Computer Chelmsford, Ma {decvax,yale,umix}!apollo!gallen I'm not older than dirt. I did know it when it was only sand, though.