NetTime has no effect on bootup

I’m using NetTime 0.43 here. I just tried using it again via the !Alarm ‘try’ interface. I used ‘try’ twice and checked in a taskwindow to get the results shown below.

*nettime
File 'nettime' not found
*help nettime
==> Help on keyword NetTime
Module is: NetTime         0.43 (28 Nov 2013)

Commands provided:
NetTime_Kick    NetTime_Status  NetTime_PollInterval
*nettime_status
Current time:    Tuesday, 12 August 2014 12:55:29.60
Status:          Sleeping
Last adjustment: 35 seconds ago
Last delta:      124.341981 seconds slow
Last server:     ntp1.exa-networks.co.uk
Last protocol:   SNTP
Poll interval:   30 minutes
*nettime_status
Current time:    Tuesday, 12 August 2014 12:55:45.06
Status:          Sleeping
Last adjustment: 5 seconds ago
Last delta:      123.436941 seconds slow
Last server:     pool.ntp.org
Last protocol:   SNTP
Poll interval:   30 minutes

Showing a residual error of over 2 mins. Which I think was pretty much the error before I did the first try.

Jim

Ah! I think I may have twigged the nature of the problem.

The first factor is the need for the time to be out by > 127 sec before the clock is set (which seems a crazily long time to me TBH).

The second is that – using !Alarm to illustrate – you have to use both ‘try’ and ‘set’ to get the time setting to function. This leaves the nettime module running and active. But if you don’t want nettime running in the background you’re then faced with having to use !Alarm again to “set manually” and then “set”.

That means that to stop using nettime you have to manually reset the clock. To make things worse, the !Alarm values are just shown in hours and mins. No seconds. So it is a challenge to set this again without generating a multi-sec error unless you have the clock showing the time inc secs and time your use of “set manually” and “set” to match as exactly as you can.

Which makes this look like a user interface difficulty for mere users who want to set the time accurately once but not have nettime running in the background.

Jim

the need for the time to be out by > 127 sec before the clock is set (which seems a crazily long time to me TBH).

Me too. My suggested threshold is 5 seconds. Maybe even less.

If the time is within the threshold, and thus the time is not corrected instantly, I’d like to see some kind of comforting message come up to say that it has done something, really it has, and that we shouldn’t panic.

There really is no excuse for the time to be so far out. Don’t blame drift until you’ve put a reasonable tolerance on the clock’s timebase (50 parts per million would be awful; realistically it should be much closer than that) and calculated how far it can drift between synchronisations, e.g. almost 24 hours of the host not being switched on.

My watch cost £9.99 new, and it drifts less than 1 second per month. The technology is the same.

My suggested threshold is 5 seconds. Maybe even less.

To me, 1 sec would be a good figure. However I don’t know enough about the processes NetTime involves to know what kind of value would be feasible. And something around 5 sec seems fine as a reasonable compromise for most desktop users.

However I confess I have the feeling that NetTime may fall between two stools.

On one hand:I can’t see that most ordinary desktop users will care enough to want the clock rate tweaked. Whereas I can see that can have drawbacks for some users.

On the other hand: A process that cheerfully leaves many seconds of offset seems unsatisfactory for precision users – particularly as NetTime itself gives no warning or says “If you want the time set, deliberately make it wrong by many mins before using NetTime!”

And the third leg of the stool: Precison users may well not want the clock rate or time altered without knowing exactly what changes were made, and when, and what the rate/time values were beforehand. We get a ‘delta’ for the time change. But no info on the rates. And the ‘delta’ doesn’t help much if the actual error remains many secs but below 127 secs.

People who may want to use the computer for precision processes that have to issue control signals or capture values in a well-defined and regular way may be confused by an automatic application. Whereas most ‘ordinary’ users simply may not have any need for the clock rate to be tweaked.

I managed (I think!) to set my computer’s time to a sec or so by using NetTime, and maintained this after NetTime was no longer selected. But this is tricky as !Alarm and the !Boot time config only show the manual value in hh mm, not ss. So takes a carefully judged ‘manual’ time set to coincide to a second or two.

And I still don’t even know if RTC rate tweaks persist over a powerdown-reboot cycle. Without being to monitor this I don’t know if that would make things worse or better! :-/

Nor do I know how large these tweaks are.

