In message <54abe00083jcgl@xxxxxxxxxxxxxxx> on 29 Mar 2015 Jim Lesurf <jcgl@xxxxxxxxxxxxxxx> wrote: > In article <57d8d8ab54.Andrew-Pin@xxxxxxxxxxxx>, Andrew Pinder > <Andrew.Pinder@xxxxxxxxxxxxx> wrote: >> >> Give the reported problems about smaller errors not being corrected, >> I'm wondering what people have experienced with the switch to BST. > FWIW the clock on my ARMiniX had drifted about 10 sec since I set it a few > days ago. I set it OK with the program I wrote and it wasn't concerned > about BST. (It deals with the underlaying UTC and the RO setup applies the > zone correction.) Seemed consistent with my machine's clock being off > by one or two seconds a day. (i.e. 10 - 20 ppm.) >> After syncing at boot, my clock is currently 0.616643 seconds slow, >> timer latch 129911 (+684ppm). > Erm, I doubt people will be getting results via net adjustments of the type > the OS does where you can state 'accuracy' to the nearest microsecond! To > do that you'd probably have to put in some work calibrating the time delays > in sending and getting times over the net. I suspect people would be better > keeping values to about a centisecond. That's if you have reasons to be > concerned at that level. > And as I've suggested before, if people want to do this they'd also need to > give detailed histories of when the machine was on/off, when any time > nudges were made, etc. Otherwise it will be almost impossible to compare > results and make any sense of how they may vary. > If you want serious accuracy you'd be better looking for a radio time > standard I suspect. > Also... > If my quick calculation is correct the rate offset you quote would > nominally remove the error in about 15 mins. If you have the OS time > system set to re-correct at a set interval, note that if that time is > too long the error will 'saw' back and forth between fast and slow. > Again, to know more you'd need to measure again just before you shut > down the machine (having noted how long it was on and when any auto > corrections were done). Then note how long it was off when repeating the > process when you start it up again. If you don't do this the values > you get may just seem random. *nettime_status Current time: Sunday, 29 March 2015 08:38:15.14 Status: Sleeping Last adjustment: 5 minutes 23 seconds ago Last delta: 0.616643 seconds slow Last server: ntppub.le.ac.uk Last protocol: SNTP Poll interval: 15 minutes Timer latch: 129911 (+684ppm) *nettime_status Current time: Sunday, 29 March 2015 08:41:41.80 Status: Sleeping Last adjustment: 8 minutes 49 seconds ago Last delta: 0.616643 seconds slow Last server: ntppub.le.ac.uk Last protocol: SNTP Poll interval: 15 minutes Timer latch: 129911 (+684ppm) *nettime_status Current time: Sunday, 29 March 2015 08:51:29.16 Status: Sleeping Last adjustment: 3 minutes 36 seconds ago Last delta: 0.099646 seconds slow Last server: electra.pinklemon.net Last protocol: SNTP Poll interval: 15 minutes Timer latch: 129971 (+223ppm) *nettime_status Current time: Sunday, 29 March 2015 09:30:44.62 Status: Sleeping Last adjustment: 12 minutes 49 seconds ago Last delta: 0.001416 seconds slow Last server: time.videxio.net Last protocol: SNTP Poll interval: 15 minutes Timer latch: 130000 *nettime_status So within 45 minutes it was close enough to stop adjusting the clock. This was just before I shut down. I restarted just after 1 PM ago and got: *nettime_status Current time: Sunday, 29 March 2015 13:16:42.38 Status: Sleeping Last adjustment: 13 minutes 14 seconds ago Last delta: 0.379843 seconds slow Last server: time.rdg.uk.as44574.net Last protocol: SNTP Poll interval: 15 minutes Timer latch: 129945 (+423ppm) Current time: Sunday, 29 March 2015 13:22:36.19 Status: Sleeping Last adjustment: 4 minutes 7 seconds ago Last delta: 0.104400 seconds slow Last server: resntp-a-vip.lon.bitfolk.com Last protocol: SNTP Poll interval: 15 minutes Timer latch: 129970 (+230ppm) It looks like it can correct time pretty quickly on a poll interval of 15 minutes. Regards Andrew -- Andrew Pinder --- To alter your preferences or leave the group, visit //www.freelists.org/list/armini-support List-related queries to info@xxxxxxxxxxxx