|
HP OpenVMS Systemsask the wizard |
|
The Question is: A 64 Bit clock (100nSec)can be assessed using the sys$gettime function call. However it seems to only update at a 1msec rate even thoght we have a 1GHz CPU. Is there any way to changed the update rate so it updates closer to the 100sSec rate? We are tr ying to make some high resolution timing measurement. The Answer is :
The Alpha rscc and rpcc mechanisms will likely be of interest.
Related topics include (2734), (3265), (3477), (4004) and others.
If you wish to pursue this question, some background information on
the general problem you are trying to solve -- in addition to what
approach(es) you are trying to use to solve it -- would be quite
helpful in providing an answer and/or potential alternatives.
You cannot improve on the interrupts provided by the system hardware
tick rate without some combination of device drivers and/or external
interrupt source. The OpenVMS system generally "acquires" some
specified number of hardware ticks before a software tick is generated
-- the software clock ticks over every 10ms, while the hardware tick
occurs at an architectural minimum rate of 1000 times per second.
Various Alpha systems have a hardware tick rate of 1024 interrupts
per second. As mentioned, the OpenVMS Alpha software clock rate is
10ms, meaning that a (large) number of hardware ticks transpire for
each software tick.
[Given that the OpenVMS Alpha software tick rate operates at 10ms
intervals, you will have some difficulty with a 5ms AST interval.]
The Accuracy Bonus is periodically added to the system time to "correct"
a tick rate such as 1024 ticks per second for the rounding errors that
are inherent when producing an integer representation of the number of
10ms intervals (ticks) that have transpired -- based on a hardware
interrupt that occurs every 1/1024 seconds, the accuracy bonus accounts
for an expected rounding error in this calculation of the current time
in 10ms units, in other words.
You will want to consider what level of accuracy is required for your
particular application, and what sort of time-related processing is
required. Triggering ASTs at periodic intervals may or may not be an
appropriate approach, depending particularly on the frequency of
interrupts required and on the time that is required to activate and
service each AST. (Further, available techniques and options can and
do vary between user-mode application code and kernel-mode driver code.
Kernel-mode code can use recurring TQE entries, or various other
approaches.)
Two common approaches to timekeeping involve the Alpha RPCC and RSCC
counters. An example of working with RSCC (beware SMP effects, as the
system cycle counter is CPU-local) follows:
$ cc/prefix=all show_rscc+sys$library:sys$lib_c/library
$ link/sysexe show_rscc
/*
// This program demonstrates the usage of the System Cycle Counter
*/
#include <stdio.h>
#include <signal.h>
#include <hwrpbdef.h>
#include <evx_opcodes.h>
#include <c_asm.h>
#define QUOTE(s) #s
#define QUOTEVAL(s) QUOTE (s)
#define RSCC() (asm ("call_pal " QUOTEVAL (EVX$PAL_RSCC)))
extern HWRPB* exe$gpq_hwrpb; /* Hardware Restart Parameter Block */
int main( int argc, char** argv )
{
__int64 scc1, scc2, micro;
scc1 = RSCC();
sleep (3);
scc2 = RSCC();
/*
// The number of ticks per second is located in the Hardware
// Restart Parameter Block (HWRPB). Convert it to microseconds.
*/
micro = (1000000 * (scc2 - scc1)) /
exe$gpq_hwrpb->hwrpb$iq_cycle_count_freq;
printf ("%Ld microseconds\n", micro);
}
|