Personally I have the feeling that NetTime is trying to be too clever for a general purpose method. It would be far simpler and more sensible IMHO to just have a “once at bootup” process that sets the clock and then doesn’t leave any module or process to tweak or re-check. And any attempt to tweak the clock rate should only do so on the basis of having the user see the start and end times, etc, in a user-chosen calibration.

Having got the time about right I think I’ll avoid NetTime and leave it to others. Maybe I’ll need how to test and calibrate the RTC if my trying it has made the clock run faster/slower than before. Until then I think I’ll just use wget to check the time from the US Navy server (until I find a suitable NPL equivalent) as that avoids me having to learn about the fancy protocols. :-)

BTW The main start-point of this for me was asking about documentation for NetTime. The response has been in effect the sadly predictable “the code is the documentation”. Which actually doesn’t help me or most mere users. And was no help when I kept getting problems and nothing others said showed why.

In user interface terms, one problem here is the way the user of ‘radio’ buttons in !Alarm and the !Boot interface force the user to reset the time ‘manually’ just to get NetTime to stop doing so. Given the hh:mm interface that can mean screwing up the time unless you take other steps. There should be a choice of “neither” that will stop NetTime being used without beg forced to set the time again from a manual value you can’t even specify better than a minute.

Another problem is that “try” may say “synch successful” but this doesn’t seem to mean the clock has been set! You apparently have to click “set” for that. The interface doesn’t make this clear. I was confused by this for a long period as I assumed that “synch successful” meant the clock was being set. And by using “try” for NetTime and then closing without a “set” I’d set the clock without having NetTime continue from then on. As it is, the interface seems to assume no-one will want to use NetTime just to set the time as a one-off user chosen event. However that’s what I want, and I wonder if others have been tripped up by this.

Jim

There is no way to alter the timebase of the RTC hardware. Ergo, its rate can’t be changed when the host isn’t running. Even when the host is running, all that can be altered is a soft copy of the time.

When you have done that, you have bought and opened a can of worms. Two different versions of the time on the same host, with the relationship between them deliberately concealed from the user, and the ability to set the time (whatever that means) severely limited.

It’s an attempt to be too clever for its own good. It ends up looking stupid.

There is no way to alter the timebase of the RTC hardware. Ergo, its rate can’t be changed when the host isn’t running. Even when the host is running, all that can be altered is a soft copy of the time.

OK, so that means I don’t have to worry that I’ve changed the clock rate in an enduring way.

But from what you say, that using NetTime means in effect that the user-facing clock will be running at a rate different to the hardware RTC during a session.

I wish I understood the time protocols, etc. If I did, I’d write a modern equivalent of !FreeTime. As it is, if no-one else does so, I may hack something together using wget and a suitable clock source to let the user see a ‘net time’ and set their computer clock if they wish from it. At present I’m doing this via seeing the results wget shows in a taskwindow and comparing it with my local computer clock. Not elegant programming, but at least under user control. :-)

Jim

Could we compromise?

I can understand the idea of gradually shifting the system time so as not to freak out applications that make use of the clock and would handle a sudden change badly…

…but this makes absolutely no sense at all if/when the time is seen to be incorrect at boot up. No matter how clever NetTime thinks it is, there is no possible way that it can speed up or slow down the system ticker by any meaningful way from boot up because there is no previous value to record so it won’t be capable of detecting if the clock is running quickly or slowly.

By the way, where do we get “the system time is 0.0004857273 milliseconds slow” from a timer with centisecond resolution?

Anyway – we need a compromise. We either need NetTime to absolutely forcibly set the real time is the system uptime is less than 30 seconds, or – better – to have a “-force” parameter to NetTime_Kick that will do this. Let the user decide, instead of pretending to provide a service and then failing to do so over a concern that some unspecified entity might be upset by it. Because, trust me, a fed up user adjusting Sys$Time manually is going to be just as jarring to said piece of software…

When discussing it with sprow, apparently cmos is used to store time from session to session so that at cold boot, it’ll immediately restore the clock to the last stored time, before attempting any kind of time sync-ing. I guess this should avoid the whole 1970 issue, provided NetTime has been used previously.

Internet time is then checked for a reference point, and the clock is then jumped forwards, or gently adjusted, depending on the result.

I’d also be inclined to think that 2 minutes (127 sec) is a little on the large size – 31 seconds or even 15 would seem a suitable power of 2. That said, there may be an issue at play here such as the time it takes for a TCP/IP timeout that affects this choice. I don’t know who designed this in the first place, so I can’t comment on the logic.

