Thank you Justin Haase. Your comment helped me see that my earlier
posting today of 23 minute window would not work for DST/STD time
changes of 60 minutes.
You can make the system clock "crawl" or "race" if you use NTP client
and
set NTP to have a larger "adjust time" than 60 minutes and use a time
zone
that doesn't have an automatic DST change (and ensure your time source
changes). By default I believe it's 20 minutes +/-, so this won't work
without some manual intervention. Otherwise the system just snaps to
the
new hour and continues on its way.
Based on Justin's observation I changed my client Poll interval to 120
minutes and it makes time slow down!
CHGNTPA RMTSYS('0.POOL.NTP.ORG' '1.POOL.NTP.ORG' '2.POOL.NTP.ORG')
AUTOSTART(*YES) POLLITV(120) MINADJ(2000) MAXADJ(120)
ADJTHLD(*MAXADJ) ACTLOG(*POLL) SVRAUTOSTR(*YES) SVRACTLOG(*ALL)
I set the IBM i time ahead one hour to start my test today.
The computer slowed down its clock and began running at half speed to
incrementally adjust/decrement the time.
Time on
Cellphone Time on IBM i
13:12 Time . . . . . . . . . : 14:06:18 HH:MM:SS
13:13 Time . . . . . . . . . : 14:06:55 HH:MM:SS
13:14 Time . . . . . . . . . : 14:07:24 HH:MM:SS
13:15 Time . . . . . . . . . : 14:07:52 HH:MM:SS
13:16 Time . . . . . . . . . : 14:08:23 HH:MM:SS
13:17 Time . . . . . . . . . : 14:08:52 HH:MM:SS
13:18 Time . . . . . . . . . : 14:09:21 HH:MM:SS
13:19 Time . . . . . . . . . : 14:10:21 HH:MM:SS
13:21 Time . . . . . . . . . : 14:10:52 HH:MM:SS
13:22 Time . . . . . . . . . : 14:11:22 HH:MM:SS
13:23 Time . . . . . . . . . : 14:11:51 HH:MM:SS
13:24 Time . . . . . . . . . : 14:12:21 HH:MM:SS
13:25 Time . . . . . . . . . : 14:12:54
13:26 Time . . . . . . . . . : 14:13:23
13:27 Time . . . . . . . . . : 14:13:53 HH:MM:SS
13:28 Time . . . . . . . . . : 14:14:21 HH:MM:SS
13:29 Time . . . . . . . . . : 14:14:52
13:30 Time . . . . . . . . . : 14:15:29
13:31 Time . . . . . . . . . : 14:15:51
13:47 Time . . . . . . . . . : 14:23:52 HH:MM:SS
SNTP Client Activity Log QTOTNTP/QNTP/877117 10/31/09 2:03:12.269 PM
TCP9136 SNTP Client started.
TCP9146 Using time server 0.POOL.NTP.ORG.
TCP9162 10/31/09 2:03:12.373 PM Time remaining for adjustment is
3483.413 seconds.
TCP9116 10/31/09 2:03:12.373 PM NTP server UTC time is 10/31/09
18:05:08.960.
TCP9117 10/31/09 2:03:12.373 PM Client clock UTC time is 10/31/09
19:03:12.373.
TCP9120 10/31/09 2:03:12.373 PM Client clock adjusted = 1 (0 = not
adjusted, 1 = adjusted)
************End of Data********************
Client adjustment threshold (ADJTHLD) - Help
Specifies the threshold which determines whether changing the clock
will
require setting or adjusting the clock.
o Setting the clock means replacing the current clock value with a
new
value. For instance replacing 12:47:56 (in hhmmss format where hh
=
hours, mm = minutes, ss = seconds) with the value 12:56:15 or
12:40:10. Setting the clock in this manner causes the clock to
jump
either forward or backward and can cause errors and unpredictable
results if programs are accessing the clock time values before and
after this setting of the clock. Setting of the clock requires
full
knowledge of the system environment. Otherwise unpredictable
results can occur.
o Adjusting the clock means to incrementally speed up or slow down
the
clock so that time is gradually synchronized with the NTP or SNTP
time server. Adjusting does not cause the large jumps in time that
can be experienced with setting the clock. Adjusting does however
take time to complete. For instance adjusting the clock by 1 second
may take 10 seconds of wall clock time to complete. Note that this
10 second wall clock interval is just an example, the system
determines how long the adjustment will actually take to complete.
While adjusting of the clock is not as immediate as setting of the
clock, it does avoid the problems associated with setting the clock
while programs are accessing the clock time.
midrange.com
