Timeslave question

[Peter Silva]

|> > We are using timeslave to track an NTP primary.  Assuming that the
|> > 'err' column in the debugging output is in units of milliseconds, we
|> > seem to be off by as much as 1/4 second at times, both fast and slow,
|> > though we're usually under 150 ms.  I have two questions:
|> 
|> It's all milliseconds.  250 msec seems rather high.  Is the system
|> suffering kernel printf's?
|>

We run a couple of dozen Irises and have the same problem.  It seems especially
slow to sync up after systems have been down for a while (after a morning
reboot, (no, it wasn't down any amount of time before or after) the station is
still 1500 ms off at 4:30pm). 

|> > Maybe I should just give up and install xntp, but I was trying to get
|> > decent time without the headaches of using yet another
|> > vendor-unsupported package.
|> 
|> If you want really good time, that might be a good idea.  Increasing the
|> measurement rate to '-r 15' would probably make timeslave much more
|> accurate at modest cost.
|>

I tried  (not too hard) building xntp, but it absolutely wanted the 
"tickadj" kernel variables to exist.  Is there a version hacked for the IRIS? 
I've been using ntp on two stations for two months, on the same lan, 
configured to go to the same servers, (as a test).  One of the 
stations is un-loaded, the other has me pounding away on it all day.  
ntp runs, and complains about the lack of tickadj, but seems to have
a "plan B" to deal with it.

The results vary wildly from week to week.  Sometimes both stations are within
a millisecond or two of whatever stratum 1 server it's picked, sometimes it's
off by as much as a hundred milliseconds.  And, of course, when it gets that
far off, it starts polling every 64 seconds... AARRRGGHH!
My checks are just using ntpdc.

My station is the one that is usually goes nuts, but at the moment the other
one is nuts too because it's been down awhile, and is still syncing up.  My 
station usually has wildly high Dispersion numbers too, of course (but today 
they seem almost reasonable, (nothing over 300).

|> I've seen nearby *ntp machines claiming to be 3 msec from UTC, but

I don't think I'm getting more than double or triple the precision of 
timeslave at the moment.   Why is still a mystery.

I won't trust it until I know why this stuff happens.


Peter Silva			OS Support 
psilva at cid.aes.doe.ca		Dorval Computing Centre
(514) 421-4692			Atmospheric Environment Service