Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!sgi.com!scotth From: scotth@corp.sgi.com (Scott Henry) Newsgroups: comp.protocols.time.ntp Subject: Re: What means "drift" and "compliance" ? Message-ID: Date: 19 Feb 91 16:09:25 GMT References: <9102141633.AA20519@sayshell.umd.edu> <1991Feb19.195717.12530@ni.umd.edu> Sender: news@odin.corp.sgi.com (Net News) Reply-To: scotth@sgi.com (Scott Henry) Distribution: inet Organization: Silicon Graphics Inc, Mountain View, CA Lines: 41 In-Reply-To: louie@sayshell.umd.edu's message of 19 Feb 91 19:57:17 GMT >>Is 4096 the exact conversion, or is the complicated table-lookup scheme >>exact and 4096 an approximation? l> Yes, 4096 is the exact "conversion" to normal, everyday units. There l> is no "complicated table-lookup scheme". >>If 4096 is the exact conversion, why the >>lookup table scheme in the first place? The lookup scheme is not >>especially linear for large values of drift, and I suspect that it may be >>the cause of machines with large drift values being unable to sync. l> I don't know what you're refering to when you cite a "lookup table l> scheme". There is no lookup table that has anything to do with the l> drift value. The drift value is used in the local clock algorithm to l> represent the intrinisic drift of your host's clock, and to apply a l> correction to it to keep its effective frequency correct. NTP (and l> ntpd) allows you to correct the phase of the clock as well as the l> frequency. Sorry, I thought this was reference to xntpd, where there IS something that I would call a "lookup table scheme" for conversion between drift and timestamp values. I am specifically referring to the macros TVUTOTSF and TSFTOTVU in include/ntp_unixclock.h which use lookups into the tables defined in lib/tvtots.c, lib/tstotv.c, etc. My emperical experimentation, the tables come out with a value averaging near 4130. If I'm looking in the wrong part of the code, I'd welcome pointers. l> Machines with large drift values either have broken hardware (i.e. l> crummy crystals) or crummy software (i.e. missing clock interrupts). l> The large drift value is just a symptom of the problem. I'm stuck with having to allow for crummy crystals. Missing clock interrupts doesn't seem to be a problem with a good crystal, so it should be allowable with a crummy one... -- Scott Henry / Traveller on Dragon Wings Information Services, / Help! My disclaimer is missing! Silicon Graphics, Inc / Politicians no baka!