[ntp:bugs] [Bug 3615] accelerate refclock startup

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Sat Sep 21 06:44:33 UTC 2019


https://bugs.ntp.org/show_bug.cgi?id=3615

Juergen Perlinger <perlinger at ntp.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|IN_PROGRESS                 |READY

--- Comment #13 from Juergen Perlinger <perlinger at ntp.org> 2019-09-21 06:44:33 UTC ---
I stayed with the 'take2' patch in the end, having minimum times to wait before
the next sys_poll change.

Harlan, the repo is in
   psp.ntp.org:~perlinger/ntp-stable-3615

IMHO the initial value problem remains itchy. If after startup a clock has an
offset, this slowly populates the clock filter stages and creates a jitter
component comparable to the offset. This in turn drives the time constant
(sys_poll) to higher values. The jitter component created by the initial step
response abates over time, but by then the local clock discipline has most
likely pushed sys_poll upwards. Feeding clock samples faster improves the
behavior by speeding up things, but it cannot completely avoid the step
response in the jitter calculation.

I don't think there's much that can be done here: The initial step response is
just a step response that cannot be distinguished from any other step. Well, we
might find a way to make sure the first incoming sample ever from a peer
presets the full filter history to avoid the initial step response, but I just
don't dare doing this.

This problem is also not limited to refclocks alone -- now we're at a point
where *every* peer would be affected.

Anyway, this should go to a different bug report then. Ideas welcome.

-- 
Configure bugmail: https://bugs.ntp.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the bugs-announce mailing list