Conference vaxaxp::vmsnotes

	the following routine expects nanoseconds as input. In my case
	I needed 500 msec delay within a driver...

	/cmos


[.....]
int64		delay_nanos = 500000000;  // 500 msec in nanosecond units
[.....]

[.....]
	//
	// Need to wait 500 msec before clearing the reset bit
	//
	status = exe$delay ( &delay_nanos );
[.....]
    

EXE$DELAY is just a loop inplemented by reading the rscc counter....

The system time resolution is still (in V7.1) 10 Ms. The system clock ticks
faster, but only 10Ms units are used.

Jur.

re .2
    
>The system time resolution is still (in V7.1) 10 Ms. The system clock ticks
>faster, but only 10Ms units are used.
    
    Can you elaborate on this?
    
    Alpha VMS V6.2 updates the quadword system time at 1024Hz.
    
    Are you saying that despite this, timer requests are only processed
    with the traditional 10ms granularity?
    
    NB: 10 Ms would be disappointing. (-:
           ^

    	Some VAX implementations included a hardware interval timer 
    register.  By programming this register, you could determine the
    interval between special hardware interrupts, from which you 
    could derive more accurate time measurements than the standard
    10 millisecond tick.  The VAX system I'm most familiar with 
    had a 1 MHz clock feeding a programmable divider to provide the
    increased resolution.  However, it was up to the "user" to imple-
    ment this feature.  Perhaps some Alpha CPU chips also have built-
    in interval timers that could be exploited.  
    
    Greg
    

:>The system time resolution is still (in V7.1) 10 Ms. The system clock ticks
:>faster, but only 10Ms units are used.
:    Can you elaborate on this?

   See VAXAXP::NOTES$ARCHIVE:ALPHANOTES_V2 note 385.*.
    

I think you're out of luck, without adding new hardware, or possibly writing
some kernel-mode code.

The only VMS timer available from user-mode has a granularity of 10 milliseconds
(via $SETIMR).  The interval clock ticks at approximately 1 millisecond
intervals, but you have no access to that, short of stealing the interrupt
vector.

There are three hardware counters:

system cycle counter, which doesn't interrupt and so is useless unless you code
timing loops in your code (EXE$DELAY uses this technique);

process cycle counter, which is per-process and doesn't keep "real" time, which
is what I assume you're interested in -- on top of that, it doesn't interrupt.

Performance monitoring counters.  These count "events" (things like cache
misses, and the like), and I believe one of the events is elapsed cycles.
You may be able to create or modify some kernel-mode code to create a timer
using these counters; I don't know because I don't know very much about them. 
If you're interested in learning more, ask in PERFOM::INTERNAL_PERF_TOOLS. 
There was a mention in ALPHANOTES_V3, note 422.

If you do take the plunge and get something useful out of this, please let us
know!

John

    Bah humbug.
    
    I've borrowed clock vectors before now, but not since RT11...
    
    At least it's fairly clear what the answer is.
    
    No comments on the inelegant but simple hack of writing character at a
    time to a 9600 baud port and using I/O completion to throttle the
    message rate ???? Remember, in this particular application, accuracy is
    not essential. I might have a go with that anyway and see just what
    the overhead is (somehow...)
    
    regards
    john

>    No comments on the inelegant but simple hack of writing character at a
>    time to a 9600 baud port and using I/O completion to throttle the
>    message rate ????

I tried doing that once and found that there was definitely too much overhead.
Then again, this was on a Microvax II.

-Mike

    Re: .7
    
.7>    No comments on the inelegant but simple hack of writing character at a
.7>    time to a 9600 baud port and using I/O completion to throttle the
    
    Watch out for possible Transmit silos.  My own choice would also be the
    HWCLK interrupt intercept approach (via an execlet).
    
    John.