rbraun@spdcc.COM (Rich Braun) (04/12/91)
I recently brought up timed on a couple of SCO Unix systems and an RS-6000, hoping to have a reliable, synchronized time source on my TCP/IP LAN. Instead, I have a bunch of synchronized systems which lose about a minute per day. The SCO documentation doesn't say anything about how one sets up a reference time source; timed only serves the purpose of synchronization, and there's no way of telling it which system is "the" reference source. How do I solve this problem? I'm working for a company whose business is selling clocks, so needless to say, inaccurate clocks are particularly annoying to me ;=) -rich
k2@bl.physik.tu-muenchen.de (Klaus Steinberger) (04/12/91)
rbraun@spdcc.COM (Rich Braun) writes: >I recently brought up timed on a couple of SCO Unix systems and an RS-6000, >hoping to have a reliable, synchronized time source on my TCP/IP LAN. >Instead, I have a bunch of synchronized systems which lose about a >minute per day. The SCO documentation doesn't say anything about how >one sets up a reference time source; timed only serves the purpose of >synchronization, and there's no way of telling it which system is "the" >reference source. >How do I solve this problem? I'm working for a company whose business >is selling clocks, so needless to say, inaccurate clocks are particularly >annoying to me ;=) timed is the best method to get synchronized funny clocks. Instead it's better to use ntp. (Network time protocol) It can synchronize to a master clock. The master clock can be a stable quartz clock, or even better a radio time standards. There are many servers for ntp in the internet, and it's possible to get a synchronized clock with a maximum error of 10 milliseconds. Look into comp.protocols.time.ntp for more information. Sincerely, Klaus Steinberger -- Klaus Steinberger Beschleunigerlabor der TU und LMU Muenchen Phone: (+49 89)3209 4287 Hochschulgelaende FAX: (+49 89)3209 4280 D-8046 Garching, Germany BITNET: K2@DGABLG5P Internet: k2@bl.physik.tu-muenchen.de
mju@mudos.ann-arbor.mi.us (Marc Unangst) (04/14/91)
rbraun@spdcc.COM (Rich Braun) writes: > minute per day. The SCO documentation doesn't say anything about how > one sets up a reference time source; timed only serves the purpose of > synchronization, and there's no way of telling it which system is "the" > reference source. You need to designate the master time server, which is the machine whose clock is assumed to be correct, and the reference source for the other machines. If you give timed the "-m" flag when you start it up, it will tell the daemon to poll the network looking for other timed master servers; if there aren't any, then it will become the master server and notify the other slave timed's of this. If the master server drops off the net for some reason, the slave timed's are supposed to hold an "election" to decide who gets to be the new master. I believe the election procedure goes something along the lines of computing the average of all the slaves' clocks, and then picking the timed whose time was closest to the average as the new master. A timed that has the -m flag set (but didn't become a master when started, because there was already a master on the network) has precedence over timed's without the -m flag. I believe there is also a utility (timeadm?) to maintain the timed server, change which machine is the master server, etc. All of this is documented nicely in the timed(1) man page, BTW. -- Marc Unangst | mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" ...!hela!mudos!mju |
georgn@comspec.uucp (Georg S. Nikodym) (04/15/91)
In article <k2.671438714@woodstock>, k2@bl.physik.tu-muenchen.de (Klaus Steinberger) writes: > rbraun@spdcc.COM (Rich Braun) writes: > > >I recently brought up timed on a couple of SCO Unix systems and an RS-6000, > >hoping to have a reliable, synchronized time source on my TCP/IP LAN. > >Instead, I have a bunch of synchronized systems which lose about a > >minute per day. The SCO documentation doesn't say anything about how > >one sets up a reference time source; timed only serves the purpose of > >synchronization, and there's no way of telling it which system is "the" > >reference source. Yes there is. In the file "/etc/tcp" (which is linked to /etc/rc2.d/Snntcp) you have a line that starts timed. Timed invoked with the -M option will _allow_ that time daemon to become a "master" should the running master go away. If you only want one master, then only use -M on one of the timeds (ignoring the fact the all the other clocks on the net will get stupid when you reboot this machine). You can use the "timedc" command to make queries of the timed system (like finding out who is master, what the time difference is between 2 nodes, etc). > >How do I solve this problem? I'm working for a company whose business > >is selling clocks, so needless to say, inaccurate clocks are particularly > >annoying to me ;=) There is another problem here, however, and that is the problem of the time clock hardware on PCs today. I have never seen one keep accurate time for any duration. There's further goo in the works because UNIX keeps its own time, which depending on how much your hardware beats on the kernel (which in this case is a fair bit), it loses time as well. The solution to this is to have one machine (which would also be the master timed) with a modem call one of the atomic clocks on the continent. I've seen one for XENIX that called a naval observatory in Washington to get the time, the program would then run something like "setclock(ADM)" which sets your hardware clock. Run this on a daily basis and you're set. > timed is the best method to get synchronized funny clocks. > > Instead it's better to use ntp. (Network time protocol) > It can synchronize to a master clock. The master clock can be a stable > quartz clock, or even better a radio time standards. You'll probably be able to get this from the free BSD sources (don't flame, I guessing ;-) Personally, not being inclined to re-invent wheels, I'd use the timed you already have. > There are many servers for ntp in the internet, and it's possible to > get a synchronized clock with a maximum error of 10 milliseconds. > > Look into comp.protocols.time.ntp for more information. True, though you may not be able to get to them via phone... :-( -- Georg S. Nikodym - 466-1079 | "Eastern Germany's defunct legal system no corporate affiliation | leaves an endless trail of papers and UUCP: ...!comspec!georgn | investigators investigating investigators." RFC822: georgn@comspec.uucp | -an example of legal recursion???
rbraun@spdcc.COM (Rich Braun) (04/17/91)
mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >You need to designate the master time server... > >If the master server drops off the net for some reason, the slave >timed's are supposed to hold an "election"... > >All of this is documented nicely in the timed(1) man page, BTW. Since my original posting on this thread, I've done some more experimentation and determined the following in an empirical way: You *cannot* run an isolated subnet with more than one "timed -m" running. The documentation (from both IBM/AIX and SCO/Unix) fails to note one VERY important fact about the "-m" flag: it forces the daemon to pay attention to time-adjustment packets sent from other daemons also run with the "-m" flag. This will cause the entire subnet to lose quite a lot of time each day if two or more "timed -m" daemons are running, unless you have a periodic task which queries a reference clock on a rather frequent basis. I consider this a bug; I'd like to be able to run more than one daemon capable of picking up where another left off, if the system goes down for an extended period, but not if I have to give up accuracy. So, to summarize: timed will work fine on an isolated Ethernet as long as you run it without "-m" on *all* systems except the one which is most reliable (read: up 99.9999% of the time) and accurate. As shipped, SCO Unix doesn't start up timed, but does include "-m" in the commented-out line; you have to not only uncomment the command line in /etc/tcp, but also get rid of "-m" on all systems but one. To SCO and other vendors: please take a look at this documentation and/or software deficiency before your next release. Thanks. -rich