Booted my Pi from a day switched off (was out) and it has brought the time to correct and retained the CEST timezone. :-)

*NetTime_Status
Current time:    Tuesday, 12 August 2014 22:23:21.20
Status:          Sleeping
Last adjustment: 45 minutes 34 seconds ago
Last delta:      0.063989 seconds fast
Last server:     md.neolane.net
Last protocol:   SNTP
Poll interval:   1 hour
*

md.neolane.net? Never seen that before.
It’s a site in French – “Adobe Campaign” – run by “Adobe Systems Software Ireland Ltd.” according to the copyright.

[update: <to self>look at your browser’s URL bar, stupid!</> :-) it redirects to http://www.adobe.com/fr/solutions/campaign-management.html]

I wonder where it got that address from? Especially given as NetTime$Server says pool.ntp.org !?

There is no way to alter the timebase of the RTC hardware. Ergo, its rate can’t be changed when the host isn’t running. Even when the host is running, all that can be altered is a soft copy of the time.

When you have done that, you have bought and opened a can of worms. Two different versions of the time on the same host, with the relationship between them deliberately concealed from the user, and the ability to set the time (whatever that means) severely limited.

It’s an attempt to be too clever for its own good. It ends up looking stupid.

Not really.

Since RISC OS 2, I’m not aware that there’s been a way for applications to read the hardware clock: according to the PRMs all the OS_Word calls just read the “soft” copy of the clock. The soft copy is synced from the RTC (if present) on a reset, and after that it runs independently. Pre-NetTime, ISTR that the soft-copy would deviate from reality at quite a large rate with no control. Now it may also deviate, but in line with real time.

I wonder where it got that address from? Especially given as NetTime$Server says pool.ntp.org !?

The ntp.org pool will just point you at one of their members’ servers, depending on your location, what subdomain (if any) you specify, and how loaded they are. My local timeserver (to which I point NetTime) is currently looking at the following as a result of being configured to pool.ntp.org.

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+secure.serverbo 195.66.241.3     2 u  678 1024  377   35.045   -0.609   0.332
-nice.stuff.is   210.100.177.101  2 u  536 1024  377   34.185   -2.466   0.477
*ns1.c-it.co     195.66.241.10    2 u  869 1024  377   35.205    0.464   0.339
+time.videxio.ne 131.188.3.223    2 u  614 1024  377   34.395   -0.500   0.305

It would be far simpler and more sensible IMHO to just have a “once at bootup” process that sets the clock and then doesn’t leave any module or process to tweak or re-check.

Not for me. Setting the time at boot only means that you know the clock was correct then, but doesn’t tell you anything about where it is after a couple of hours at the mercy of the “soft”-clock’s timekeeping. As soon as machines start to be networked together, keeping their clocks in step becomes more useful than not.

BTW The main start-point of this for me was asking about documentation for NetTime. The response has been in effect the sadly predictable “the code is the documentation”. Which actually doesn’t help me or most mere users. And was no help when I kept getting problems and nothing others said showed why.

I seem to recall pointing you at the documentation?

I seem to recall pointing you at the documentation?

I seem to only recall you pointing me at source code.

If NetTime suits you now, fine for you. But it seems quite clear from this thread that I’m not the only person who thinks the current setup needs changing.

And if your concern is that machines on a local network need synching together, then I suspect that would be better done by synching them together. Not by having each one fetch seperately at different times from a distant ‘pool’. If precise synching is needed, then it is the machines that need synching together that should be synched together as directly as possible. Not by using randomly different distant references via connections whose relay delays also vary uncontrollably.

And of course none of the above changes what I said wrt the user presentation and interface. e.g. the problem of keeping a decent set time when you want to stop using NetTime via the current GUI.

Jim

Steve Fryatt has said most of what others have missed. As ever, it’s worth considering the full range of use cases, not just the one presented on the thing in the box in front of you.

Case 1: There’s no RTC hardware at all. You’ll be solely running on the soft clock incremented at 100Hz from some timer or other, which is initialised to 1970 (however, the Pi uses the last shutdown time instead by poking this value over a magic location in the ROM image, yuck!).

Case 2: There’s no RTC hardware, and NetTime is enabled. The soft clock is initialised to 1970 until NetTime can get a reply from the time server.

