how to get uptime

[Claus Olesen]

This C code (linked with /sysexe=selective)

#pragma extern_model save
#pragma extern_model globalvalue
int extern *EXE$GL_ABSTIM_TICS;
#pragma extern_model restore
return( (*EXE$GL_ABSTIM_TICS) );

returns raw tics since boot i.e. uptime. It has the advantage that the tics are not affected by "$set time" changes as there are with fx $gettim but the disadvantage that they wrap around relatively often. It works also on IA64.

I looked to see if there might be another (new) way to get the uptime or for that matter any type of ticker that is not effected by "$set time".
$getrmi has item codes for returning tics but not for uptime.

Is there another (and less intricate) way to get the uptime (with good resolution) on IA64?

Where does "$show system" get the "Uptime" from? Where does "$mon modes" get it from for the percentage calculations of time spent in the various cpu modes?

we use it in simple polling cycles as in
if (next_time < curr_time)
{
do something...

on systems where ntp is running or where "$set time" is used to eliminate drift.

[John Gillings]

Claus,

SHOW SYSTEM calculates uptime as the current time minus EXE$GQ_BOOTTIME (or more cleanly as $GETSYI item SYI$_BOOTTIME). As you've noted this is affected by time changes. It can even be affected by cluster clock drift, since the calculation is done using the clock of the node on which it's displayed.

Note that depending on your requirements, using BOOTTIME may give a more accurate long term result than counting tics, since tics aren't guaranteed to be precisely the same time period. That depends on your definition of "accurate" - are you thinking subjective time according to the system clock, or more objective time, using an idealised global clock?
On a system with good time syncronization the SHOW SYS time will give a long term accurate value for the real elapsed up time (but possibly with a 1 hour error due to time changes). Tics will give you a more accurate short term indication of consumption, but for practical purposes only for periods up to twice the cycle time.

It looks like your requirement cares more about short term, in which case you need to manage rollover yourself. Maybe use something that combines EXE$GL_ABSTIM and EXE$GL_ABSTIM_TICS?

[Hein van den Heuvel]

Everytime I see this topic in the directory, I have to snicker a little bit.

(Claus, I'm hoping it was intentional! :-)

Many a spam filter would not let this one pass by.


Good question. A little more detail would be welcome.

Good reply by John... as always.

Cheers,
Hein.

[Hoff]

The system boot time is available via the error log, and there's a SYSINIT record written into the accounting data, and (probably the least intricate of all) there's the the approach of writing out the necessary data during your own startup procedures.

I'd probably pick GMT or UTC whenever that choice is available and feasible, and to stay as far away from daylight and local time as I can manage), and processing it later as required.

As for $getsyi itemcode values, there's the aforementioned boot time, and depending on how the application(s) are coded, the cluster foundation time.

As for the polling or whatever the "do something" task(s) might be, I'd probably tend to use recurring TQEs, a self-requeuing timer AST (beware drift, should you use "now plus interval" to calculate the next AST), $schdwk, or other scheduled processing, rather than looping. (And if you're just busy-looping for some periodic task, why is the boot time of interest.)