Clock drift

As I’ve mentioned before I’m setting up a competition timing system using a pi3B as the clock source. I’ve checked it against a stopwatch overnight and found that it drifts by just over a minute in 13 hours. This means that over a typical competition run, the difference between it and a stopwatch would be around 1 to 2 centiseconds, i.e. not detectable by stopwatch. I’m happy with that.

However the reason I checked it like that, was when I realised the time difference between the ARMX6 I use for development and the rPi was growing quite fast. Accordingly I ran the same check on the ARMX6.

The ARMX6 is set to use network time setting. This morning it successfully set its time at startup, and again later. It is set to recheck every 30 minutes.

During a 90 minute test it lost a minute and a half against the stopwatch. It would have rechecked NTP twice during this time, and the most recent one was recorded as successful. I was surprised, to say the least as I have been assuming that an ARMX6 locked into NTP would be accurate. Instead the rPi free-running is more accurate, by a big margin.

It’s fortunate that it’s this way round as it’s the rPi clock that will be timing the competition.

(If I had found a significant drift on the rPi I could have introduced a fixed correction – I use an event in TickerV to do the time collection, and that could add or subtract a count every so often. In this case it would be adding 1 every 10000 cycles. What I’m not sure of is whether the rPi clock can be expected to always drift by the same amount, or whether it depends, for example, on temperature.)

Just to complicate things, where the competition takes place it is difficult to use NTP. The only way I can be sure of an internet connection is on Windows via my iPhone. I would have to configure the windows NTP server and reconfigure the clients to use it.

To make things quite clear, the timing of the competition does not depend on the synchronisation of clocks between computers. It records the time of start of a run and time of finish of a run using the same clock on the same computer. The run time is then calculated from these events. The only issue is that if things drift too far, someone observing the displayed event times on a different computer may notice apparent anomalies.

I may have to resort to adding code to the system to synchronise the clocks on all the computers to the timing computer. At the moment I do it from the ARMX6 when the network is started up. It gets them within better than half a second, which would be adequate.

Have you tried running a TimeServer on the Server machine and FreeTime on the clients (which I assume are networked to the server)? They use UDP – I think NetTime is only NTP. They can possibly be persuaded to sync just before each race. See https://armclub.org.uk/32bit/

You say the ARMX6 lost 90 seconds after 90 minutes – was that loss all since the last NTP check, or the total loss? Perhaps regular NetTime_Status commands would show drifts. Are you sure your stopwatch is accurate?! It seems a large drift to me.

You say the ARMX6 lost 90 seconds after 90 minutes – was that loss all since the last NTP check, or the total loss?

That was over the 90 minute period, during which there would have been 2, maybe 3 ntp checks. I suspect that the time may have been out significantly when I started the test, and got a big correction partway through. Yesterday ntp was showing as “disconnectred” for most of the day.

I’ve now set time to manual, and it’s lost 3 seconds in 3 and a half hours.

Are you sure your stopwatch is accurate?!

Pretty sure. During the competitions these watches are the backup system, and they are used in pairs, so regular checks are made that both show the same time.

I wasn’t aware of a time sever for RISC OS – thanks for the link. Ideally they would all sync to the machine with the lowest drift rate. On present form, that will be the rPi3B which is the timing computer.

Yesterday ntp was showing as “disconnectred” for most of the day.

I am also seeing this. I am interested in what conditions would cause this?

Alan, how old is the version of RISC OS you’re using? There were some bugs in the RTC module which could cause bad clock corrections to be applied (e.g. the first correction on boot would typically be applied in the wrong direction), and could explain the 90 second error you were seeing on the ARMX6. These were fixed with RTC 0.02.

There’s also an unresolved issue, which is that comparisons against the hardware RTC may result in the system thinking the time is out by +/-1 second, because the OS assumes the hardware RTC can report the time with centisecond accuracy (when in reality the RTC’s sub-second counter is typically inaccessible to the outside world).

