Re: [ARMini-support] Is it possible to get the correct time
- From: Jim Lesurf <jcgl@xxxxxxxxxxxxxxx>
- To: armini-support@xxxxxxxxxxxxx
- Date: Sat, 21 Mar 2015 09:31:15 +0000 (GMT)
In article <366f78a754.Andrew-Pin@xxxxxxxxxxxx>, Andrew Pinder
<Andrew.Pinder@xxxxxxxxxxxxx> wrote:
> In message <54a742b0d9jcgl@xxxxxxxxxxxxxxx> on 20 Mar 2015 Jim Lesurf
> <jcgl@xxxxxxxxxxxxxxx> wrote:
> > In article <54a734e0a8bob@xxxxxxxxxxxxxxxx>, Bob Latham
> > <bob@xxxxxxxxxxxxxxxx> wrote:
> >> Is it possible to set the clock on ARMiniX?
> > Short answer:
> > Yes. :-)
> ISTR that the update to !Clock introduced in RO5.20 gave the ability to
> set time from the network. But the comment in the OP implied that that
> option was selected.
> I'm using RO5.20 on an ARMini, with the server set to pool.ntp.org The
> current discrepancy is 0.702530 seconds fast, with 30 minutes between
> checks. Good enough for my purposes, though I think Jim previously had
> concerns related to timing audio.
No, that isn't the major issue.
My main concern with the 'standard' method applied with the OS is that it
tends to *regulate* the clock not *set* it. It takes for granted that the
machine is almost 'always on'. I found - as Bob seems to have done - that
even time errors of over 2 mins were often *not* corrected by setting the
clock.
A contributory problem is that it doesn't explain this to the user and
simply presents itself as a way to set the clock. The terms 'set' and
'regulate' have quite different meanings when it comes to clock
adjustments.
As a result some users find that, despite using it regularly, their
machine's clock remains in error by rather more than a second or so.
Indeed, maybe over a minute. Which seems absurd to me.
For people with machines that *are* 'always on' this problem may not arise.
But for those who turn off their machine for a fair bit of the time, it
will tend to happen.
As I said, Rick kindly wrote some code that fetches the time. I then used
it to write a simple program that then *sets* the clock if the user says it
should.
The question of 'audio' rates wasn't my main concern at all. I was however
concerned about the use of machines to collect data where timing *rate*
errors might be a problem. However this won't arise for most users. I'm
aware of it from a long history of using RO machines in labs, etc. There,
having a clock whose *rate* keeps being adjusted could be a pest as it
would corrupt the relative timing of a long data sequence.
What I wrote is far from perfect. But at least it gives users a choice. Do
they want to *set* the clock, or *regulate* it (just for the duration of
the session of use)? The two actions are quite different.
Jim
--
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Audio Misc http://www.audiomisc.co.uk/index.html
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
---
To alter your preferences or leave the group,
visit //www.freelists.org/list/armini-support
List-related queries to info@xxxxxxxxxxxx
Other related posts:
