xiaoyan@ecf.toronto.edu (XIAO Yan) (01/14/91)
I am using timeslave to synchronize our 4D/310. However, timeslave is working really hard and tries to tune the clock almost every minute. The manual says a option '-r' sets the time interval. But whatever the value to use this option, timeslave seems not to rest for more than two minutes. Does anybody have a better solution? xiao <xiaoyan@ecf.toronto.edu>
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (01/15/91)
In article <1991Jan14.021755.24425@ecf.utoronto.ca>, xiaoyan@ecf.toronto.edu (XIAO Yan) writes: > > I am using timeslave to synchronize our 4D/310. However, timeslave is > working really hard and tries to tune the clock almost every minute. > > The manual says a option '-r' sets the time interval. But whatever > the value to use this option, timeslave seems not to rest for more than > two minutes. I generally use repetition rates of around 15 seconds, since timeslave is generally run only on machines that want the time as good as they can get it. It's hard to keep your clock within a few milliseconds of the master unless you check every 10**5 milliseconds, assuming your system is consistent only to one part in 10**5. Timeslave tries every 90 seconds until it has made enough measurements so that its error damping should be stable. It thinks its filters have stopped hunting after about 11 measurements, provided the error signals from the filters have become stable. Timeslave should start using your value about 15 minutes after you start it. You can generally tell what is going on by turning on debugging, with either one or more '-d' arguements or with SIGUSR1. SIGUSR2 reduces the debugging level. I almost never run with the maximum debugging level, because of the volume of cruft that puts into /usr/adm/SYSLOG. Provided the network link to the master is not too bad, this initial burst of activity should not be a significant load. Please note that timeslave was originally developed a few years ago to synchronize the SGI corporate network with a GEOS clock at another company over a 9600 bit/sec TCP/IP/Cypress link. That link was very heavily and asymmetrically loaded. Vernon Schryver, vjs@sgi.com