NetTime has no effect on bootup

The Bazley household recently suffered an unpleasant incident where the RTC battery on the ARMini ran down after the computer was turned off for a week (surely it should be able to hold its charge longer than that…?) and the system clock reset to 1970. Annoying, but in theory non-critical… until NetTime stepped in.

I am given to understand that NetTime should check the time and connect to a server when it is first run (typically from an Obey file in Tasks, put there by TimeSetup). If the local clock is obviously wrong (say, in 1970), then it will correct it to something more sensible. I believe it should also perform a synchronisation at this time.

In practice, it does nothing of the sort.

By the time bootup had completed and email was being downloaded, the system was still convinced it was 1970. Not only had NetTime failed to perform its most basic function in a timely manner, matters were then made even worse by the fact that the other feature of NetTime – namely, to synchronise every 15 minutes (as configured here) – turned out to be working just fine.

Suffice to say, shortly after a vast backlog of emails had been downloaded and datestamped in 1970, NetTime finally woke up and synchronised for the first time. The apparently 44-year-old emails were then promptly expired.

In light of this, I’ve been trying to work out what caused NetTime to fail. The results, as far as I can see, is that NetTime, when run as part of the boot sequence, does nothing.

At the time of the incident, NetTime 0.40 (as part of the stable HardDisc4 image) was installed. I have since upgraded to 0.43, which behaves no better.

The initial advice given to us was to insert a *NetTime_Kick command somewhere in the boot sequence after NetTime had been loaded. This did nothing. I confirmed this by manually setting the system clock 20 minutes early, ensuring the module was still being loaded, and rebooting. The time was still wrong.

Issuing *NetTime_Status immediately after bootup always reports that the clock has not yet been synchronised, including when NetTime has been configured on by TimeSetup.

Issuing *NetTime_Kick in a TaskWindow immediately after bootup works as advertised. But the same command in an Obey file run automatically shortly after NetTime is loaded has no effect, although I have confirmed it is definitely being executed.

I find the whole thing baffling. How can NetTime possibly tell the difference between a Kick command in the boot sequence and one in a TaskWindow?

And is there any way – at all – that NetTime can be persuaded to do its job, and correct large time errors before more important things see them?

I mean, some people don’t have RTC batteries at all, and use NetTime exclusively. That wouldn’t be viable if there was no way to synchronise the time until after the boot sequence had completed, right?

I thought that the operating system now saved the time when it was last shutdown (via CTRL-SHIFT-f12) and would never set the clock to earlier than this on any start up.

Martin – this is not a solution to the shortcomings of RISC OS itself, but can warn you of potential problems.

If you put an Obey file !CheckYear into tasks, with the contents:

If Sys$Year<“2014” Then Error 0 This machine has been reset! Please set the year to the current year and then re-boot!!

that should alert you to any such problems in time to correct them.

I’ve been using this since the days of the A3000, and it’s saved me many a problem of reset CMOS etcetera.

I hope this is helpful, even tho’ it doesn’t address your basic complaint!

Best wishes,

John

Re John’s year checking utility. (We use something similar), I think it would be a very useful addition to all disc builds.

Actually I’m not sure it is in my best interest to be added as we would probably get less paid support work:-/

The apparently 44-year-old emails were then promptly expired.

Surely an equally important bug here is that your mail client is apparently using the system’s time to expire messages, instead of parsing the date/time of the message itself from its headers?

You updated your boot sequence, so you must erase all the network configuration. Else, NetTime will not work. I did have this problem a few weeks ago.

I mean, some people don’t have RTC batteries at all, and use NetTime exclusively. That wouldn’t be viable if there was no way to synchronise the time until after the boot sequence had completed, right?

Not quite a direct answer your question, but I can believe that a system with no RTC at all might behave differently from a system with an RTC but no (useful) battery. If there’s no RTC, you have to get time from a server. If there is an RTC, then the system might naively believe what it says.

I agree that the behaviour you’re seeing is wrong.

Issuing *NetTime_Status immediately after bootup always reports that the clock has not yet been synchronised, including when NetTime has been configured on by TimeSetup.

FWIW my iyonix does correctly fetch the time on bootup, so there has to be something amiss with your config.

FWIW my iyonix does correctly fetch the time on bootup, so there has to be something amiss with your config.

Have just rebooted my PandaBoard for another reason and nettime does indeed sync at bootup.

