NetTime has no effect on bootup

I was tempted to ask for a pointer to an idiot’s guide to amu.

!Amu seems to accept the industry standard Makefiles. It even converts the unix format filenames for you.
(e.g. jim.o to o.jim).
You should be able to find loads of info on the interweb thingy.

Jeff

Don’t know what the conditions are for the ‘EUPL’.

It’s like GPL without the bull – so hack, fiddle, and share.

https://joinup.ec.europa.eu/software/page/eupl/licence-eupl

Simple PDFs. Pick a language. ;-)

Amu seems to accept the industry standard Makefiles.

That may be so, but I don’t understand them, either. 8-]

It’s like GPL without the bull – so hack, fiddle, and share.

OK. :-)

Jim

I’m hoping to produce a simple program that will get the ‘net’ time, and compare it
with the ‘local’ time. Then offer to set the clock if they differ. All via a TaskWindow.
Not yet looked at how to handle timezones. I’ll be pleased if I can just do that, automated
to cope with BST/GMT!

Good idea.

Good grief – have you read what is in Capp?

No, but I thought I would try it out anyway. Not being a C expert of any sort I have got as far as discovering !Make is now regarded as somewhat yesterday and these new Makefiles are quite the modern way. The makefile below uses Capp and does build JimTime.

# Makefile for JimTime

COMPONENT = JimTime
CINCLUDES = -ITCPIPLibs:,C:

LIBS      =  TCPIPLibs:o.Socklib ${INETLIB} ${UNIXLIB}

include CApp
C_WARNINGS = -Wp

# Dynamic dependencies:

The one oddity was that LIBS refused to accept {SOCKLIB}, it was ignored.

!Locate to the rescue which found the file AcornC/C++.Makefiles.AppLibs which contains no definition for SOCKLIB but does contain the following :-

SOCK4LIB  = TCPIPLibs:o.socklib
SOCK5LIB  = TCPIPLibs:o.socklib5

LIBS = ${SOCK4LIB} ${INETLIB} ${UNIXLIB} works.

Have I found a bug or just an anomaly?

Have I found a bug or just an anomaly?

I have a vague recollection that something changed in the stack; so maybe it was changed to require version 4 or 5 to be specified.

With just a little more digging :-

NET4LIBS  = ${UNIXLIB} ${INETLIB} ${SOCK4LIB}
NET5LIBS  = ${UNIXLIB} ${INETLIB} ${SOCK5LIB}

Assuming the ‘5’ variant is the one to use then the LIBS line can be simplified :-

LIBS      =  ${NET5LIBS}

JimTime compiles and runs.

FWIW I’ve now combined Rick’s code with some that reads the realtime local clock and works out how much they differ. I’m using the Territory swis for reading the local time and the zone and offset, so may eventually also be able to take that into account. But at present I’m focussed on GMT/UT.

Rick’s code waits 1 sec. I find I have to make that 2 or more as otherwise it gets no response in time fairly often. The downside is a greater error due to the wait when it responded quickly. So I may experiment with looping this until it gets a coconut or goes beyond, say, 5 sec. Not tried it yet, though, so I don’t know if it will work. But if it does, the loop delay could be less than a sec to get more accuracy.

However I doubt the results will be accurate to more than a second or two anyway. So may just let it run once for two sec. Then subtract a second from the difference to split it. :-)

As a result I hope to get an initial program that can set the clock if it is off by more than a couple of seconds. But only accurate to a second or so.

Until I get a chance to experiment with zone effects I’ll probably limit the program to just offering to set the time when the error is less than an hour and more than, say, 2 sec.

Must admit I’ve been confused a few times by the PRMs on the various ‘formats’ and ‘clocks’ on the machine. Some swis use 5-byte time, but others mention 7-byte, plus all the various string formats and ordinal representations. Maybe its me, but at present it seems a bit haphazard and I have to convert via one form into another into another.

Jim

Until I get a chance to experiment with zone effects I’ll probably limit the program to just offering to set the time when the error is less than an hour and more than, say, 2 sec.

So that you know where you’re aiming – NTP is supposed to work on the basis of making the system take a large step if the reference time and the system time differ by a large amount and only use the slew method of micro adjustments when the two a close but not identical so if you produce an offer to sync to within a few seconds when the difference is large you are following the correct path.
In the slew phase it over adjusts and then under adjusts alternately – fading pendulum style never quite hitting zero adjustment.

I’m using the Territory swis for reading the local time and the zone and offset, so may eventually also be able to take that into account. But at present I’m focussed on GMT/UT.

You don’t need to take it much into account – Territory can tell you UTC, local, the difference, and if DST is in use on a given date. Just combine the right calls at the right time…

Rick’s code waits 1 sec. I find I have to make that 2 or more as otherwise it gets no response in time fairly often.

Hmmm… My original code specified two seconds, but it always responded for me when the delay was one second.

Here’s something you can do:

   returncode = socketread(handle, &buffer, 32);

The returncode is a count of how many bytes have been read. So you can replace that line with something like:

[pseudocode!]

timevar = timenow() + 500; // five seconds
do
{
   returncode = socketread(handle, &buffer, 32);
} while ( (returncode == 0) & (timevar < timenow()) );

In order words, you’ll just keep calling socketread() until a timeout happens or some data turns up. You may need to check the result to ensure that all of the data has arrived, but since it’s like 40 bytes or so, it shouldn’t come in bits. See how you get on in real life use.

However I doubt the results will be accurate to more than a second or two anyway.

That ought to be sufficient. After all, the FAT filesystem is only accurate to two seconds and uses local times (brilliant in DST changes) but it served PC users… well, it still does. FAT32 can record file times to milliseconds, but any accuracy more than the old 2-sec way is “optional”. ;-)

Must admit I’ve been confused a few times by the PRMs on the various ‘formats’ and ‘clocks’ on the machine. Some swis use 5-byte time, but others mention 7-byte, plus all the various string formats and ordinal representations. Maybe its me, but at present it seems a bit haphazard and I have to convert via one form into another into another.

Let’s start with the clocks and timers. There are four (!).

1. The monotonic timer. This counts centiseconds since the machine was booted, and it cannot be reset by the user. It is a 32 bit word (so can run for about a year and a half before wrap-around). You can read it with the SWI OS_ReadMonotonicTime.
2. The system clock. This (stored as a five byte value) is a count of centiseconds since the machine was booted. While it is essentially the same as the monotonic timer, the bit difference is that it can be reset.
3. The interval timer, (yet) another centisecond clock that can cause an event when it rolls around to zero (so to count five seconds, you’d set it to -500). It is for compatibility with Arthur. Maybe even the Master MOS. Don’t worry about it.
4. The real time clock. Stored as a five byte value (centiseconds since 1900/01/01 00h00.00), this provides a soft copy of the time as understood by RISC OS. It is periodically synced with the hardware RTC, and modules such as NetTime (these days) and RTCAdjust (mesolithic era) can “slew” the upate rates to guide the clock to correctness. All calls to read the “CMOS clock” (as the PRMs call it) will return the soft copy maintained by RISC OS.

Something you might not have known but do now:

Boot to the desktop. Open a TaskWindow…

*BASIC
ARM BBC BASIC V (C) Acorn 1989

Starting with 651516 bytes free

>SYS "OS_ReadMonotonicTime" TO t% : PRINT t%, TIME
      3784      3784
>TIME = 1234
>SYS "OS_ReadMonotonicTime" TO t% : PRINT t%, TIME
      5423      1361
>

Yup, they’re not the same ticker, though both run at 100Hz.

BTW, setting the system clock is an obnoxious thing to do in a multitasking world. It belongs in the epoch where games and such would unplug every module in sight to gain a few extra kilobytes. [annoyingly common in the days of RISC OS 2, leaving you to sort out the mess if the software crashes and doesn’t restore your machine]

Now for the time formats:

1. String format, generally in the style “Tue,16 Dec 2014.22:08:00”, but may vary slightly depending on system (Territory) language.
2. Five byte format, as mentioned above, it is the standard time format of RISC OS and is the count of centiseconds since Jan 1st 1900 (at midnight). It doesn’t take leap seconds into account, so in theory the clock’s idea of seconds since 1900 will be 25 seconds out from reality, but since we can set the clock to the current time, it’s not really worth worrying about. [Linux didn’t do so well either – just Google “leap second linux” and see what went wrong in 2012]
3. Seven byte format – IGNORE THIS. The NVRAM used in the original Archimedes (and hardware of its ilk) actually store the internal time in BCD form. There are calls to work in BCD, but just stick to five-byte and ignore BCD entirely. I have since 1988 and it hasn’t done me any harm. ;-)
4. Ordinals – the time expressed as nine words which are as follows: +0 = centiseconds, +4 seconds, +8 minutes, +12 hours (24h), +16 day of month, +20 month, +24 year (with century), +28 day of week, +32 day of year. In general, when giving a time, only the first 7 words need to be provided (RISC OS doesn’t expect you to calculate the week/year days), but when RISC OS provides ordinals, those fields will be calculated for you.
   Note that the “7 word format” is not the same as the previously mentioned 7 byte format.

