SET RUN TIME CLOCK RESOLUTION?

[Former Member]

My reading of the documentation says that I can use this construct:

SET RUN TIME CLOCK RESOLUTION LOW

to set the value returned by GET RUN TIME to be milliseconds. A:

SET RUN TIME CLOCK RESOLUTION HIGH

would return microseconds.

In a simple test program it doesn't seem to make any difference. The value returned by GET RUN TIME is always microseconds.

Here's the demo program:

REPORT ZPERFTEST2.

tables: TSTC.

data: s_time type i.

data: e_time type i.

data: total type i.

SET RUN TIME CLOCK RESOLUTION HIGH.

get run time field s_time.

DO 10000 times.

• Waste some time..

SELECT SINGLE * FROM TSTC

WHERE PGMNA = 'SAPLC11E'.

ENDDO.

get run time field e_time.

total = e_time - s_time.

write: / s_time, ' ',

e_time, ' ',

total.

Any ideas?

[sridhar_k1]

I think it's OS dependent, If your OS does not support multiple precisions for measurement, ther's no difference between LOW and HIGH.

If SET RUN TIME CLOCK RESOLUTION not used in the progeam, default is HIGH.

REgards

Sridhar

[RichHeilman]

F1 Help....

<i>

<b>SET RUN TIME CLOCK RESOLUTION</b>

Variants:

1. SET RUN TIME CLOCK RESOLUTION HIGH.

2. SET RUN TIME CLOCK RESOLUTION LOW.

Effect

You use these statements to determine the accuracy ofruntime measurements obtained using GETRUN TIME:

Low accuracy measures runtime to the millisecond, but themeasurement interval is longer.

High accuracy measures runtime to the microsectond, but themeasurement interval is shorter. High accuracy is the default setting.

For long measurement intervals (seconds or more), low accuracy isnormally sufficient. The measurement result is correct on allplatforms, regardless of whether the host has one or more processors.

For short measurement intervals (less than a second), you should usethe high accuracy setting, but this depends on the platform and thenumber of processors on the host:

<b>High accuracy measurement produces correct results on either singleor multiple processor machines on the following platforms (forexceptions, see the note below):

AS/400 with OS/400

SNI with SINIX

SUN with SUN-OS

Windows NT</b>

<b>On the following platforms, the high-accuracy measurement is only correct on single-processor hosts - incorrect values may be returned on multiple processor hosts:

DEC with OSF/1

HP with HP-UX

IBM with AIX</b>

On these platforms, the mesurement is based on a hardware registerthat is tied to the CPU. The registers are not synchronizedbetween the different processors. This leads to incorrect valuesfollowing a change of processor. If the measurement section is short, you should repeat themeasurement several times and then take the lowest value as yourresult.

Note

If the measurement interval at high accuracy cannot becontained in a single processor register, an incorrect value willresult (see 'Utilities -> Interval...').

Variant 1

SET RUN TIME CLOCK RESOLUTION HIGH.

Effect

GET RUN TIME uses high accuracy with a shortmeasurement interval to measure the runtime.

Variant 2

SET RUN TIME CLOCK RESOLUTION LOW.

Effect

GET RUN TIME uses low accuracy with a longmeasurement interval to measure the runtime.

Note

Runtime errors:

SET_RUN_TIME_CLOCK_ERROR : After GET RUN TIME, you may no longer use SET RUN TIME CLOCKRESOLUTION.

</i>

Regards,

Rich Heilman

[Former Member]

This particular system is running on Windows - I can't confirm at this point if it has multiple CPUs. I will also test on a Unix box.

I can understand that the HIGH (microseconds) resolution might not work on all platforms, but LOW (milliseconds)? I'd expect that on all platforms.

As it is all I'm seeing on my Windows box is HIGH (microseconds) resolution no matter what.

[sridhar_k1]

Tx: ST06 shows number of CPUs, it's shown next to count top right side.

REgards

Sridhar

[Former Member]

It has 2. Thanks for the ST06 pointer.

[Former Member]

From my reading of the documentation, it seems that that get run time always reports in micoseconds, but if the resolution is set to low, then the precision of the measurement is lower.

Rob