FWIW my iyonix does correctly fetch the time on bootup, so there has to be something amiss with your config.

As I said before, there are problems with NetTime when you upgrade some components.

Solution: erase Internet in Boot:Choices and configure the network stack again.

A Quick question for those who are finding NetTime doesn’t work during booting: is your network configured for a static IP address?

I’ve never seen any problems with NetTime (it sets the time of a betteryless Beagleboard at boot with no problems), but then I use DHCP and the whole boot stalls while that negotiates with the server. Presumably by the time it completes, networking is available.

If DHCP isn’t being used, is there a chance that NetTime might be getting run by !Boot before there’s a path to the outside world for it to use?

If DHCP isn’t being used, is there a chance that NetTime might be getting run by !Boot before there’s a path to the outside world for it to use?

I don’t thinks so.

After the boot, *NetTime_Kick should work.

It’s a problem within the network config file. Between january and june (sorry not to be more precise), one change in the disc image or the rom make an existing configuration of NetTime not working (but network still works).

I did have exactly the same problem (ie NetTime not working and not connecting to Internet despite a perfectly correct configuration). A reset of the Internet configuration cured the problem.

I can back up David’s comments wrt. something being changed at some point which broke existing NetTime installs. However I can’t remember what it was that changed or when (other than it not being something from the last few months – so maybe a year or two ago).

I can add to all the above that here (R-Comp ARMiniX 5.21) NetTime generally fails to set the clock time. Usually I end up with time errors of tens of secs of more. I asked repeatedly on the support email list for someone to tell me a recipy which I would find reliably set the clock to a second or more. But got no response which worked here. Instead I just got arguments to the effect about what the ‘code’ ‘should’ do. Regardless of what it ‘should’ do, it doesn’t set the clock here. At bootup or when use via ‘set’ accessed from !Boot or !Alarm.

As a result because I don’t understand the ‘code’ involved I’ve simply taken to using wget to fetch a time from the US Navy timeserver. So far I’ve just used that ‘by hand’ but may bodge a way to automate reading the result and setting the clock. I think that way I can get the order of a sec or so of accuracy wrt the Navy clock, which seems good enough for my purposes. Although I may try an NPL fetch if I can work out a suitable way.

FWIW Personally I don’t want a process running in the background and fiddling with the clock at regular intervals. I’d prefer one that simply checks and sets the time at bootup, and then quits. Ideally one the user can alternatively choose to just run on a “set clock and quit” basis as a normal desktop app as well. i.e. double-click or Filer_Run sets the clock and then the ‘code’ quits leaving no residual. Just the clock being set well. I’d use NetTime like this by adding something to kill the module after use. But as explained above, here it doesn’t work. If someone here knows the magic recipy, pray tell, and I’ll try it!

Jim

This thread?

RTC not setting with 24-11 disc update

Sorry, if that was aimed at my problem I’m afraid I am still unclear as to what I am meant to do.

On some occasions when I deliberately set the clock wrong by many mins, using NetTime set it back within better than a sec. But on other occasions that didn’t happen. In effect the same process sometimes worked, but (usually!) doesn’t. And when the error is tens of secs, I’ve never managed to get NetTime to adjust the clock setting to within a second. Leaving it running via !Boot over many startups also fails to set the time accurately.

Jim

Sorry, if that was aimed at my problem

No, aimed at…

However I can’t remember what it was that changed or when (other than it not being something from the last few months – so maybe a year or two ago).

… but probably not relevant.

And when the error is tens of secs, I’ve never managed to get NetTime to adjust the clock setting to within a second.

Hmmm…?

*NetTime_Status
Current time:    Monday, 11 August 2014 20:02:07.10
Status:          Sleeping
Last adjustment: 22 minutes 19 seconds ago
Last delta:      0.312158 seconds fast
Last server:     ntp3.vps.net
Last protocol:   SNTP
Poll interval:   1 hour
*NetTime_Kick
*NetTime_Status
Current time:    Monday, 11 August 2014 20:02:25.00
Status:          Sleeping
Last adjustment: 1 second ago
Last delta:      0.217395 seconds fast
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   1 hour
*

Ah-ha. If you screw with the time, it appears to shut down and not correctly wake up again.

