- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: $gettim high resolution time option
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-11-2009 10:03 AM
тАО12-11-2009 10:03 AM
$gettim high resolution time option
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-11-2009 11:04 AM
тАО12-11-2009 11:04 AM
Re: $gettim high resolution time option
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-11-2009 11:31 AM
тАО12-11-2009 11:31 AM
Re: $gettim high resolution time option
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-11-2009 01:06 PM
тАО12-11-2009 01:06 PM
Re: $gettim high resolution time option
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-11-2009 09:45 PM
тАО12-11-2009 09:45 PM
Re: $gettim high resolution time option
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-12-2009 08:17 AM
тАО12-12-2009 08:17 AM
Re: $gettim high resolution time option
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-14-2009 08:13 AM
тАО12-14-2009 08:13 AM
Re: $gettim high resolution time option
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-14-2009 01:43 PM
тАО12-14-2009 01:43 PM
Re: $gettim high resolution time option
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.