To avoid the 1-second error you can *RMKill the RTC module. This will stop both hardware RTC and NetTime clock corrections from being applied. The system timer will be reset to its default frequency, so assuming you don’t have any other software loaded which is fiddling with it, the only clock drift you should experience will be due to inaccuracies in whatever crystal is driving that timer (probably around a couple of seconds per day).

I’m running RO5.25 as supplied by R-Comp with the ARMX6.
Help RTC shows 0.01.
Is there any reason not to find and install the later RTC module?

My plan for the system at the moment is to make the rPi3b the clock master when we’re runing at a competition. In a demonstration last night I had to reset that computer partway through, and it lost about half a minute, as it doesn’t have an RTC hardware module fitted. I’m going to rectify that.

(Since the whole GPIO bus is connected into the electronics box by a ribbon cable, I’ve had to extend the first part of the bus within the electronics box and fitted a header ready to plug the module on to. The RTC module will be housed within the electronics box.)

My only remaining concern then is whether the RTC hardware module can cause the computer clock to jump. Actually it isn’t even that, it’s whether it can cause tickerV events to be skipped or duplicated, since I count those independently. In other words does it adjust the clock by any means while RISC OS is running, or is it only used to set the clock at boot time?

Is there any reason not to find and install the later RTC module?

The current version should work fine as a drop-in replacement (preferably load it before the network setup part of the boot sequence). However it’s not included in the disc image, so you’ll probably have to build it from source.

My only remaining concern then is whether the RTC hardware module can cause the computer clock to jump. Actually it isn’t even that, it’s whether it can cause tickerV events to be skipped or duplicated, since I count those independently.

There are two methods used to adjust the clock:

• Small corrections are applied by adjusting the frequency of the monotonic timer. E.g. if the software RTC is ahead of the hardware RTC (or network time), the monotonic timer frequency will be reduced, and you’ll get under 100 TickerV ticks per real-world second. This is limited to within +/-2% of the “correct” frequency.
• Large corrections (anything larger than 32767 centiseconds – about five and a half minutes) are applied by immediately updating the software RTC to the new time value. So any software which is using TickerV or the monotonic timer to track real time will get confused.

In other words does it adjust the clock by any means while RISC OS is running, or is it only used to set the clock at boot time?

Every hour the RTC module will check the time against the hardware RTC and adjust/apply the correction. I think the first of these corrections will only be calculated once the computer’s been turned on for an hour.

If there’s a time source available with a higher “priority”/accuracy (e.g. NetTime) then that will override lower-priority sources like the hardware RTC. And each time source is responsible for deciding how often corrections should be calculated (e.g. NetTime does it every half hour).

However it’s not included in the disc image, so you’ll probably have to build it from source.

As I don’t have access to development tools, not even just a C compiler, I don’t think that will be possible.

Is it in any of the recent rPi downloadable SD card images? I seem to recall Zap can extract modules if present.

Every hour the RTC module will check the time against the hardware RTC and adjust/apply the correction. I think the first of these corrections will only be calculated once the computer’s been turned on for an hour.

I think therefore that I will use the RTC hardware clock to set the time at boot, but not allow automatic adjustment. The rPi (RO5.24) I am using for timing doesn’t have an RTC module of any version present, so that should not present problems. I don’t mind a steady and constant small drift rate. What would produce inconsistent scores would be a rate that changed during the day, and it sounds as though the RTC software module could cause that. However a jump of the software clock would not cause me such a problem, because I’m doing the timing by counting TickerV events. That’s mainly because it’s easier for the interrupt code to handle the counter as an integer rather than accessing a 5-byte value every centisecond. Actual (approximate) time of day is only used for display to the operators, and is obtained by adding this counter to a 5-byte value stored when the interrupt counter started.

As I don’t have access to development tools, not even just a C compiler, I don’t think that will be possible.

Is it in any of the recent rPi downloadable SD card images? I seem to recall Zap can extract modules if present.

