[Info-vax] Does anyone know if the unsupported TBO (time boost utility that "drifts" time forward or backward by adjusting ticklength) was every ported to the Itanium?

[Jon Pinkley]

On Thursday, November 5, 2020 at 12:04:50 PM UTC-5, David Jones wrote:
> On Wednesday, November 4, 2020 at 5:48:40 AM UTC-5, Volker Halle wrote:
> > Jon, 
> > 
> > TBO 2.0 (as pointed to by your first entry), compiles and links without error on OpenVMS I64 V8.2. Chances are good, that it will also function correctly, but I didn't try ... 
> > 
> > Volker.
> I assume you have to disable NTP service while running TBO or else the NTP daemon will keep trying to correct the drift.

Yes, NTP or anything else that is modifying either TICKLENGTH or TIMEADJUST has to be stopped during the "time dilation or compression" period.

What TBO does is pretty simple.  It calculates a new ticklength and timeadjust based on user's input /delta is number of seconds to adjust time by, /range is the period of time this adjustment should take (in "normal" time, e.g. our fallback.com has

$ tbo /direction=backward /range=18000 /delta=3600 /info

The above takes 5 hours (18000 seconds) as measured by stopwatch to adjust the openvms software clock EXE$GQ_SYSTIME back by 1 hour (3600 seconds).  In other words, the OpenVMS software clock will advance by 4 hours over a 5 hour period, with the end effect of setting the clock back one hour, while EXE$GQ_SYSTIME continues to march forward with a "relatively" constant rate.  TBO does not touch EXE$GQ_SYSTIME; that is updated by the hwclk interrupt service routine, and the ISR also looks at EXE$GL_TICKLENGTH and EXE$GL_TIMEADJUST (and updates them as well, as needed).

;  EXE$GL_TICKLENGTH - increment added to clock at each hardware clock interrupt
;  EXE$GL_TIMEADJUST - number of ticks to apply EXE$GL_TICKLENGTH (before resetting EXE$GL_TICKLENGTH to the "standard" value EXE$GL_SYSTICK

As far as I know, there is nothing to ensure mutual exclusion, e.g. no DLM lock to prevent another thread from changing these.  no blade guards.   I don't know if NTP and DTSS know about each other either.  TBO does use hwclk spinlock to protect against hwclk interrupt service routine from doing updates to EXE$GL_TICKLENGTH and EXE$GL_TIMEADJUST while TBO is replacing them with new values.

My guess is that if NTP were not stopped, it would quickly replace EXE$GL_TICKLENGTH and EXE$GL_TIMEADJUST with values of its choosing, and the settings that TBO set would be lost.  The effect would be that your clock would not be changed.  Almost like issuing the command $ TBO /RESET shortly after the initial TBO /dire=... /range=... /delta=... (but the new values wouldn't be the default EXE$GL_TIMADJUST = 0 and EXE$GL_TICKLENTH = EXE$GL_SYSTICK)

Also note that sys$manager:utc$time_setup TDF function will also update the EXE$GQ_TDF, EXE$GQ_TODCBASE and EXE$GQ_SAVED_HWCLOCK, even if you don't request the time to be changed.

If you have programs using the CRTL time functions, they will still see an abrupt change in time when the TDF is changed.  So one way to minimize that would be to periodically change the EXE$GQ_TDF to the calculated offset from UTC, but that may cause other problems, because the TZ would still be set to one a specific time zone with offset, and if EXE$GQ_TDF was also "drifting", you would probably odd results.

During the "twilight time zone" if I send email, the sent time is note reported correctly, and it seems to be 2x the difference that I expected.  It still causes fewer problems than file timestamps that overlap during the 2AM DST and 2AM ST period, e.g. 1AM to 2AM "local time" is duplicated in the fall if time is just set back one hour.

There are many places that EXE$GQ_SYSTIME is referenced.