Generally, for what you are doing, you will want to provide Territory_ConvertTimeFormats with UTC ordinals (because it is dead easy to parse the string and shove numbers into the right parts of the ordinals buffer) and receive back a UTC five-byte time. You can then, if you want, give the UTC five byte value to Territory_SetTime.
Do not use OS_Word to set the CMOS clock. For some mind-numbing reason, it wasn’t until RISC OS 4.something that OS_Word would become capable of setting the clock from a five-byte value. Instead, it accepted strings. WTF, Acorn?

Just… Use Territory Manager. I’m not sure if time and date are really something in Territory’s remit, but it does a good job so I’ll recommend it.

Maybe its me, but at present it seems a bit haphazard and I have to convert via one form into another into another.

Well, you can, if you wish, parse the input string and construct your own count of centiseconds since 1970.
Between you and me, I think a few calls to atoi() and poking values into an int array is a lot easier. ;-)

Hope this helps.

So that you know where you’re aiming – NTP is supposed to work on the basis of making the system take a large step if the reference time and the system time differ by a large amount and only use the slew method of…

My approach has to be very simple. In effect at present it will be:

If the time ‘offset’ is more than 1 (or 2) seconds it will ask the user if they want the time to be set. That will then simply alter the time by the determined offset. However if the offset it bigger than, say, an hour, it may warn that the error may be due to a zone problem. (This is because I may not be able to suss and test this properly initially.)

I’m not going to make any attempt to regulate the clock (i.e. not change any clock rates). Just set the clock (i.e. alter the ‘current time’). For situations like my own, regulation that only works on the ‘soft clock’ until a power down is wasted effort. And by set, initially I’m just concerned with the time-of-day for simplicity. Once I can ensure I can handle zones I could then widen this to the entire time.

Rick: Thanks for the suggested mod to the looping, etc. I’ll have a go at incorporating that. Its clevered than the way I’d aimed to try as I didn’t know how the buffer could be checked. Indeed, I wasn’t certain that even trying to check might not be distructive!

Thanks also for the tips and info. I was baffled by the 7-byte mention in the PRMs when everything else is 5-byte, Ordinal, etc. I was going to ignore it out of ignorance, but had a nagging feeling that might bite me.

I’ve not checked yet but IIUC the 5-byte time is equivalent to the 5 smallest bytes of a 64bit int that counts the monotonic time from the reference start instant. I can’t help wishing they’d just adopted a such an int from the start of RO. But I guess back then BASIC was more relevant than ‘C’. 8-]

Jim

I’ve not checked yet but IIUC the 5-byte time is equivalent to the 5 smallest bytes of a 64bit int that counts the monotonic time from the reference start instant.

Just checked and this seems fine. I can convert the 5-byte values into a time in cs OK. Since I’m currently just wanting to ‘set the time of day’ I can then adjust that by the offset between net and local time-of-day, then write the new 5-byte value to ‘correctly’ set the clock with an accuracy of a second or two.

Jim

I now have a program that seems to work here if I have my machine’s clock set to either GMT or BST (via the ‘BST’ flag). I need to test it a bit more and tweak a little. Then I’ll make a copy available in case anyone else wants to test it.

Please note, though, that I have kept the program to just ‘checking and fixing the time of day’. So it assumes you already have to correct day and date set. The aim of the program is to just make slight adjustments of the clock in terms of mins/secs to counter the drifts we get from day to day because the RTC isn’t running at exactly the correct rate.

It also works via a TaskWindow and asking the user to choose if to set the clock or not having listed and compared the nist time with the local clock’s UTC. This to let the user avoid messing up their clock if the program gets it wrong. (Should the program turn out to be useful and reliable it will be easy enough to have a ‘just do it’ mode so simply running the program sets the clock without any user interactions. But I’m not that confident as things stand! More checks and work to do.)

