Operating System - OpenVMS
cancel
Showing results for
Did you mean:

## DST Time Drift

SOLVED
Go to solution
Trusted Contributor

## DST Time Drift

We use the old Springforward/Fallback macro for drifting time for the DST time.

The macro has the following:
\$ IF F\$GETSYI("HW_MODEL") .LT. 1024
\$ THEN FIVE_HOURS = "1800000" !VAX
\$ ELSE FIVE_HOURS = "18433179" !AXP

Where do I get the value for the FIVE_HOURS?
I am trying to setup the same macro to be tested on Itanium.
12 REPLIES 12
Honored Contributor
Solution

## Re: DST Time Drift

Peter,

The value 18433179 is 5x60x60x1024, in other words, the number of 1024Hz ticks in 5 minutes - the Alpha clock interval. (well, actually it's not quite that value, I think it should be 18432000, but I don't know what the programmer was thinking). The VAX number is 5x60x60*100 which is the number of 100Hz (10mSec) ticks in 5 minutes, the VAX clock interval.

I think the I64 value should be the same as the Alpha number.
A crucible of informative mistakes
Honored Contributor

## Re: DST Time Drift

FWIW,

If I were writing that code, I would have written it as:

\$ FreqVAX = 100
\$ FreqAlpha = 1024
\$ FreqI64 = 1024 ! ?
\$ FIVE_HOURS=5*60*60*Freq'F\$GETSYI("ARCH_NAME")'

to make the theory and reasoning more obvious.

I'd be even happier if I could find a \$GETSYI item to return EXE\$GL_SYSTICK so the value could be derived in an architecture independent manner, rather than hard coded.

You can confirm the I64 value by comparing EXE\$GL_SYSTICK between I64 and Alpha. The Alpha value is %X2625 = 9765 Decimal, which means .0009765 seconds, or 1/1024th second.
A crucible of informative mistakes
Trusted Contributor

## Re: DST Time Drift

The values from my itaniums.

SDA> exa EXE\$GL_SYSTICK
EXE\$GL_SYSTICK: 00000000.00002710 ".'......"
SDA> EXAM EXE\$GL_TICKLENGTH
EXE\$GL_TICKLENGTH: 00000000.00002710 ".'......"

18432000 as the five_hours would make more sense for the alpha.
Honored Contributor

## Re: DST Time Drift

Peter,

> The values from my itaniums
>
> SDA> exa EXE\$GL_SYSTICK
> EXE\$GL_SYSTICK: 00000000.00002710 ".'......"

That's 10000 decimal, so the frequency on I64 is 1000. Your FIVE_HOURS should therefore be 18000000. My version would be:

\$ FreqVAX = 100
\$ FreqAlpha = 1024
\$ FreqI64 = 1000
\$ FIVE_HOURS=5*60*60*Freq'F\$GETSYI("ARCH_NAME")'

(I'm also assuming that ARCH_NAME returns the string I64, but no access to an I64 system to check)
A crucible of informative mistakes
Trusted Contributor

## Re: DST Time Drift

arch_name = IA64
Honored Contributor

## Re: DST Time Drift

Wouldn't that tick be CPU speed dependent as well as platform dependent?

My Alpha 4100 5/600s give a value of 208D Hex, or 8333 (1/1200th second) and not the 2625 Hex (1/1024th second) John listed above.
Trusted Contributor

## Re: DST Time Drift

I thought the CPU dependent value was EXE\$GL_TICKLENGTH. This is the one we have been having to change on each different version of alpha cpu to get the drift right.

## Re: DST Time Drift

Could be because I'm on version 7.1. I get the same value returned for exe\$gl_systick and exe\$gl_ticklength.
Honored Contributor

## Re: DST Time Drift

>I thought the CPU dependent value
>was EXE\$GL_TICKLENGTH

See section 12.6 of the IDSM "INTERVAL TIMER INTERRUPT SERVICE ROUTINE".

EXE\$GL_SYSTICK should be constant, dependent on the hardware (I thought all Alphas were supposed to be the same, but obviously not since Gregg is seeing a different value).

EXE\$GL_TICKLENGTH is initially set from EXE\$GL_SYSTICK, but may be varied dynamically in order to drift the clock back or forwards to synch with external time standards.
A crucible of informative mistakes
Honored Contributor

## Re: DST Time Drift

Peter,

If you are going to run this on more than a single model of the Alpha, you can't safely use a single value, as we are now aware of at least 3 different frequencies. 1024, 1200, and 974.

I would suggest you get the TBO V2.0 kit from VMS freeware 6. On Alpha AXP it computes the values based on SYSTICK and the frequency from the hwrpb. Here are some of the comments from the top of the included TBO.MAR source file.

It won't work as is on an IA64, but it could probably be retrofitted easier than starting from scratch.

; VAX has a 10millisecond clock (a tick). ALPHA has an interval timer that
; is determined by the value in the hardware restart parameter block (HWRPB)
; at offset HWRPB\$IQ_CLOCK_INT_FREQ. This value will minimally be 1000 and
; and initially all ALPHA systems will generate 1024 interupts (ticks) per
; second.
;
; Note that we'll use the following:
; VAX & ALPHA:
; EXE\$GL_SYSTICK - standard clock tick length
; EXE\$GL_TICKLENGTH - increment added to clock at each hardware clock interrupt
; EXE\$GL_TIMEADJUST - number of ticks to apply EXE\$GL_TICKLENGTH
; ALPHA:
; EXE\$GPL_HWRPB_L - hardware restart parameter block
; HWRPB\$IL_CLOCK_FREQ_L - offset to clock interrupt frequency

NOTE: the comments have a typo, where is says HWRPB\$IL_CLOCK_FREQ_L it should be HWRPB\$IL_CLOCK_INT_FREQ_L

Just a note: The ES47 doesn't follow the Alpha architectural spec with respect to the minimum hwclock interrupt frequency. The manual states "minimum of 1000 times per second", the ES47 (at least ours) is 974 Hz.

\$ write sys\$output f\$getsyi("HW_NAME")
hp AlphaServer ES47 7/1150
\$
\$ analyze/sys

OpenVMS (TM) system analyzer

SDA> eval @(@EXE\$GPL_HWRPB_L+HWRPB\$IL_CLOCK_INT_FREQ_L)/1000 ! scaled by 4096 decimal
Hex = 00000000.000003CE Decimal = 974 UCB\$L_PI_TGT_SCRIPT+00002
SDA> Exit
\$

And for comparison, on an ES40

OT\$ write sys\$output f\$getsyi("HW_NAME")
AlphaServer ES40
OT\$ analyze/system

OpenVMS (TM) system analyzer

SDA> eval @(@EXE\$GPL_HWRPB_L+HWRPB\$IL_CLOCK_INT_FREQ_L)/1000 ! scaled by 4096 decimal
Hex = 00000000.00000400 Decimal = 1024 ACB\$M_NODUP
BUG\$_UNEXPIOINT
CHPCTL\$M_INTERNAL
CPU\$C_MAX_CBB_CPUS
CPU\$M_VIRTCONS
|
(remaining symbols suppressed by default)
SDA> Exit
OT\$

Jon
it depends
Trusted Contributor

## Re: DST Time Drift

Keeping this thread as a reference until I get approval/authorization to get this drift working on Itanium too.