*Time
Mon,11 Aug 2014.20:05:12
*Set Sys$Time 20:05:00
*NetTime_Status
Current time:    Monday, 11 August 2014 20:05:05.16
Status:          Dormant
Last server:     powered.by.root24.eu
Last protocol:   SNTP
Poll interval:   1 hour
*NetTime_Kick
*NetTime_Status
Current time:    Monday, 11 August 2014 20:05:22.25
Status:          Sleeping
Last adjustment: 3 seconds ago
Last delta:      29.954237 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   1 hour
*NetTime_Kick
*NetTime_Status
Current time:    Monday, 11 August 2014 20:05:32.72
Status:          Sleeping
Last adjustment: 4 seconds ago
Last delta:      29.763450 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   1 hour
*RMReInit NetTime
*NetTime_Status
Current time:    Monday, 11 August 2014 20:06:20.88
Status:          Sleeping
Last adjustment: 4 seconds ago
Last delta:      29.487652 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   30 minutes
*NetTime_Kick
*NetTime_Status
Current time:    Monday, 11 August 2014 20:06:26.59
Status:          Sleeping
Last adjustment: 0 seconds ago
Last delta:      29.291932 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   30 minutes
*

I was able to revive it by using the report of the clock disparity to push the system time back to within a second of real time, killing the module, then reloading it from the Obey file (Boot:Choices.Boot.Tasks.TimeSetup)…

*NetTime_Status
Current time:    Monday, 11 August 2014 19:10:40.09
Status:          Sleeping
Last adjustment: 2 seconds ago
Last delta:      0.392308 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   1 hour
*NetTime_Status
Current time:    Monday, 11 August 2014 19:10:45.41
Status:          Sleeping
Last adjustment: 7 seconds ago
Last delta:      0.392308 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   1 hour
*RMKill NetTime
*NetTime_Status
Current time:    Monday, 11 August 2014 19:11:06.26
Status:          Sleeping
Last adjustment: 2 seconds ago
Last delta:      0.061088 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   1 hour
*

I wonder if somewhere there is stored a “time is dirty” flag? Or maybe it just can’t cope with a messed up time?

Right. I set the system clock twenty seconds slow and rebooted.

NetTime did nothing. Calling *NetTime_Kick had no effect.

I left the system clock slow and powered down for a count of ten.

Upon powering up, NetTime did nothing. Again, no joy from *NetTime_Kick!

With repeated experiments (that I’m not going to paste here, it is several screenfuls!), NetTime did not seem to want to wake up until my system clock was within one second of what it thought it should be. This is pretty dumb.

Here is the log of me narrowing the time down to within a second (I’m using a TaskWindow and watching Alarm’s display to guide me), and you will note NetTime doing nothing until I’m within a second of reality:

*NetTime_Kick
*Nettime_Status
Current time:    Monday, 11 August 2014 19:20:27.44
Status:          Sleeping
Last adjustment: 1 second ago
Last delta:      1.203368 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   1 hour
*Set Sys$Time 19:20:36
*NetTime_Kick
*NetTime_Status
Current time:    Monday, 11 August 2014 19:20:41.88
Status:          Sleeping
Last adjustment: 2 seconds ago
Last delta:      1.332044 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   1 hour
*Set Sys$Time 19:21:00
*NetTime_Kick
*NetTime_Status
Current time:    Monday, 11 August 2014 19:21:05.11
Status:          Sleeping
Last adjustment: 1 second ago
Last delta:      0.052088 seconds fast
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   1 hour
*| got to within a second (phew!), should update now
*NetTime_Kick
*NetTime_Status
Current time:    Monday, 11 August 2014 19:21:10.89
Status:          Sleeping
Last adjustment: 1 second ago
Last delta:      0.034867 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   1 hour
*

This deliberate experiment is interesting. I have not specifically noticed any time inaccuracies before, so either CJE’s RTC is super-accurate or NetTime does work, just not when you are looking at it (like a certain cat, perhaps?). At any rate, there ought to be something here to fix as it is pretty clear that it isn’t updating when it says it is?

Module version is 0.43 (28 Nov 2013).

This has been discussed quite vigorously on the ARMini owners list recently. It would appear that when the clock is only out by a small amount (if I recall, roughly 2 mins) then nettime makes gradual, minor “drift” adjustments to hopefully re-align the clock naturally. This prevents wild time changes that could affect apps.