Case 3: There is RTC hardware. The kernel reads this after all the modules have started (effectively, doing an OS_ResyncTime) then leaves RTCAdjust to slew the soft clock by changing the ticker rate. The adjuster reads the hardware clock hourly and recalculates the adjustment needed with a simple control loop. The RTCAdjust module has been in RISC OS since 1989 so if you’ve use RISC OS in the last 25 years your clock has been slewed and you’ve just never noticed! The adjustment is needed because the RTC hardware is assumed vastly more accurate than the 100Hz timer, either because it’s skipping a count when interrupts are disabled or because the crystal or PLL running the 100Hz timer is terrible. For reference, a really bad RTC crystal has ~30ppm initial accuracy (not accounting for ageing and temperature). Additionally, some RTC chips don’t have a full 4 digit year, so any missing digits are augmented by a value held in the year CMOS locations – eg. the Risc PC has a 2 bit year, and gets the other 14 bits this way.

Case 4: There is RTC hardware, and NetTime is enabled. As with (3), the soft clock is initialised from the hardware RTC first and slewing will begin. NetTime may then get an update from the time server and will try to slew the soft clock too (subject to some priority rules, since there are now 3 views of the time to contend with).

Historically, as RTCAdjust had to contain a second copy of a (read only) RTC driver this meant it kept having to be updated each time a new HAL came along with another clock chip. More recently been replaced by the RTC module instead which just asks the HAL.

My watch cost £9.99 new, and it drifts less than 1 second per month.

You’re very lucky, that’s 0.4ppm.

By the way, where do we get “the system time is 0.0004857273 milliseconds slow” from a timer with centisecond resolution?

Because the centisecond timer has always been derived from a clock of at least 1MHz, even on the BBC Micro. More recent platforms improve on this with 10’s MHz ticks divided down to 1cs.

BTW The main start-point of this for me was asking about documentation for NetTime. The response has been in effect the sadly predictable “the code is the documentation”.

I seem to recall pointing you at the documentation?

Sprow: Unless I’m mistaken, won’t RTC_Adjust only correct the hardware RTC if a large correction offset is being applied?

Yes, a step change in time is the last resort, when outside 163.84s error I think. Slewing can be up to ~1% which is 10000ppm (contrast that with the crystal accuracy above). Over 1h you’d catch up 36s. To ever accumulate 163s of error in the first place the RTC would have to have been at the extreme of its 30ppm range for over 2 months, so in practice the error on power up will be trimmed out in much less than 1h.
Don’t get hung up on “my threshold’s bigger than yours”, it’s a figure of merit to decide whether the time can be slewed back in a sensible amount of time or not.

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.

I don’t think so. The RTC hardware is assumed king so RTCAdjust never wrote to the clock. NetTime did (and still does) but only on Service_PreReset.

Without wanting to get too philosophical, when you manually set the time, how long is the time from your eyeballs seeing the number on your watch (or hearing the pip of the speaking clock) and pressing a mouse button. Does the time apply when you press or release the mouse button? Have you accounted for the time taken to write or remove any configuration file, plus the IIC transaction to the chip, and the time take to convert the string into the 40b counter? I’d take anyone claiming their PC clock is more accurate than 1s is just kidding.

There is no way to alter the timebase of the RTC hardware.

Not necessarily; the RTC used with OMAP3 machines allows you to fine-tune the clock rate. Which is just as well, considering that the RTC’s accuracy is pretty abysmal.

It’s a feature that we’re not using at the moment, but it would probably make sense to add it to the RTC module.

No matter how clever NetTime thinks it is, there is no possible way that it can speed up or slow down the system ticker by any meaningful way from boot up because there is no previous value to record so it won’t be capable of detecting if the clock is running quickly or slowly.

True. On startup NetTime can easily determine whether the hardware RTC has suffered any clock drift and can adjust the frequency of the soft clock in order to gently fix that drift (plus reset the hardware RTC). But once that drift has been corrected it should reset the soft clock frequency to default because it doesn’t yet have enough data to make any assumptions about the accuracy of the soft clock.

By the way, where do we get “the system time is 0.0004857273 milliseconds slow” from a timer with centisecond resolution?

Because on all platforms the RISC OS centisecond timer is derived from a timer running at 1MHz or greater. HAL calls allow the code to peek at the value of the timer and so get a result that’s accurate to within about a microsecond.

Unfortunately hardware RTCs generally only expose the time accurate to the nearest second or centisecond, so making the hardware RTC sync precisely with network time is a bit trickier (Wait for the soft clock to roll over to the next second and then reprogram the hardware RTC?)

