$gettim high resolution time option

[Jim Hintze]

anyone know the majic parameter to $gettim to return the hi res timestamp??


NEW FUNCTIONALITY AND/OR PROBLEMS ADDRESSED IN THE
VMS831H1I_SYS-V0800 KIT

5.1 New functionality addressed in this kit

5.1.1 $GETTIM System Service Flag Parameter

5.1.1.1 Functionality Description:

This change adds an option flag parameter to the $GETTIM
system service which will cause the service to return the
number of 100ns intervals since boot with a resolution
equivalent to the system time. This change can be used
in place of the C routine times() to get a higher
resolution time stamp.

This kit is required for systems running Oracle RAC.

Images Affected:

- [SYS$LDR]SYSTEM_PRIMITIVES.EXE

- [SYS$LDR]SYSTEM_PRIMITIVES.STB

- [SYS$LDR]SYSTEM_PRIMITIVES_MIN.EXE

- [SYS$LDR]SYSTEM_PRIMITIVES_MIN.STB

- [SYS$LDR]MESSAGE_ROUTINES.EXE

- [SYS$LDR]MESSAGE_ROUTINES.STB


thanks
Jim

[Hoff]

I've logged a problem report.

There's apparently more here than just this, based on a little digging, too.

And times()? Not clock_getres() and clock_gettime()?

If I hear back (and you've not already gotten an answer), I'll post a reply here.

[Hoff]

PTR 75-123-39

[Jim Hintze]

And here is a new entry point for 8.4 that may be the same.....

o Functional description:

Adding infrastructure support for new system service $GETTIM_PREC.

The Get Time Precision service returns the current system time in

64-bit format. The quadword is the number of 100 nanoseconds since

November 17, 1858.The default frequency at which system time is

updated on VMS is approximately 1 millisecond. SYS$GETTIM_PREC

returns the system time after accounting for the time elapsed since

the last one millisecond update of the system time on Itanium.

On Alpha this service is equivalent to $GETTIM service and just returns

the last updated system time. The successful completion status of the

service on ALPHA is SS$_LOWPREC.

So it appears this would provide 1 ms timer resolution on Alpha and something better on Itanium.

[Sandeep Ramavana]

Hi Jim,

If you pass the optional parameter to $GETTIM as 1, it would return the number of 100ns since "boot". Oracle RAC uses this optional parameter to get the time since boot.

$GETTIM with optional parameter as 0 (or if it is not specified) would return the system time in 100ns. However, this system time is updated every 1 ms. Hence the precision of the system time returned is 1 millisecond.

$GETTIM_PREC, however, returns the number of 100ns that have elapsed since November 17, 1858. In other words, this returns the system time with a much higher precision of 100ns.

Best Regards,
Sandeep

[Hoff]

The "new" $gettim call looks like this, then?

stat = sys$gettim( pointer [,optflag] )

Is the flag argument by value or by address?

That's not documented in the manuals and the help; I've logged a PTR against that.

Out of curiosity, why are there two system service calls here, and not a flag that causes $gettim to return higher precision? (Also whether just returning higher precision values would construe a problem? Going lower might be, but higher seems less likely to break stuff. But the flag can control that.)

[Jon Pinkley]

I wrote a FORTRAN program just to see how $gettim worked.

It returns unexpected results.

What is unexpected:

1. The return represents a delta time (time since boot) but is returned as a positive value. So it you pass it to $asctim, it will return a date with an offset from 17-Nov-1858. Negating it prior to passing to $ASCTIM makes it display as a delta time.

2. The value returned does not correspond to the uptime value that $ show system /noprocess shows. (I think that is based on EXE$GL_ABSTIM_TICS, but I didn't check the source)

3. The value returned does not correspond to the f$delta(f$getsyi("BOOTTIME"),f$time())

So it isn't clear what the source of the time returned is. Perhaps a system cycle counter, or some interval counter on the itanium.

Here are the results on an ES47 that has an uptime of just over two weeks. See attachment for the FORTRAN code and command file (and I know it is poorly written code with not error checking...)


$ @uptime
OpenVMS V8.3 on node OMEGA 14-DEC-2009 07:51:11.51 Uptime 15 07:10:31
The time is 14-DEC-2009 07:51:11.52
$GETTIM with optional parameter value 1 returns 00000C05DF7904A0
Converting to delta time format (negating) and formatting with $ASCTIM 15 07:12:16.36
DELTA = " 15 07:12:06.53"
OpenVMS V8.3 on node OMEGA 14-DEC-2009 07:51:11.53 Uptime 15 07:10:31

I am just curious why the discrepancy. I know that EXE$GL_ABSTIM_TICS can disagree with computing the delta between current and boottime, and can be quite far out of synch if time has been changed with $ SET TIME, but I was surprised that two of the above three "uptime" values did not agree more closely with each other.

Perhaps it something to do with the alpha accuracy bonus not being applied in the time base that this values is derived from.

Jon

[John Gillings]

Jon,

Calculating uptime can be tricky, especially in a cluster. You're using the original boot time stamp with no compensation for clock adjustments, and the current time on the current node (which may be different from the node you're calculating for). I think this was reported a while back as a possible bug in SHOW SYSTEM (here in ITRC?). You may be seeing the results of attempting to "fix" the issue in one path than hasn't been implemented the same in another path (if only we could scrap the time mechanisms in OpenVMS and start from scratch!).

Note that Sandeep specified the result as "return the number of 100ns since "boot".", so a positive value would be correct, even though it's contrary to standard OpenVMS usage for delta times. From the description it sounds like this was an enhancement for a specific customer, so it would have been to their specifications.