In article <d490d0a754.Andrew-Pin@xxxxxxxxxxxx>, Andrew Pinder <Andrew.Pinder@xxxxxxxxxxxxx> wrote: > Am I right in thinking that the 'Timer latch' value given by > *nettime_status is the value that is being used to 'regulate' the clock? > Currently 'Last delta' is 0.004372 seconds fast; 'Timer latch' is 13001 > (-7ppm). I'm not sure as I don't understand the inner workings of the supplied nettime program. But I think you are correct. > > 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. > I turn my machine (ARMini, RO5.20) on and off a couple of times a day. > It's definitely off more than on. I've no experience of the clock > being significantly inaccurate. BTW, I always have !Alarm on the > iconbar. Its a matter of luck and circumstances. AIUI The 'correction' to the rate only operates when the machine is on. When its off, the rate defaults to that of any supplied hardware clock. So how accurate your clock is after many days depends on factors like: 1) What fraction of the time your machine is on each day, and to some extent the patten of use. 2) How far from the 'standard time rate' your *hardware* clock's rate happens to be. In effect, the 'tweaks' made try to aim the clock to drift back towards the 'right time'. Then 're-tweak' on the chosen schedule. This process is disrupted by turning the machine off, allowing the clock to fall back on its fixed hardware rate. If your hardware clock rate is good, the error won't accumulate as quickly. Here I can leave the clock running without correction for many days or weeks and it will accumulate an error of the order of a second per day or slightly less.[1] But its a matter of how close your hardware clock rate happens to be to standard time rate. I'd be much happier with the standard method if it: 1) Explained clearly what it does and the distinction between regulation and setting. 2) Gave the user an option to *set* the time which then actually worked regardless of the existing error, leaving the soft clock rate unchanged. But as things stand it does neither, so people get different results and don't know why, or how to fix it. So if it suits someone, fine. But be aware of the issues involved. Jim [1] I set it here yesterday to about 1 sec. Just checked and it now says its about 3 sec off. However these values are chunked to a second and subject to server response delays. So the error drift might be more like 1 sec than 2. Assuming NIST can keep good time. 8-] -- 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