From owner-freebsd-current Wed Aug 19 18:13:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA16180 for freebsd-current-outgoing; Wed, 19 Aug 1998 18:13:53 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA16170 for ; Wed, 19 Aug 1998 18:13:48 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id SAA01057; Wed, 19 Aug 1998 18:13:07 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd001026; Wed Aug 19 18:13:01 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id SAA01826; Wed, 19 Aug 1998 18:12:48 -0700 (MST) From: Terry Lambert Message-Id: <199808200112.SAA01826@usr05.primenet.com> Subject: Re: 13 months of user time? To: green@unixhelp.org (Brian Feldman) Date: Thu, 20 Aug 1998 01:12:47 +0000 (GMT) Cc: bde@zeta.org.au, freebsd-current@FreeBSD.ORG, jwd@unx.sas.com In-Reply-To: from "Brian Feldman" at Aug 19, 98 05:22:50 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It's probably a good idea to get this fixed ASAP, since people have been > complaining about this exact bug for months now. Would anyone like to give > me any pointers to where to start evaluating the code at, or what > functions this could be caused by? I think I'll check the process > accounting code first then the actual timing code, if noone has any better > ideas. My suggestion would be to implement this timing using a monoclock. A monoclock monotonically increases; that is, it *never* goes backward. A monoclock *can* have it's ticks accelerated (or delayed) to sync it to a timebase, but this is not really necessary. If the system clock never went backwards (ie: adjtime(2) did not cause the system clock to be modified, but instead scheduled a delay or an acceleration), then you could never have negative wall values, and you would never have this bug. The merits of using gettimeofday(2)/settimeofday(2) to modify the system clock rather than a derived wall clock based on a monoclock are debateable; the calculation is not that high an overhead. It is an error for the struct timeval member, the long value "tv_sec", to be equated with time_t. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message