|
Just when all was thought to be quiet regarding clock problems I'm seeing some interesting issues. Rather than add this to the existing posts I'm putting it here because I'm only seeing it on the -SA machine.
Ever since the previously discussed clock problems I've had my modified TempDir running monitoring the clock. It runs continuously from startup and it tracks the day, month and year
from when it is first run. If the day, month, or year change then it reports the change, showing the Basic TIME$ and the Territory_ConvertTimeToUTCOrdinals time from CMOS clock (OS_Word 14,3). This was originally done to catch jumps in the year whilst there was suspicion about clock sync with Windows but for a long time I had not noticed the year jump. Then, today, I examined the log output.
In the last couple of days six clock jumps have been recorded:
1 Mon,08 Jun 2009.19:48:47 from bogus Tue,06 Jan 2009.20:46:03
2 Mon,08 Jun 2009.21:24:53 from bogus Tue,06 Jan 2009.20:44:03
3 Mon,08 Jun 2009.23:18:49 from bogus Tue,06 Jan 2009.18:17:59
4 Tue,09 Jun 2009.05:58:56 year had jumped to 08 Jun 2008
5 Tue,09 Jun 2009.12:15:44 from bogus Tue,06 Jan 2009.20:46:02
6 Tue,09 Jun 2009.16:42:38 from bogus Tue,06 Jan 2009.20:46:02
Its interesting that the bogus time of 1, 5 and 6 above are so close - perhaps there is a clue here. And 6 above happened just a few minutes ago whilst I was watching it. The alert came up in the log to say the time had jumped and a couple of seconds later it recorded the fact that it returned to the correct time. This means the RISC OS view of the CMOS clock temporarily changed.
SyncClock 0.10 (27 Feb 2002) is running so it should be sync'd to Windows and the hostclock DLL is running.
The clock jumping is in itself an interesting phenomenon but there is an added peculiarity in that the values of N%!0 N%!4 and N%!8 (where N% points to the buffer returned from Territory_ConvertTimeToUTCOrdinals) are: N%!0=808401202 N%!4=959459125 N%!8=0. These should be centiseconds, seconds, minutes but the first two contain ASCII bytes "90/50/92" which reversed is "29/05/09" (29 May 09). This is obvously left over from the previous SWI (Territory_ConvertDateAndTime) so Territory_ConvertTimeToUTCOrdinals is not working correctly although the day, month, year and hour seem to be correct. It also worked correctly when TempDir was started. Even more bizarre is that the Territory_ConvertDateAndTime had been executed immediately prior to every one of the time change reports listed above. So why is it "29 May 09" anyway? The machine was powered down on that date and was not powered up again until 8th June. It suggests its a value that was stored in CMOS RAM and saved on shutdown. However, since the SWI is called on every Wimp poll why is it not showing todays date?
Here is the code:
Day% Mon% Yr% are set at startup.
REPEAT
PROCpoll:!Z%=3:SYS7,&E,Z%
SYS"Territory_ConvertDateAndTime",-1,Z%,N%,&80,Df$TON%:F$=FNA(N%)
IF F$<>H$THEN
SYS"Territory_ConvertTimeToUTCOrdinals",,Z%,N%
IF N%!24=Yr% PROCM:H$=F$ ELSE PROCdtchk
IF(N%!16<>Day%)OR(N%!20<>Mon%)THEN
Time%=TIME:Time$=TIME$
*Report \Y Time$ Day% Mon% Yr% N%!16 N%!20 N%!24
*Report \Y N%!12 N%!8 N%!4 N%!0 N%!32 Time%
Day%=N%!16:Mon%=N%!20:Yr%=N%!24
ENDIF
F$=H$
ENDIF
UNTIL Q%:SYS17
END
H$ is the current name of the temp directory for today's date.
F$ is the potential new name for the temp directory based on the new date.
FNA returns a string from null-terminated string (e.g. "29May09")
PROCM creates the new directory if it doesn't exist
PROCdtchk is the year jump catcher
Have I missed something here?
And the crucial question is what is happening to the CMOS clock? Is Windows changing it periodically? I wonder if its anything to do with ntp updates?
|
Login 
FAQ
Search 
