Date: Thu, 20 Aug 1998 01:12:47 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: green@unixhelp.org (Brian Feldman) Cc: bde@zeta.org.au, freebsd-current@FreeBSD.ORG, jwd@unx.sas.com Subject: Re: 13 months of user time? Message-ID: <199808200112.SAA01826@usr05.primenet.com> In-Reply-To: <Pine.BSF.4.02.9808191720490.29282-100000@zone.syracuse.net> from "Brian Feldman" at Aug 19, 98 05:22:50 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808200112.SAA01826>