> On 11/08/2015, at 9:24 pm, Miroslav Lichvar <[email protected]> wrote: > > On Tue, Aug 11, 2015 at 05:18:47PM +1200, Bryan Christianson wrote: >>> Hm, it's not clear to me why is the interval a function of >>> kernel_slewrate and max_error. Is that intended for the case when a >>> large offset is being corrected and to not make unnecessary updates >>> before the offset reaches zero? >> >> Yes. I realise any residual is picked up in the next cycle, but my thinking >> was to complete the update within a cycle in order to minimise the number of >> wakeups. > > It would be nice to have that too. But shouldn't it be rather a > function of the offset which was set by the last adjtime() call > instead of the estimated maximum error to the reference?
OK - I'll look into that. Probably a separate patch. > >>> Something like this: >>> drift_removal_interval = C1 * est_error / (fabs(current_freq) + C2); >> >> So this is estimating the contribution of local drift to offset_sd where C1 >> is an estimate of the proportion of local contribution? > > Ideally, if adjtime() reports the remaining offset accurately (and > there is no adjtime() offset lost or applied twice), the absolute > value of the drift should have no effect on the offset_sd value. The > source tracking works with the cooked timestamps and should be more or > less independent from any corrections that are currently applied to > the local clock. It's the job of the driver to hide them from the > upper layers. > > I meant the C1 constant as a ratio between the maximum acceptable > offset of the clock that is gained between adjtime() updates and the > estimated error in the source tracking (including source combining, > etc). > > If the clock is drifting by 10 ppm and the tracking of the source says > it's good only to 100 us, I think it would be ok to allow the clock to > drift between adjtime() updates by 25, 50, or maybe even 100 us. The > overall error of the clock won't be significantly worse than it would > be with a very short interval keeping the adjtime() offset within few > microseconds. I think what we're saying is that there's a performance measure. Not how close 'System time' is to 0 but rather what is 'System time' relative to other errors. I'm not sure of good name for such a measure but its kind of like a signal to noise ratio. We could even express it in dB. I think on a Mac chrony will be mostly used to keep local time as near to NTP as possible rather than providing NTP services to other hosts and a single measure to express its accuracy would be good. ntpd doesn't seem to do better than about 5ms offset using my LAN NTP servers and chrony is already orders of magnitude better than that. > >>> where C is some constant between 0.0 and 1.0 and C2 is maybe 1 ppm to >>> prevent getting inf or nan when current_freq is very close to zero. >> >> I'm testing this at the moment with C1 = 0.1 (just a guess based on my drift >> of 22ppm and offset_sd between 20 and 150 usecs for the LAN ntp servers) and >> C2 = 0.5e-6 (i.e. a small fraction of my observed drift) >> >> The LAN results look satisfactory with drift_removal_interval < 1.0 secs. >> Local (NZ) based pool servers also seem to work OK with 0.9 < >> drift_removal_interval < 3 >> International (US) pool servers are also working OK - offset_sd around >> 5000usec and drift_removal_interval about 30 secs > > Is that with just one source or multiple sources (i.e. combining > enabled)? It would be nice if the update interval was in a typical > case with multiple pool.ntp.org servers at least 5-10 seconds long. > 5 servers from each of the NZ and US pools - so combining is in effect. In looking at our NZ servers (about 10ms round trip over my DSL link) I am seeing about 1/2 the interval you suggest. If C1 (we need a better name) is increased from 0.1 to say 0.25 than update interval should be pretty close to the 5 - 10 sec range I have 3 servers on my LAN, including a stratum 1 USB GPS PPS that is good to about 5 usecs - and thats close to the 'System time' I'm seeing on the Mac. I think this approach works quite well and a bit of fine tuning on the constant should get a good compromise for typical use cases. Regards B -- Bryan Christianson -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
