cm36+@andrew.cmu.edu (C. V. R. Murthy) (05/11/88)
Hello, I am trying to translate a piece of code written under 4.2 BSD to System V environment to System Release 3.0 . The first problem I faced is the gettimeofday () system call. Although Wollongongs WIN Rel 1.0 (that we have) refers to gettimeofday (2), there is no such call on at least System V Rel 3.0 . Essentialy , this requires a microsecond accurate time (namely BSD's struct timeval). I want to know how one could get time accurate to microseconds . Any suggestions will be apprecicated, Thanks, Murthy.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/11/88)
In article <14203@brl-adm.ARPA> cm36+@andrew.cmu.edu (C. V. R. Murthy) writes: >gettimeofday () system call. Although Wollongongs WIN Rel 1.0 (that we have) >refers to gettimeofday (2), there is no such call on at least System V Rel 3.0. gettimeofday() is Berkeley-specific although Wollongong MIGHT have provided one in their package. >Essentialy , this requires a microsecond accurate time (namely BSD's struct >timeval). I want to know how one could get time accurate to microseconds . You can't get time like that from a normal UNIX system, even a Berkeley one. Apart from the uncertainties introduced by time-sharing scheduling, most implementations don't even maintain internal time that accurately. 100Hz clock is typical. Use time() instead.
egisin@watmath.waterloo.edu (Eric Gisin) (05/13/88)
In article <7871@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > You can't get time like that from a normal UNIX system, even a Berkeley > one. Apart from the uncertainties introduced by time-sharing scheduling, > most implementations don't even maintain internal time that accurately. > 100Hz clock is typical. Use time() instead. On Vaxen running BSD gettimeofday reads a hardware clock register with microsecond accuracy. Look at the timings from ping(8), they have better resolution that the 100Hz software clock. On System V, the best resolution you can get is the long (clock_t) value returned by times(2). The resolution is on the order of 10 milliseconds.
chris@mimsy.UUCP (Chris Torek) (05/14/88)
In article <18806@watmath.waterloo.edu> egisin@watmath.waterloo.edu (Eric Gisin) writes: >On Vaxen running BSD gettimeofday reads a hardware clock register >with microsecond accuracy. Only in 4.3BSD and later (4.2BSD just gave back 10 ms. increments), and only where the hardware supports it. The routine `microtime' in /sys/machine/machdep.c is responsible for determining a more accurate time. On most Vaxen this is indeed done this way, but the MicroVax II does not have the register. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/14/88)
In article <18806@watmath.waterloo.edu> egisin@watmath.waterloo.edu (Eric Gisin) writes: >In article <7871@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >> You can't get time like that from a normal UNIX system, even a Berkeley >> one. Apart from the uncertainties introduced by time-sharing scheduling, >> most implementations don't even maintain internal time that accurately. >> 100Hz clock is typical. Use time() instead. >On Vaxen running BSD gettimeofday reads a hardware clock register >with microsecond accuracy. >On System V, the best resolution you can get is the long (clock_t) >value returned by times(2). The resolution is on the order of 10 milliseconds. The resolution is limited by the available hardware clock (which may be no better than power line frequency), and may be less than that if the kernel implementor so chose; there is normally a round-robin scheduler increment that serves as the effective resolution of time throughout the OS, except for special access to finer-grained timers such as provided by Berkeley getitimer() etc. The higher theoretical resolution of such a timer on systems with fast hardware clocks is not available in practice, because of the basic (coarser) increment used to schedule the return from the system call. Ordinary UNIX is not well suited to precise timing applications. (Some vendors who target the real-time market have attempted to improve this for their products.)
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/17/88)
In article <7887@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: | The resolution is limited by the available hardware clock (which | may be no better than power line frequency), and may be less than | that if the kernel implementor so chose; there is normally a Of course on a Cray2 that's 4.1ns/tick, reasonably close. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/17/88)
In article <10860@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > Of course on a Cray2 that's 4.1ns/tick, reasonably close. As I said, it depends on the hardware. Note that the Cray-2 has a 64-bit word or else this resolution would get you into real trouble.