home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / question / 13321 < prev    next >
Encoding:
Text File  |  1992-11-12  |  1.3 KB  |  26 lines
  1. Newsgroups: comp.unix.questions
  2. Path: sparky!uunet!ukma!darwin.sura.net!convex!constellation!osuunx.ucc.okstate.edu!datacomm.ucc.okstate.edu!martin
  3. From: martin@datacomm.ucc.okstate.edu (Martin McCormick)
  4. Subject: adjtime
  5. Message-ID: <1992Nov12.210618.4538@osuunx.ucc.okstate.edu>
  6. Sender: news@osuunx.ucc.okstate.edu (USENET News System)
  7. Nntp-Posting-Host: datacomm.ucc.okstate.edu
  8. Organization: Oklahoma State University, Stillwater, OK
  9. Date: Thu, 12 Nov 1992 21:06:18 GMT
  10. Lines: 14
  11.  
  12.  
  13. I have determined that our Sun sparc's real-time clock gains about a minute
  14. every three months.  Is the adjtime call appropriate to use to slow down
  15. the system clock to compensate for this error?  When reading the manual
  16. entry on it, I was a little confused as to whether this was meant for only
  17. synchronizing other system's clocks to a master time server or if it did that
  18. in addition to introducing a correction factor to the host system clock.
  19. I would like to hear from anybody who has actually used it.
  20.     There are various hardware solutions to synchronizing clocks, but
  21. I feel that our system would be pretty accurate, for our needs, if a correction
  22. factor could constantly be in effect to nudge the system in to counting time
  23. a little more slowly.  Any help such as whether or not this does what I think
  24. it does, or examples of what the C code to call it looks like would be
  25. appreciated.
  26.