Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!sdd.hp.com!decwrl!shelby!portia.stanford.edu!kevinw From: kevinw@portia.Stanford.EDU (Kevin Rudd) Newsgroups: comp.arch Subject: Computer time measurements (Was Re: 64 bits for times....) Message-ID: <1990Aug22.044826.18572@portia.Stanford.EDU> Date: 22 Aug 90 04:48:26 GMT References: <26012@bellcore.bellcore.com> <11187@alice.UUCP> Sender: Kevin W. Rudd Organization: Electrical Engineering Department, Stanford University Lines: 30 In article aglew@dwarfs.crhc.uiuc.edu (Andy Glew) writes: > Very few machines have a cycle time that is really commensurate in >the integrals with exact units like nanoseconds... > Very few machines have a cycle time that is really perfectly >regular... >But, for the people who really need high resolution timers, provide a >"RAW" timer that ticks in whatever is the most convenient tick rate >for your machine. Try to make the ticks as regular as possible. Don't >play any tricks like warping the tick rate or dropping ticks. >Characterize the ticks as well as you can... ----------------------------------------- It seems to me that this is the crux: It is difficult to implement a system which has a stable timer (to an appropriate accuracy) as well as a reliable means of acquiring the time when required. In a computer system there are many sources of timing "noise" including processor stalls, bus conflicts, interrupts, and (not to leave out) the phase of the moon and all of these make it difficult to precisely start and stop some timing increment. If it is desired to make incredibly precise measurements it seems that precision measurement equipment would be used, probably clocked off of a high performance logic analyzer to determine the appropriate states to mark the timing boundaries. I am unclear as to the self measuring precision required of a computer system. For example, I don't see the relevence of marking file time stamps to the 1ns increment... --Kevin [If ignorance is bliss then we must all be very happy...]