If the clock is wildly out (eg. 1970) it should first restore it from cmos (last clock time stored) then sync more thoroughly (since >2 mins out). Further corrections are made by drift.

As a result, I’d imagine that for machines with battery-powered clocks, only drift-changes will apply, rather than the big step-changes.

Offset the time by a few seconds and then see how that is corrected. The status of the RTC or RTCAdjust module is relevant.

Iyonix OS5.21 (13-Jun-14)
NetTime 0.43 (28 Nov 2013)
RTC 0.01 (18 Nov 2013)

Time is “slowly” corrected.

*nettime_kick
*nettime_status
Current time:    Tuesday, 12 August 2014 07:11:39.69
Status:          Sleeping
Last adjustment: 19 seconds ago
Last delta:      6.637807 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   30 minutes

*nettime_kick
*nettime_status
Current time:    Tuesday, 12 August 2014 07:12:13.03
Status:          Sleeping
Last adjustment: 8 seconds ago
Last delta:      5.745476 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   30 minutes

*nettime_kick
*nettime_status
Current time:    Tuesday, 12 August 2014 07:50:26.17
Status:          Sleeping
Last adjustment: 7 seconds ago
Last delta:      0.573331 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   30 minutes

*nettime_kick
*nettime_status
Current time:    Tuesday, 12 August 2014 08:15:19.71
Status:          Sleeping
Last adjustment: 8 seconds ago
Last delta:      0.085103 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   30 minutes

Iyonix OS5.20
NetTime 0.43 (28 Nov 2013)
RTCAdjust 0.10 Dormant

NetTime_Kick corrects immediately.

Raspberry Pi OS5.21 (06-Aug-14)
NetTime 0.43 (28 Nov 2013)
RTC 0.01 Dormant

NetTime_Kick corrects immediately.

None of this has anything to do with the original issue where a flat battery defeated NetTime on start up. That could and did happened here on the ARMini given the rather short time its battery lasted. A second start always worked.

(1970 made an appearance here recently on the A9home, which was how I discovered the both the A9home and a Iyonix could not obtain a DHCP IP address from a recently installed Apple Time Capsule. The previous Airport Extreme has been OK. Manual setting was just fine.)

What’s the difference between:
  *Configure Timezone +1
and:
  *Configure CEST
?

I noticed my machine was an hour slow, so I corrected the timezone manually and rebooted. The time was an hour slow – I presume NetTime was correcting this back to what it thought I should want?

So I typed *Configure CEST ¹ and the setting has persisted across a reboot.

The only NetTime system variables set are ...$Loaded (is ‘1’) and ...$Server (is “pool.ntp.org”).

¹ Modified version of UK territory that includes CET/CEST as valid timezones.

This has been discussed quite vigorously on the ARMini owners list recently. It would appear that when the clock is only out by a small amount (if I recall, roughly 2 mins) then nettime makes gradual, minor “drift” adjustments to hopefully re-align the clock naturally. This prevents wild time changes that could affect apps.

Alas all the “vigour” clouded over the fact that – even if I set the clock wrong by many mins – using NetTime then generally failed here to accurately set the clock on my machine.

I repeatedly set to times more than a few mins off, and using NetTime – as people told me to – did not always accurately set the clock. On two occasions it did. But I could not replicate this on many other occasions, using similar offsets as a starting error. The time errors that remained were typically tens of secs after ‘correction’, but the biggest was more like > 150 sec.

Jim

Martin: What version of NetTime and RTC/RTCAdjust do you have? If you’re using NetTime 0.42 or older with the RTC module then there’s a bug which means that large clock corrections (i.e. 1970 → now) won’t get applied properly. NetTime 0.43 fixes that.

Everyone else: The 2 minute threshold is indeed by design. See here for the logic in NetTime or here for the RTC module (which is what will actually perform the clock correction if both RTC+NetTime are running). In both cases the correction offsets are expressed as fixed point numbers and the (perhaps arbitrarily chosen) thresholds happen to be +/-127 seconds.

Sprow: Unless I’m mistaken, won’t RTC_Adjust only correct the hardware RTC if a large correction offset is being applied? For small offsets it’ll fiddle with the system timer so that the soft clock will drift towards the correct time but it doesn’t seem to update the hardware RTC. It looks like NetTime will attempt to correct the hardware in a few places (e.g. on shutdown), so as they are things should be working OK, but it would probably make more sense if the RTC module applied this fixup itself.