Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.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: 22 Aug 90 03:03:04 GMT References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA> <30728@super.ORG> <26012@bellcore.bellcore.com> <11187@alice.UUCP> Sender: usenet@ux1.cso.uiuc.edu (News) Organization: University of Illinois, Computer Systems Group Lines: 90 In-Reply-To: andrew@alice.UUCP's message of 15 Aug 90 05:13:03 GMT ..> Time formats While my benchmarks chug away, mind if I have my say about time? Time formats are (1) something that I have strong opinions about, and (2) something that I believe I know quite a bit about, since I have spent most of my career making exact time measurements on computers in one form or another, wrestling with the various time formats. A 64 bit, 1 bit per nanosecond (or 128 bit, 1 bit per picosecond??), time format is great FOR PORTABLE USES OF TIME. Like timestamping files, maybe even a little bit of low accuracy performance measurement. Such a fixed format, though is EVIL and MISLEADING for high accuracy time measurement. Here are some reasons: Very few machines have a cycle time that is really commensurate in the integrals with exact units like nanoseconds. Typically, such machines have cycle times that are, say, 1.0012 ns long. Now, very few hardware designers are going to put a divider in to account for this small deviation - instead, they'll just use a counter, and assume that the deviation is negligible, or can be handled some other way. In other words, a hardware designer who says that he is giving you an exactly ns clock is probably *lying*. The best he can do is give you a clock accurate to several ppm (or parts in 10^13 - you just move the point around). There is a science/engineering discipline, called metrology (or horology) that specializes in how to make really accurate measurements. Most real designers are not (and do not need to be) trained metrologists. Who cares about parts in 1E13? The guy who is trying to make really accurate measurements. I have been able to make measurements where I have been able to see the effect of a single cache miss in a long section of code - after I have gone through the processes of converting "Nanoseconds according to the processor" into "the closest thing I can get to real nanoseconds". Occasionally one reads papers where it is obvious that the researchers did not go through this process, ie., where they assumed that the hardware reported nanoseconds were real nanoseconds. It would be better if we were just honest and admitted that machines don't run in nanoseconds - rather, they run in whatever is the fastest convenient time for the part. Even if vendor A says "I can build a nanosecond clock more regular than any constraint you put on it", vendor B may not be able to, due to differences in technology or format. Very few machines have a cycle time that is really perfectly regular. Ie. that supposedly nanosecond clock might be 0.999999867 now, and 1.0000001234 sometime later, according to changes in temperature, humidity, the local EM environment, whatever. I have observed such effects on several real systems, both CMOS and NMOS. Such effects are well known, which is why most timer hardware has a "timer correction" facility. Eg. when you compare your clock to another clock, and find that you are 0.00000001256 out of synch, you tell your clock to shorten its cycle by 0.00000000001 every tick - ie. to tick faster. So, in addition to the physical/environmental variations in timer cycle, you have a designed in time warp. You can't make measurements of a higher resolution than this, without standing on your head. To use a software example that is probably more familiar to the readers of this group: the BSD "adjtime()" facility warps the meaning of time, so that naonseconds are not consrant. Instead of warping the clock rate, which is difficult to do, some timers drop a tick every N ticks or so. So, therefore, your timer is not accurate to its least significant bit - a delta of 2LSBs might mean a 1ns difference instead of 2ns, if you were unlucky. Provide your "high resolution" 1 ns per bit timer if you must. 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. Provide a software library to convert from this RAW timer format to the portable timer format. Ensure that the software library does not just linearly scale ticks to real time, but instead can inter/extrapolate on a curve fitted between RAW timer values and certain calibration points in real time. Ironically enough, less hardware is required for this RAW timer than for a canonical bit per ns timer - and what hardware there is should all be devoted towards making the timer as accurate and regular as possible, rather than scaling into some "portable" format. Let software do the mapping. -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]