Anyway – we need a compromise. We either need NetTime to absolutely forcibly set the real time is the system uptime is less than 30 seconds, or – better – to have a “-force” parameter to NetTime_Kick that will do this. Let the user decide, instead of pretending to provide a service and then failing to do so over a concern that some unspecified entity might be upset by it.

Yes, it looks like making some changes would be best. It’s probably worth checking what thresholds Linux and BSD use for their RTC adjustments, as I suspect they’re much better at this kind of thing than we are.

FWIW the NetTime spec mentions that of the two NTP methods supported, Time Protocol only give the time with an accuracy of one second, and NTP results are typically accurate to within 1-50ms.

This post included a link to the NetTime spec, all 2030 words of it.

I assume that page may make sense to experience programmers working on the topic. But I’m afraid that to me it doesn’t look much like a page of user documentation explaining how to use NetTime, etc, avoiding the snags I’ve described.

And if you’re ever going to add the ability to genuinely alter the RTC clock rate in a way that persists over power down-up cycles I’d strongly recommend ensuring this also make a user-readable record in a file somewhere of what the before/after rates were and when they were changed. Otherwise you could be causing real problems for some kinds of precision-timed real-world processes.

Jim

Otherwise you could be causing real problems for some kinds of precision-timed real-world processes.

Surely you’d want to log the values regardless of whether the RTC is being adjusted? If you aren’t adjusting the RTC then the RTC will continue to drift further and further out of sync, and without a log file listing RTC time vs. a reliable time source you won’t have a clue how far out of sync it was at any point in time. For all you know it could run 10x faster than normal for a week, then run at normal speed for a week, then run backwards for a week, and then jump forwards 10 years due to a bug in the OS.

I seem to recall pointing you at the documentation?

I seem to only recall you pointing me at source code.

I remember the following exchange:

> > I looked on the ROOL site and saw sources. But not any real
> > documentation on the details of how it works.

> What about

> https://
> <a href="http://www.riscosopen.org">www.riscosopen.org</a>
> /viewer/view/castle/RiscOS/
> Sources/Networking/NetTime/Doc/Spec%2Cfaf

> That seems fairly detailed on what NetTime is, and how it does its
> stuff. It's HTML in CVS, so you might need to download it and then load
> it into your browser (as the web interface helpfully escapes all of the
> tags so that you can read them in all their glory).

Thanks.

Jim

If NetTime suits you now, fine for you. But it seems quite clear from this thread that I’m not the only person who thinks the current setup needs changing.

I think Sprow covers most of the issues above. In short: It’s A Bit More Complicated Than That, and always has been even though no-one seems to have been worried until now.

And if your concern is that machines on a local network need synching together, then I suspect that would be better done by synching them together. Not by having each one fetch seperately at different times from a distant ‘pool’. If precise synching is needed, then it is the machines that need synching together that should be synched together as directly as possible. Not by using randomly different distant references via connections whose relay delays also vary uncontrollably.

I do, thanks. NetTime syncs with a local NTP server, which in turn syncs to uk.pool.ntp.org — as I explained above.

@ Sprow:

As ever, it’s worth considering the full range of use cases, not just the one presented on the thing in the box in front of you.

Case 5: The user knows the time is wrong. The module entrusted to rectify the situation intentionally leaves it wrong (only maybe a little less wrong) by design – while providing no obvious indication to the user that the time is not being immediately corrected when the user asks it to be done.

You’re very lucky, that’s 0.4ppm.

I struggle to believe a cheap watch can manage better than one second a month. I have an expensive watch that is maybe that good, got it a long time ago but I don’t wear watches these days.
The clocking in machine at work has….difficulties….in keeping track of reality. So one of the line managers gave me a cheap sports stopwatch thingy to compare against. That’s even worse (five seconds a day when it is hot!) so I use my mobile phone.

Without wanting to get too philosophical, when you manually set the time, how long is the time from your eyeballs seeing the number on your watch (or hearing the pip of the speaking clock) and pressing a mouse button.

Well, by calculating what real time should be from the NetTime offset, and pressing the mouse button slightly ahead of when I wanted to, I managed to get within 0.05s of reality. Is that good enough for you? ;-)
While it’s a fluke more than skill, the important thing is to factor in your own reaction time so you never ever click at the moment you want, you have to anticipate and click just a tiny bit earlier.

and the time take to convert the string into the 40b counter?

