From owner-freebsd-hackers Fri Feb 23 13:31:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA12715 for hackers-outgoing; Fri, 23 Feb 1996 13:31:40 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA12700 for ; Fri, 23 Feb 1996 13:31:20 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA31212; Sat, 24 Feb 1996 08:29:39 +1100 Date: Sat, 24 Feb 1996 08:29:39 +1100 From: Bruce Evans Message-Id: <199602232129.IAA31212@godzilla.zeta.org.au> To: Mattias.Gronlund@sa.erisoft.se, bde@zeta.org.au Subject: Re: iostat Cc: FreeBSD-hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >> Just fix microtime(). >Hmm, I guess that I wasn't all clear what I wanted. The thing that >I want is a timer that never ever can return a time before the >time that it got last time it was called in one session (from the >last time booted). One other thing that I whould like with it is >that it should be fast to calculate timedeltas with, that would >make it very good for all types ofprofiling in the kernel and >it should could give a value for the time since boot needed to >calculate some statistics. This can be implemented as: struct timeval tv; microtime(&tv); timevalsub(&tv, &boottime); It can't be done portably much faster than this unless you optimize for profiling at the expense of normal operations that want the current time. >> I have seen the clock go backwards a couple of times recently: >... >> I've never seen this on i486 systems. >This does not look good, I have tried to understand the code in >microtime.s but I have never been into x86 assembler so I didn't >realy understand what the code at the pentium_microtime did but >it seems on your description like that is where the "bug" is. It's very simple :-). See isa/prof_machdep.c for a slightly faster non-Pentium version written in C. This depends on being called often and is only good for profiling. >> No time daemons or users running `date' or adjtime() were active. >But there is some system where `date' and/or adjtime is active :-). adjtime() isn't a problem - it only makes tiny adjustments and never sets the clock backwards I just got another negative time: -6625 usec. I'll add some checks in microtime() and in . Bruce