For support and advice on VirtualAcorn products
Forums now closed. This is an HTML only record of the content.
HTML version of Forum generated Thursday 24th May 2018

All times are UTC [ DST ]

Post new topic Reply to topic  [ 2 posts ] 
Author Message
 Post subject: Clock problems again
PostPosted: Tue Jun 09, 2009 5:09 pm 

Joined: Thu Nov 28, 2002 7:08 pm
Posts: 69
Location: Cambridge
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.
IF N%!24=Yr% PROCM:H$=F$ ELSE PROCdtchk
*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%

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?

 Post subject: Re: Clock problems again
PostPosted: Tue Jun 09, 2009 9:30 pm 

Joined: Thu Nov 28, 2002 7:08 pm
Posts: 69
Location: Cambridge
OK, there is no problem with Territory_ConvertTimeToUTCOrdinals. Further investigation revealed that the memory pointed to by N% is used in a nested call to a function (note that its not easy to spot these things in code that has been squashed - so thats my excuse). However, the clock problem is a real problem and needs further investigation.

Post new topic Reply to topic  [ 2 posts ] 

All times are UTC [ DST ]

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Forums originally Powered by phpBB © 2007 phpBB Group. Contents © 3QD Developments Ltd 2018 version no. 1.07