Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!hplabs!hao!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: Csh confusion: #define HZ 100? Message-ID: <289@rlgvax.UUCP> Date: Sat, 8-Dec-84 02:37:43 EST Article-I.D.: rlgvax.289 Posted: Sat Dec 8 02:37:43 1984 Date-Received: Mon, 10-Dec-84 02:15:37 EST References: <124@osu-eddi.UUCP> <-1180729@sneaky.UUCP> <286@rlgvax.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 22 > Except that in 4.2, quantities of CPU time are available from the "old" > system calls ("times", etc.) in ticks of 60ths of a second (not in any > units based on the system clock - always 60ths of a second) and are available > from the "new" system calls in *very* nominal units of microseconds. As > such, under 4.2 no user-mode program need know the system clock frequency > in order to interpret values from system calls... Well, actually, there is one mechanism that does supply time in system clock ticks - the "profil" facility. Somebody just posted a bug report that "profil" works in clock ticks, which are now 1/100 seconds on the VAX, but the "prof" command still thinks profiling works in 1/60 second units. How many systems out there have clocks run off the line frequency rather than off, say, a crystal? Systems running off the line frequency would either have to 1) always supply this time in some nominal units which need not be the unit of the system clock, 2) provide a facility by which a program can ask the OS what the system clock units are, or 3) supply different versions of a lot of the user-mode software in countries with different line frequencies. Systems with programmable clocks wouldn't have this problem. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy