Timekeeping [Was: Re: cvs commit: src/usr.bin/vmstat vmstat.c src/usr.bin/w w.c]

[Bruce Evans]

On Fri, 21 Oct 2005, Poul-Henning Kamp wrote:

> In message <435921F1.5E9050AD at 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