Somebody with way too much free time could probably examine the code and give you an answer. However I rather suspect the answer would be out of the resolution that NetTime works in, given the speed ARM processors run these days, and the cache, even predictive execution, and…

I’d take anyone claiming their PC clock is more accurate than 1s is just kidding.

Indeed. Back before I had internet, I used to update my PCs clock from the teletext TSDP. My code didn’t even bother adjusting the time if it was within 10s because with the latencies of satellite transmission, the decoding of teletext, the transfer of data over a parallel port IIC link, the interpretation of the data….it wasn’t worth getting all hung up over a minor discrepancy.

My argument is not “how accurate” the time is (after all, we’re taking it on trust that the network time server is correct), but rather that when explicitly asked to set the “correct” time, the NetTime module would rather fart around doing something complicated instead of just saying “okay, the time at the third meep will be….”.

@ Jeffrey:

Which is just as well, considering that the RTC’s accuracy is pretty abysmal.

I don’t think there is the impetuous to make an accurate RTC these says, as every major operating system in the last decade auto-syncs at least once a day to ensure the clock is correct.

Unfortunately hardware RTCs generally only expose the time accurate to the nearest second or centisecond, so making the hardware RTC sync precisely with network time is a bit trickier

+/- a second is good enough for me. ;-)

For all you know it could run 10x faster than normal for a week, then run at normal speed for a week, then run backwards for a week, and then jump forwards 10 years due to a bug in the OS.

Hey! I know that! A billion years ago, an office I worked in had a “smart office fax” that behaved like that. It used to tickle me that we had to call out the service engineer because it crashed on Feb 29th. So we ended up sending out stuff on March 1st for two days of the year on leap years. It was eventually thrown out (and I stripped it for useful parts) because on 1st January 2000, it reverted to 1980.
The brains of the box? An 8MHz Z80 clone.

I should add, however, that I am currently listening to Dido on a little MP3 player with a clone chip inside which is a Z80 clocked at ~25Mhz hooked to a DSP. The wildly amusing thing? While it has a DSP and some GPIO (memory mapped?) for the buttons, the Z80 core is pretty much a straight Z80 right down to a 64K addressing space. [datasheet]

Aaaaanyway…

@ Jim:

Otherwise you could be causing real problems for some kinds of precision-timed real-world processes.

Before getting two hung up on great accuracy, I would ask two questions:

1, What are these applications that require such accuracy (and are they likely to be using a domestic operating system?)?

And:

2, More importantly, perhaps, is that if time accuracy is required down to centi/milliseconds, how can you be certain that the current time is correct? You can, I would imagine, bounce your request off multiple time servers to try to accumulate all of the differences – but in reality you only have the time as presented by the servers you use. For most grockles and muggles, within a second (or so) is likely to be sufficient. For precision? Well… I would refer you to a GPS receiver that contains custom hardware that depends upon exact timings and may take many minutes to synchronise “from cold”. So if you told me your clock is accurate to a thousandth of a second outside of a laboratory, I would say “prove it”.

I struggle to believe a cheap watch can manage better than one second a month.

It does.

Like the man said, I’m very lucky.

There is a difference between watches and computer RTCs: watches are often trimmed, RTCs rarely are. But in any case, it’s luck. Just because something can be 10 ppm out, it doesn’t mean it will be.

One other small thing: my watch spends two thirds of its time in a temperature controlled environment.

(memory mapped?)

unlikely. The Z80 had IO ports built in to its instruction set e.g. IN A,&20.

The Z80 had IO ports built in to its instruction set e.g. IN A,&20.

Thanks for the clarification. I was one of the unpopular kids with a BBC Micro. The other kids had Z80s inside their machines. ;-) Out of interest, how was the I/O hooked to the processor? Was there an I/O bus or was it somehow within the normal addressing range but with some sort of signal to say “this is I/O”?

Didn’t use my Pi yesterday. Went south of the Loire (we like the Vallet/Clisson area) and since my summer holiday is almost over… Was a lovely bright sunny day and as soon as we crossed the Loire northwards – bang! Clouds, dreary, on-and-off torrential rain. It was kind of galling looking back and seeing blue skies with fluffy clouds and thinking that there might be some truth in the idea that “the weather changes south of the Loire”.

Anyway, power up today and…

*NetTime_Status
Current time:    Thursday, 14 August 2014 14:32:44.17
Status:          Sleeping
Last adjustment: 7 minutes 27 seconds ago
Last delta:      32.045953 seconds slow
Last server:     ntp3.vps.net
Last protocol:   SNTP
Poll interval:   1 hour
*

