From owner-freebsd-hackers Sat Jun 21 04:20:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA25547 for hackers-outgoing; Sat, 21 Jun 1997 04:20:51 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA25542 for ; Sat, 21 Jun 1997 04:20:47 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id VAA26616; Sat, 21 Jun 1997 21:16:38 +1000 Date: Sat, 21 Jun 1997 21:16:38 +1000 From: Bruce Evans Message-Id: <199706211116.VAA26616@godzilla.zeta.org.au> To: FreeBSD-Hackers@FreeBSD.ORG, kjc@csl.sony.co.jp Subject: Re: High Resolution Timers, How? Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Solaris implements gethrtime(get high resolution time) that returns >a 64-bit value in nanoseconds since some arbitrary time. > >Its features are: > - simpler and faster > - higher resolution > - no sec/usec conversion required > - no clock adjustment (no time warp) > >hrtime seems to be an attractive alternative since microtime() is used >mostly to measure time delta, and easily implemented by extracting >part of microtime(). > >How about implementing gethrtime in FreeBSD? I'm not sure that microtime() really is used mostly to measure time deltas. I'm fairly sure that calculation of deltas is not more common than reading the time, so it wouldn't be a good tradeoff to do extra work when reading times to give binary format. A naive implementation would have to do something like mono_time.tv_sec * 1000000000LL + mono_time.tv_usec * 1000 extra, and the multiplication by 10^9 would be wasted when two times with the same tv_sec value are subtracted. A better implementation would keep a separate copy of `mono_time' in binary format. A better interface would use machine-dependent units to avoid premature scaling. Bruce