Date: Sat, 22 Oct 2005 18:51:44 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Andre Oppermann <andre@freebsd.org>, src-committers@freebsd.org, Andre Oppermann <oppermann@networx.ch>, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: Timekeeping [Was: Re: cvs commit: src/usr.bin/vmstat vmstat.c src/usr.bin/w w.c] Message-ID: <20051022175218.F8139@delplex.bde.org> In-Reply-To: <31104.1129915194@critter.freebsd.dk> References: <31104.1129915194@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Oct 2005, Poul-Henning Kamp wrote: > In message <435921F1.5E9050AD@networx.ch>, Andre Oppermann writes: >>>> IMO it's this: >>>> >>>> Uptime is the time the operating was available to present it's common >>>> services to userland. That excludes any suspend and ddb times. Single >>>> user mode however counts because the OS was servicing userland even if >>>> there was only one user. Uptime is represented in SI seconds. >>> >>> I can live with this definition. This is a good measure from the point of view of the users of the services. It is not quite right for statistics utilities like vmstat. But systat uses different units that end up being almost equivalent to monotonic time. It doesn't use any of boottime, time(3), gettimeofday(2) or clock_gettime(2); it uses on tick counts. Since the tick counts don't increase during suspend and ddb activity, the act in the same way as CLOCK_MONOTONIC except they are less accurate and are not slewed except for the physical slew from drift in the hardware clock that generates the clock interrupts. >>> So now we just need to be able to reliably measure the "not-uptime". >> >> Umm... Whenever the onesec tick is not incrementing the uptime (and >> monotonic) counter. Which conviniently already is the case when OS is >> suspended or in DDB. > > Uhm, yes. Only... > > How do we measure the time our clock does _not_ tick ? > > We need to use another clock for that. > > The RTC comes to mind, but it's precision leaves a lot to be > desired. It is more than enough except for short term "suspensions" (e.g., ones involving non-interactive single-stepping in ddb), and timecounters normally keep working across short term "suspensions". It's more of a problem that the system might not know when it is suspended or resumed, so it couldn't take the timestamps needed to decide when it wasn't running. As a worst case, suspend/resume might be per-cycle. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051022175218.F8139>