home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / time / ntp / 1027 < prev    next >
Encoding:
Text File  |  1992-11-12  |  2.0 KB  |  46 lines
  1. Newsgroups: comp.protocols.time.ntp
  2. Path: sparky!uunet!spool.mu.edu!yale.edu!ira.uka.de!fauern!fauna!faui45d!kardel
  3. From: kardel@faui45d.informatik.uni-erlangen.de (Frank Kardel)
  4. Subject: Re: xntp3, DOSYNCTODR_SUCKS
  5. References: <1992Nov9.214008.2068@elroy.jpl.nasa.gov>
  6. Message-ID: <BxLoJC.Ky1@immd4.informatik.uni-erlangen.de>
  7. Sender: news@immd4.informatik.uni-erlangen.de
  8. Organization: CSD., University of Erlangen
  9. Date: Thu, 12 Nov 1992 11:13:59 GMT
  10. Lines: 34
  11.  
  12. stevo@elroy.Jpl.Nasa.Gov (Steve Groom) writes:
  13.  
  14. >...  In particular, when the machine comes back up
  15. >after being powered off, the clock seemed to be set to a reasonable value,
  16. >or at least I didn't notice that it was far enough off to be a problem.
  17. >In xntp3, this DOSYNCTODR_SUCKS thing has a comment that seems
  18. >to indicate that if I don't define this, the hardware clock doesn't get
  19. >updated by xntpd.
  20. True when you also use tickadj to disable SW clock setting from the HW clock.
  21.  
  22. >Is this something new in v3?
  23. Yes.
  24.  
  25. >Also, there is a comment
  26. >that says that I probably only need this if I'm not on a network.  It seems
  27. >to me that if this is indeed a problem, the machine could wake up
  28. >with the clock far enough out of whack that xntpd would give up, making
  29. >this an issue for "networked" machines as well.
  30.  
  31. As long as you stay with the HW clock within 1000 seconds of the time everything
  32. is fine. And each time xntp has to set the SW clock because it is of by 
  33. more than 128ms the HW clock will also be set and thus stay "close" to what
  34. it should be. When you are away for a long time from the net or you are synched
  35. very nicely via xntp your HW clock may drift quite a bit. Therefore a periodic
  36. settimeofday(gettimofday) is done when you define DOSYNCTODR_SUCKS. This is fine
  37. for machines synchronized not better then 5ms.
  38. DOSYNCTODR_SUCKS pertains mostly to Suns.
  39.  
  40. WARNING:
  41. DOSYNCTODR_SUCKS introduces a glitch of ~ 800us ervery hour on Suns (SS2) and is
  42. thus NOT USABLE for high precision hosts.
  43.  
  44. --
  45.   Frank Kardel (time@informatik.uni-erlangen.de)
  46.