NRS6319: Director's Time of Day seems off by about 6 seconds

Commentary

Wednesday, September 12, 2012 at 10:32:27 am    Client reports that the Time of Day (as reflected on Director panels and in TNDLOG) appears to be about 6 seconds different than the actual CPU displayed time of day (e.g. in the console log). The time is actually 6 seconds ahead of CPU time and client wonders why....

Wednesday, September 26, 2012 at 07:40:58 am    I've been successful at recreating the 6 second disparity in an isolated test environment. Appears TNDSTCK is struggling to get the precise seconds out of the results of the system clock.

Wednesday, September 26, 2012 at 11:25:50 am    After more research, it seems that the operating systems have gone through a bit of an adjustment when synchronizing the Hardware clock to UTC instead of GMT. The Director adjusts the Clock value by CVTTZ (GMT time zone adjustment), but does not take into account CVTLS0, which contains the UTC adjusments to handle the difference in how UTC and GMT handle Leap year seconds. Looks like we'll have to patch in logic to adjust the STCK by CVTLSO (leap second offset) prior to converting to human displayable time.

Thursday, September 27, 2012 at 01:20:24 am    Got client to DUMP his CVT Extension to confirm the CVTLSO theory and...not it (his CVTLSO is all zeroes). Returned to TNDSTCK and experimented with starting the time computation as 2012 instead of 1996 and, voila, TNDSTCK got the exact right second. So...I think it safe to say that we've got a bug in STCK that, over time, causes the "seconds" to creep. More testing underway to determine where the flaw is.

Friday, September 28, 2012 at 12:00:33 pm    TNDSTCK, essentially, computes 1 second too much for each Leap Year since 1992, thus a total of 6 seconds from 1992 to 2012. I suspect this is a function of reduction of the TOD clock by the equivalent of a Leap Year, which has a precision that is off by .B4000000 for each Leap year. Am experimenting with several different approaches to resolve this odd behavior.

Tuesday, October 2, 2012 at 09:57:04 am    TND42353 adjust TNDSTCK to reduce the STCK value fed into the decode routine by 1 second per Leap Year. Ultimately, the problem happens because the length of a Leap Year in Timer Units is insufficiently precise in the first 32 bits of the clock (which is used by TNDSTCK). This PTF still actually misses the mark slightly (by the difference between 1 second and 1 timer unit, or .048576 seconds per leap year. But, in the grand scheme of things, I suspect no one will actually notice this.

Friday, October 5, 2012 at 11:50:42 am    PTF was applied at client site and the 6 second gap was eliminated.