Date: Mon, 17 Aug 1998 18:25:02 +0000 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: joerg@krdl.org.sg (Joerg Micheel), ac199@hwcn.org, grog@lemis.com, mph@pobox.com, brawley@camtech.com.au, hackers@FreeBSD.ORG Subject: Re: 64-bit time_t Message-ID: <199808171825.SAA00292@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 17 Aug 1998 06:02:42 GMT." <199808170602.XAA20899@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > What bothers much more is resolution. Many things of interest now happen > > in fractions of milliseconds. Look at the clock frequency of computers > > or the clock of networks (SONET, etc). Nanosecond granularity is a must, > > if you'd like to accurately describe an interval it takes to compute or > > transmit a certain piece of information. Please note that granularity > > does not mean accuracy (it has never been). > > Right. For example, all resoloution better than a second is arrived > at through interpolation, and has been for a long time. SunOS 4 > interpolated to a resoloution of 4uS (based on the time it took to > make a system call vs. the speed of the hardware at the time). Not correct on systems Pentium and above, where the cycle counter is used. It's been a while since I looked at the code, but basically the cycle count is stored each tick and the number of cycles per tick is known, so a rapid calculation can be performed to obtain the offset from the last tick (whose time is known) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808171825.SAA00292>