Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@dwarfs.crhc.uiuc.edu (Andy Glew) Newsgroups: comp.arch Subject: Re: 64 bits for times.... Message-ID: Date: 30 Aug 90 17:45:37 GMT References: <11187@alice.UUCP> <3300165@m.cs.uiuc.edu> <2470@crdos1.crd.ge.COM> <1783@tuvie> Sender: usenet@ux1.cso.uiuc.edu (News) Organization: University of Illinois, Computer Systems Group Lines: 22 In-Reply-To: alex@vmars.tuwien.ac.at's message of 30 Aug 90 14:11:16 GMT >For clocks there is a solution to the problem: >Adjust the *rate* of the clock until the correct value is reached >and maintain the correct value by corrections of the rate. >Unfortunately 1003.4 does not specify an interface for this >(ok, this does not really belong in comp.arch ...). Which is exactly the sort of thing I was complaining about. Adjust the rate for your absolute time clock that you never measure intervals on. The clock that you basically only use for timestamping files. But leave your hands off the clock that I'm using to time loops, program execution, ie. where I am differencing timer values to gain an interval time. Or at least log all of your rate adjustment times, so that I can know that a difference of 10 ticks NOW is 10.2 us, while a difference of 10 ticks yesterday at 9pm is 9.8 us. Doing those adjustments is a pain, but its doable. -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]