On 05/26/2016 07:23 PM, Stuart Maclean wrote: > Hi Pearly, > > based on your suggestion on the use of ntpq, I indeed ran those commands > and the offset does indeed say about 26ms, see here: > > associd=0 status=0418 leap_none, sync_uhf_radio, 1 event, no_sys_peer, > > version="ntpd 4.2.8p4@1.3265 Mon May 23 20:45:07 UTC 2016 (1)", > > , leap=00, stratum=1, > precision=-15, rootdelay=0.000, rootdisp=26.313, refid=csac, > > reftime=daf1adb7.a5581391 Thu, May 26 2016 17:15:35.645, > > clock=daf1adbd.54fb354f Thu, May 26 2016 17:15:41.331, peer=6499, tc=4, > > mintc=3, offset=25.970500, frequency=500.000, sys_jitter=0.000000, > > clk_jitter=1.029, clk_wander=12.000 >
(*grunt*) Instructive, and rules out a few possibilities. > > > I shall have to see if my ntp build process was flawed. Our deployment > target is a legacy Linux 2.6.10 system on Arm, and we have a fairly > dated cross compiler toolchain. So getting ntp to cross-compile at all > took a bit of effort, my exact sequence was this: > > $ mkdir arm-linux > $ cd arm-linux > $ ../configure --host=arm-linux --disable-GPSD --with-yielding-select > $ make > > Perhaps those extra configure options, without which the build failed, > introduce some offset of 26ms ?? That sounds unlikely to me... which proofs nothing, of course. But omitting the GPSD/JSON protocol support won't do any harm, and the method for multiplexed IO shouldn't do anything bad, either. But a few thoughts start to connect... And one thing would be *really* bad: Are you sure the implementation of 'adjtimex' is fully operational? You said you have a 32kHz crystal (probably a 32768Hz wrist watch oscillator), and properly implementing the adjtimex syscall is probably tricky with such a low frequency. But even if this call is properly implemented, there's still the interaction with the close loop controller in NTPD. AFAIR ntpd does not accumulate the residual correction that is returned after setting a slew with this call. So if your implementation of adjtimex needs a certain threshold to start working actively, there's a good chance that the FLL/PLL closed loop controller will not issue a correction that exceeds this limit once the deviation is small enough -- e.g., 26msec! (The same could happen if there's no real threshold: If at least part of the correction does not happen in the next second, nothing will happen at all: NTPD issues a correction once per second, cancelling any old correction that is not yet complete.) I *think* the non-accumulating behaviour is by intention, because accumulating the the residual creates a very different feedback characteristic. That is, it would become a different closed loop controller, and not necessarily with same stability properties. Considering the time Dr. Mills spent on those issues I don't think fiddling around there is a good idea. Is the 32768Hz oscillator the only possible time source? I would hope that there are other, much faster oscillators available to implement the system clock... These would probably result in *much* smaller internal thresholds, and consequently much smaller residual errors. Provided the assumption about the internal minimum threshold for 'adjtimex' to kick in can be held upright. > > I'll re-run ntpd on our target arm board under strace, and see it is > using e.g. some drift file I was unaware of. > Especially the drift file shouldn't be a problem, as after a while your offset becomes stable -- just not zero, as it should. > Thanks again for your help and suggestions de nada! _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
