Path: utzoo!utgpu!watserv1!watmath!att!emory!sol.ctr.columbia.edu!ucselx!bionet!agate!ucbvax!CS.UCLA.EDU!wales From: wales@CS.UCLA.EDU (Rich Wales) Newsgroups: comp.protocols.time.ntp Subject: NTP and the infamous SPARC clock problem (again) Message-ID: <901130.051735z.03507.wales@valeria.cs.ucla.edu> Date: 30 Nov 90 05:17:35 GMT References: <901026.213137z.27072.wales@valeria.cs.ucla.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: The Internet Lines: 46 About a month ago, I reported that we (UCLA CS Department) had been having a very nasty time trying to keep our SPARCstations (SPARC-1's and SPARC-SLC's, running SunOS 4.0.3) time-synched via NTP. I've done the following things already: (1) Everyone is running "in.ntpd", May '89 version, patch level 13. (2) "_dosynctodr" has been set to zero in all kernels. (3) "_tick" has been changed from 10,000 to 9,998 in all kernels (one person on the NTP list suggested this, and it seems to have helped). But the problem still recurs. Especially on the SLC's -- but sometimes on the SPARC-1's too -- a clock may lose over an hour before someone finally sees the problem, reports it to our "help" mailing list (system support staff), and the clock gets reset by hand. Our users usually notice the problem because the NTP daemon starts complaining incessantly about how the clock is too far off for NTP to deal with it. Our five Sun-4/380's do not suffer from this problem at all, by the way. I'm aware of the existence of a clock problem in the SPARCs, but I had been hoping that NTP might be able to keep it under control. Even if we could keep our SPARCs to within a second or so of real time, I'd be willing to lower my standards :-} and accept such a situation. I'm also concerned that the clock problems in our SPARCs is creating a general impression around our department that NTP is flaky and unproven (and that perhaps we should be running something supposedly more "stan- dard" like "rdate" or "timed" instead; no smileys here, sad to say). When I reported this problem about a month ago, one user said he had a set of kernel patches that would fix the problem. But he never deliv- ered, and he eventually confessed that he had misplaced the patches and could offer no hope of ever being able to get them to me. I'm willing to switch to "xntpd", but only if someone can provide me with positive assurances that this other NTP implementation will fix the problem. Thanks very much for any concrete assistance anyone can provide us. Rich Wales // UCLA Computer Science Department 3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (213) 825-5683 "This is yet another example of how our actions have random results."