Precision Timekeeping

[YE LIU_1]

Dear VMS users,

I have a question on precision timekeeping. The following is recommended. I found that if I want to use it to meassure rather long time, scc2 - scc1 will be negative or a very large number, which is not useful. Is there a way to work it around while still keeping the high resolution?

#include
#include
#include
#include
#include

#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);
}

[Hein van den Heuvel]

The ticks-per-second is system wide,
but the cycle counter is cpu specific.

How are you ensuring the process is still on thesame cpu? when measuring "a rather long time", could it not easily have been rescheduled on an other cpu?

see also

http://h71000.www7.hp.com/wizard/wiz_8572.html

hth,
Hein.

[Hoff]

There's a whole pedantic discussion of "accurate" versus "precise" -- you've gotten yourself a precise answer here, it's just not an accurate one -- and then there's the necessary discussion around just what you're doing here with with your timekeeping requirements.

And then there's the question of the required precision for your accurate answer. Various OpenVMS APIs can deceptively return high precision values, but with relatively low accuracy.

Then there are the potential alternatives, such as the available ANALYZE /SYSTEM (SDA) tools used to look at PC values other such activities.

Gag. I'm giving the same answer.

[Robert Gezelter]

Ye Liu,

In addition to Hein's comment about switching to a different CPU, consider that it could be on the same CPU, but have been preempted an arbitrary number of times for an arbitrary amount of time.

One much be very careful that the semantics of what one is doing match those desired.

- Bob Gezelter, http://www.rlgsc.com

[Jon Pinkley]

YE LIU,

What problem are you trying to solve? What are you measuring that requires high precision (resolution)?

It appears that the example code you provided came from the "ask the wizard" article Hein referenced. Did you read and understand the text that went along with it? Specifically the part about SMP.

The PCC_CNT register is only 32 bits wide, and is updated by hardware. It takes just over 4 seconds to wrap around on an implantation that updates it once every nanosecond. The interrupt service routine updates the high 32 bits of the unsigned 64 bit value that is returned by CALL_PAL RSSC.

If you are getting a negative value from the subtraction, that implies either that subtraction isn't 64 bits wide, or that you are comparing values obtained from different processors. It takes a long time (If I did the math right, over 584 years, over 292 years if treated as signed) to cause a 64bit resister to overflow, if it is incremented once every nanosecond (1*10^-9 sec) So I don't believe it overflowed.

Jon

[Jon Pinkley]

While what Bob says is true, it is unlikely to be the cause of the problem you are seeing. Multiple processors is much more likely to be the cause.

You can download the Alpha Architecture Manual in PDF format. (Currently available from http://download.majix.org/dec/alpha_arch_ref.pdf)

Here's what the Architecture Manual states:

See what note 3 says. If the SCC looses ticks, interrupts have to be disabled at or above CLOCK_IPL interrupt level for an extended period of time. That is going to be noticeable.


Following from Section II-A OpenVMS Software, pages 10-16 and 10-17.

10.1.12 Read System Cycle Counter
Format:
Operation:
R0 <- {System Cycle Counter}
Exceptions:
Instruction mnemonics:
Description:
The RSCC instruction writes register R0 with the value of the system cycle counter. This
counter is an unsigned 64-bit integer that increments at the same rate as the process cycle
counter. The cycle counter frequency, which is the number of times the system cycle counter
gets incremented per second rounded to a 64-bit integer, is given in the HWRPB (see Section
26.1).
The system cycle counter is suitable for timing a general range of intervals to within 10% error
and may be used for detailed performance characterization. It is required on all implementations.
SCC is required for every processor, and each processor in a multiprocessor system has
its own private, independent SCC.
Notes:
1. Processor initialization starts the SCC at 0.
2. SCC is monotonically increasing. On the same processor, the values returned by two
successive reads of SCC must either be equal or the value of the second must be greater
(unsigned) than the first.
3. SCC ticks are never lost so long as the SCC is accessed at least once per each PCC
overflow period (2**32 PCC increments) during periods when the hardware clock
interrupt remains blocked. The hardware clock interrupt is blocked whenever the IPL is
at or above CLOCK_IPL or whenever the processor enters console I/O mode from program
I/O mode.
4. The 64-bit SCC may be constructed from the 32-bit PCC hardware counter and a 32-bit
PALcode software counter. As part of the hardware clock interrupt processing, PALcode
increments the software counter whenever a PCC wrap is detected. Thus, SCC
ticks may be lost only when PALcode fails to detect PCC wraps. In a machine where
the PCC is incremented at a 1 ns rate, this may occur when hardware clock interrupts
are blocked for greater than 4 seconds.
5. An implementation-dependent mechanism must exist so that, when enabled, it causes
the RSCC instruction, as implemented by standard PALcode, always to return a zero in
R0. This mechanism must be usable by privileged system software. A similar mechanism
must exist for RPCC. Implementations are allowed to have only a single mechanism,
which when enabled causes both RSCC and RPCC to return zero.

[Jur van der Burg]

This will only work on a non-smp system. If you want to use it on smp there's much more involved, like calling smp$calibrate_scc from kernel mode (V8.3 and later only). Look at the LDdriver sources (V9.0) for how I dealt with that.

Jur.

[YE LIU_1]

Is there an api to me to increase the privilige of the code to disable my process to switch to another processor?

Thanks,

YE LIU

[Jur van der Burg]

Look at SYS$PROCESS_AFFINITY in the system service reference manual. By only allowing your process to run on one cpu you may get the desired effect.

Jur.