www.virtualacorn.co.uk/forum

I am developing a BBCbasic application which needs a fairly accurate RealTime clock running over a period of 24 hours or so. (Accurate in the sense that the time does not drift too much. I only need individual times accurate to the nearest second or two)
I have a few questions which would help clear up things in my mind (and help me find a bug somewhere in my coding which makes the perceived time change unexpectedly - sometimes by minutes at a time)
Question 1 - Am I right in thinking that the time returned by OS_Word 14,3 is the time which is updated from the host clock by the SyncClock module?
Question 2 - To what accuracy is the value of the emulated soft copy of the system time clock updated? (centi-seconds?)
Question 3 - What is the default value for the interval at which SyncClock synchronises the soft copy of the clock?

In reply to your questions:
1. Yes (certainly as far as I am aware)
2. Sorry I don't understand. The RISC OS clock "ticks" away in centi-seconds.
3. It depends what it has been set to (*help SyncClock). I believe the default is five seconds (but I could be wrong).

Question 2 clarification - Is the PC clock also incremented in centi-seconds? And, is the value transferred to that Accuracy (or, to the nearest second, for example?)
Incidently, I am finding that the VRPC-SE clock runs with much better accuracy now that I have added an SNTP client on to Windows XP to stop the time from drifting. (I was coming to the conclusion that running VRPC-SE seemed to cause the PC clock to drift a lot more than it does with no Windows applications running - anything up to 5 or 6 minutes fast within as many hours). Has anybody else seen this

Right now I understand. This is how it works.
When RISC OS starts up it is given a time by VirtualRPC. This time is taken from the time in Windows. The RISC OS clock then starts ticking away from this time in centiseconds. There is no further connection between the two.
SyncClock (if running) checks both times every N seconds and sets the RISC OS time to match the Windows time (if the RISC OS time has drifted).
VRPC has no effect on the Windows clock. The value is only read, not written to. If the Windows clock drifts then the RISC OS one will follow suite (if SyncClock is running).

OK - Thanks.
As I said, it is all running much more accurately with an SNTP Client running on the Windows side of things. (updating the Windows clock every 60 seconds from my ISP's NTP server.

Hmmmm
If only life was so simple.
The Windoes SNTP Client (Tardis200) is just masking the problem by adjusting the clock every so often - so it always looks correct.
But when I look at the SNTP log, the time is being stepped backwards regularly by about 30 seconds every 5 minutes. (A simple BBCbasic program running under VRPC-SE confirms this)
If VRPC-SE does not touch the PC clock, then the PC must be faulty.
My other copy of VRPC-SE on another PC gives the correct time.

I am raking my brains to see what I can suggest.
One thing to double check is that you have all the updates applied to the VRPC on the machine that's going wrong. It's possible that you have a
very old VRPC-SE that's detecting the machines CPU speed incorrectly.
The only other thing I can think of is to ask if this PC is overclocked. If so then putting it the speed back might cause a change. Have you checked to see if this is a known problem with the motherboard in this machine. Are there any BIOS updates?

Thanks for the response.
This copy of VRPC-SE is only half a dozen weeks old, so I am assuming it has all of the updates.
I do not believe that the PC is overclocked.
Enquiring on the PC section of another forum has given me a few things to check - all of which I have done. But one reply has suggested that it is a known fault. I have not yet checked for BIOS updates, but I will.
The PC is one discarded by my daughter's employer when the upgraded. (Matybe we now know why they discarded a 1700 MHz computer )

I have left it running all afternoon without VRPC-SE and the clock is very much more accurate.
BeebEm (A BBC micro emulator) does not seem to have any effect on the clock.
It is now running a test - suggested elsewhere - with just the BIOS running to check the clock - so far so good - after about 2 hours, still seems OK (can't check exactly as the BIOS does not show seconds)
Edit: 5 hours later with just the BIOS setup screen running at the clock has kept perfect time.

On another forum, I am getting replies which suggest that the Windows install my be faulty (it came installed with license sticker on a second hand computer)
If I install a different build windows XP (Home instead of Pro), using a different microsoft key the Activation period will be long enough for me to try this again. (exact same hardware - except for disc drive)
Will VRPC-SE run with the existing unlock code?

Assuming that it's the same hardware and you install all the appropriate third party drivers (sound, graphics, lan etc) then it should be the same code.

OK - thanks.
I will give it a try in the next day or so.

See this post for information on how the SyncClock module works.

On native hardware the CMOS clock is more accurate than the interrupt soft clock, but can still drift by several seconds a day depending on the state of the rechargeable battery, which is likely to be very poor given the age of Risc PC's now. Accuracy can be enhanced by regularly running a ntp time utility which updates the hard and soft clocks from the internet.

When running under the emulator, SyncClock will cause the host OS's clock to be read, and this will rely on it's accuracy and resolution. I don't know if Windows VRPC uses the standard 18Hz DOS clock, which is lower resolution than RISC OS's 100Hz tick, or if it uses one of the many other APIs which can provide microsecond resolutions. How accurate these are depends on the particular PC, Windows doesn't even put seconds on its taskbar clock, so its not as obvious! XP and later also have the ability to update the time from the internet, but it needs to be set up, and by default it seems to only want to check once per fortnight, which is far too long.

But whatever you are doing, you will have to expect time to be quite lumpy on the emulator. If SyncClock isn't run, it will lose time as the Host OS fails to deliver timer events under load, and time will freeze while RISC OS is suspended. If SyncClock is running, regular adjustments will be made, which will result in the clock jumping anything from a few centiseconds to hours. RISC OS 5's RTCAdjust module does a better job smoothing out the small changes, but still has to jump for large adjustments.

Thanks for the update.

I have been busy updating the software on native hardware, so have not looked at this problem for ages.

When I have the next stable build, I will return to testing on VRPC-SE.