The last time I looked (11th), I was 0.034867 seconds slow, and now? Half a minute. Yikes. A Kick has reduced this to 16 seconds. I guess the rest would even outin time, only I’m going out shopping so…

Chris @ CJE: Does your RTC board have a way of monitoring the state of the button cell, or do I just need to replace it if the time starts getting inaccurate? I ask this because my PVR, when not plugged in, can run down a button cell in under a month (it is running an MSP430 microcontroller). My Pi is not habitually always-on, so the button cell will be keeping the clock running a lot…

I remember the following exchange

I also remember continuing to point out the absense of user documentation of the kind I kept asking for.
In particular, anything dealing with the issues I’ve since found wrt to various user-intefface problems.

WRT possible problems I can suggest two sorts of examples.

1) For some years I ran a RPC to regularly take samples measuring the gain and phase changes over a 20-30 km
30GHz link to assess weather effects for the old Radcom Agency. This took 40 measurements per sec and regularity was important.
Absolulte time was less important as it was the variations that mattered rather than the precise absolute time
of any changes. The data would have been degraded if the clock rate was being changed at regular intervals by
some other process that didn’t keep a clear record of what it had done.

FWIW I did the above with the RPC running for about a month per chunk, only stopping it briefly to change removable HD for analyis. But during these periods it’s clock seemed
to stay accurate to a sec or so. Which was fine for my purposes for the reasons given
above.

2) Sampling for processes akin to audio where a high rate is used but relies on the computer’s ‘clock’. Again if I want to assess
something like determine the behaviour of some other device’s clocking. In practice these days I can get around this becuase
good USB ADCs/DACs now use their own clocks for the data taking and transfer handling. But not everyone may have
these. Even as an amateur these days I tend to do test rate measurements to better than a ppm. Working for NPL or RA I’d have had to take more care.

The user can, of course, work around possible problems if they know about them. And as a pro I tended to always check things for myself (hence my queries about NetTime). The problem with NetTime
is the absence of clear user documentation on how to use it and what it actually does rather than
what the programmer had in mind without being aware of possible side-effects.

e.g. It really doesn’t help that when you see “synch successful” in fact no synch has actually been applied, for example.

e.g. 2 the difficulty of using the standard GUI for NetTime to stop using NetTime without fouling up the time accuracy.

And WRT Rick’s comments. I have also had "try"s of using NetTime which failed to synch the clock.
And inc. ones that started with an offset of more than 127 sec (I think about 150 sec in one case)
where the clock time did not get set accurately. So I remain suspect of how NetTime operates.
But I can only comment as a user since the source code isn’t decypherable by me, alas. I’m a
user. So approach this as other users may do, assuming that something ‘works’ without knowing
of side-effects or problems until tripped up by them.

Jim

Out of interest, how was the I/O hooked to the processor? Was there an I/O bus or was it somehow within the normal addressing range but with some sort of signal to say “this is I/O”?

I don’t know the specifics of the machine in question, but the Z80 has 64 kiB of memory address space and a separate I/O space, which can be 256 bytes or 64 kiB depending on how you address it. I suspect it was rare for anything Z80-powered to require more than 256 bytes of I/O. The address and data busses were the same; there were different control signals for memory and I/O space.

Been there, done a lot of Z80 assembly language programming, designed a Z80-based embedded control system for an audio test set… and survived…

There is a difference between watches and computer RTCs: watches are often trimmed, RTCs rarely are. But in any case, it’s luck. Just because something can be 10 ppm out, it doesn’t mean it will be.

It is also quite possible that if you’d bought a series of watches made one after another on a single
production line that they’d be much more similar than the spec because the problem is that every xtal
is ‘off’ by the same amount.

FWIW I hadn’t tampered with the setting of my ARMiniX clock until I became curious about NetTime. But
over many months it had seemed to continue to give the ‘right time’. Albeit just looking at hh:mm.

I’ve now set the clock to about a sec wrt the USA Navy clock. I’ll keep an eye on how it does over
some weeks to see what happens. NetTime is not in use here as I do this. But I have no idea
how similar the ARMiniX RTCs may be. Maybe Andrew can comment on that sometime.

BTW apologies for worse-that-usual typing. I keep getting a text window about three screens wide! And I’m afraid I still find a webforum much harder to read, etc, that using !Pluto
for an email list or newsgroup.

Jim