  Precision Timekeeping? (rscc, rpcc) 
 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 &lt;stdio.h&gt;
#include &lt;signal.h&gt;
#include &lt;hwrpbdef.h&gt;
#include &lt;evx_opcodes.h&gt;
#include &lt;c_asm.h&gt;
 
#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-&gt;hwrpb$iq_cycle_count_freq;
 
  printf ("%Ld microseconds\n", micro);
  }
 
 
 
 Answer written or last revised on  7-JAN-2004 