Jim

OK, for anyone whose stomach and nerves are up to it, I’ve put a copy of my current program here

http://jcgl.orpheusweb.co.uk/temp/JimTime.zip

It ‘mostly works’ here. But I’m sure there are still problems. It works here if I set DST or not. Occasionally earlier versions would fail in various ways. Not yet sure if I’ve fixed that entirely, but it has been OK during recent tests. Use at your own risk. :-)

I’ve deliberately named the application SetTimeOfDay to make plain that it won’t handle errors in the day and date. Its just to fix offsets of some mins or secs that can accumulate if the RTC hasn’t been corrected for a while.

Please read the included !Help before use. If nothing else that should reduce any sense of dissapointment when you try the program. ;→

Jim

Martin’s problem was caused by the fact that the system variable Inet$NTPServer had not been set at the time that the NetTime module was loaded (nor at the time of his *NetTime_Kick command). I believe this variable was being set after !Boot had completed, but I didn’t bother investigating further.

The NetTime module can’t set the real-time clock if it doesn’t know which server to query – it’s as simple as that. It always fetches the current time when it is loaded, so a *NetTime_Kick command should be superfluous unless Inet$NTPServer is set after loading the module.

I solved the problem by inserting commands to set Inet$NTPServer and *RMEnsure NetTime 0.0 RMLoad NetTime in an Obey file which contains additional Internet configuration commands set by the user, which is run during the pre-desktop part of the boot sequence. This is where I’d expected Internet configuration to occur. (This Obey file is also accessible through the Configure application plug-in for Internet configuration.)

I don’t know why the TimeSetup plug-in (or whatever it’s called) stores an Obey file to be run as a task after entering the desktop rather than as part of the predesktop boot. I didn’t modify the TimeSetup Obey file, so it still does *RMEnsure NetTime (which now has no effect, since the module has already been loaded) and sets the interval between NTP queries.

Christopher

In the last week or two I’ve seen various comments on usenet, etc, to the effect that “something seems to have changed” wrt fetching net time. Along with this the program I wrote in 2014 – based on Rick’s fetching code – also has ceased working.

The program in question is still available zipped from

http://jcgl.orpheusweb.co.uk/temp/JimTime.zip

However when I run it on my ARMX6 now, it freezes the machine. Almost nothing works, and even the caret ceases to flash. f12 ignored, etc. Although the mouse pointer still works. I have to do a power cycle to get a working machine.

Discussion on usenet did briefly indicate that setting a larger buffer worked. I tried this, but it worked once, then never again. So I am left with the impression that – purely by luck – it still sometimes works. But almost always stiffs.

Rick, can you or someone else help me with this? I don’t understand the details of the time fetching and socket use. I’m just using your code to get a value I then can compare with the local clock, and then adjust it.

BTW Sorry I’ve not visited the forum for ages. Been doing other things. Mainly building a (large) new website at

http://www.torrens.org.uk/ukhhsoc/AudioDocs.html

which may interest those into hifi, etc. :-)
It currently has just under 3 GB of files, and is growing as fast as I can add things!

I’ve not visited this forum for so long that I’d forgotten my password and had to set a new one!

Thanks

Jim

I’ve seen this many times, in fact I removed NetTime from all my machines back in 2013 when I first tracked it down as the cause of machine locks.

Memory is a bit vague, but I believe the lockup occurs when NetTime fails to connect to the time server, possibly due to a failed DNS lookup.

IIUC Rick’s code is supposed to time out after waiting 5 sec. It has done this OK in the past. But not now. Note that the code he wrote and I’m using isn’t the same as used in other time-fetching user software.

The puzzle is why it has worked fine for years. But now falls over almost every time I try it.

I’ve seen this many times, in fact I removed NetTime from all my machines back in 2013 when I first tracked it down as the cause of machine locks.

The thread referred to is commenting on an A4000 though, which runs RISC OS 3.00 (or maybe 3.10), so the conclusion is nonsense based on that particular observation. NetTime is in !System.360.Modules.Network so wouldn’t be visible on an A4000 and the configure plugin used to enable it RMEnsures RISC OS 3.60 too, so wouldn’t run on an A4000 either.