Yes, and any idiot could save it out by just doing Module>Extract from the Verma menu.

I can’t see why the same, or another, idiot couldn’t e-mail it to you, as it’s released into the wild, if they had a valid address for sending!

Unfortunately those idiots would be doomed to failure, because it’s written in C and so won’t work when extracted from a ROM image (ROM builds of C modules are statically linked to the ROM version of CLib).

s it in any of the recent rPi downloadable SD card images?

As John says using Verma to “Extract” the module ready to be loaded from disc is rather easy. Using Zap is actually overkill.

Unless there’s a difference in the RTC module in a Pi or iMX6 or RPC (IOMD) ROM image then running anyone of them with a current beta ROM would give a build you could extract from.

PS. Well while I was writing the last paragraph Jeffrey identified the difference. So, you’d need someone with the ability to build the module as a standalone to do that and post it to you.

ROM builds of C modules are statically linked to the ROM version of CLib

Would it work if you also extracted the CLib?

I suspect the answer’s going to be no, static implying fixed adresses, so does this not make a bit of a nonsense of the modularity principle I’ve always taken to be one of the bases of RISC OS? The same principle we more-generally apply to having separate apps for separate functions so that we can understand better what’s going on.

It sounds a bit like using GOTOs in BASIC!

We haven’t used those since we used to program the display ZX80s to do something peurile in the shop.

Or am I (characteristically) misinterpreting the situation?

[this idiot’s first computer was a ZX81]

A RAM build of RTC 0.02 is here in the hope that it might do what is required. It softloads here.

Build details.

Machine : All
APCS : APCS-32

HTH.

I suspect the answer’s going to be no, static implying fixed adresses

Yeah, just saying that it’s statically linked to CLib was a bit of a simplification. It’s linked for a specific address within ROM (e.g. &FC123450), and it’s linked to the ROM version of CLib (which will also be at a specific address within ROM). So to successfully extract it from ROM and run it on another machine you’d need to extract both the module and CLib, and then run them from the same addresses as the original ROM location (which will be tricky because that’ll be right ontop of your current machine’s ROM).

so does this not make a bit of a nonsense of the modularity principle I’ve always taken to be one of the bases of RISC OS?

Only a little bit.

does this not make a bit of a nonsense of the modularity principle I’ve always taken to be one of the bases of RISC OS

Not really when you consider that the way CLib works is to patch in a jump table to the end of the program – if you look inside a C program, you’ll see lots of dummy instructions towards the end, these are patched up by CLib to point to the right places.
Clearly this isn’t going to work on stuff in a ROM, so baking the addresses directly into the ROM is going to be the way to go here. RISC OS is still modular, it’s just that those modules are tied to that particular build of the OS.

What you’d need, as David kindly supplied, is a standalone build that links itself in in the usual manner.

What you’d need, as David kindly supplied, is a standalone build that links itself in in the usual manner.

Thank you for that. I’ve now put it in boot:choices.boot.predesk, and it is being initialised so that after reboot help rtc shows v0.02.

I’ve set date and time to use the net, and it says sync successful, both during boot and manually.

However compared to a windows PC, and to a website showing current London time, it’s a steady 12 seconds slow. Should I expect this?

(https://www.timeanddate.com/worldclock/uk/london)

However compared to a windows PC, and to a website showing current London time, it’s a steady 12 seconds slow. Should I expect this?

You might find that it’s the Windows PC that’s wrong, not RISC OS. I’ve noticed on several occasions that my Win 10 PC is off by a minute or two. And I’m fairly certain that website will just be applying a timezone offset to your computer’s local time, instead of using a trustworthy network time source!

You might find that it’s the Windows PC that’s wrong, not RISC OS.

You are of course right.

I just repeated the comparison, and the difference is down to 2 seconds. Running the website and PC clock side-by-side shows them as identical.

Running the website in Netsurf shows a static clock – i.e. no javascript to update the display.