> > > I'm not sure exactly where you want to do this check. The
> dispersion
> > > calculated at the beginning of RCL_AddSample and RCL_AddPulse is
> > > actually based on the average dispersion from the filter. I don't
> > > see how rejecting samples when the filter result is too big will
> > > he
On Thu, May 22, 2014 at 11:53:25AM +0200, Hattink, Tjalling [FINT] wrote:
> I tried to mail the patch but somewhere the email text gets extra line
> breaks, so the patch breaks. I've attached the patch as a file now.
Applied, thanks. (I've reformatted the text to 80 columns and prefixed
the subjec
This is an automated email from git. It was enerated because a ref
change was pushed to the repository "chrony/chrony.git".
The branch, master has been updated
via 8210be0f17429f8e396d09a5e92c9e0f8f8e751e (commit)
via f88a712d01597c44dd4ddbc195dc1480cc0d72c9 (commit)
via 9c
Hi,
I tried to mail the patch but somewhere the email text gets extra line
breaks, so the patch breaks. I've attached the patch as a file now.
Best regards,
Tjalling Hattink
chrony.patch
Description: chrony.patch
This patch fixes leap second handling for the PPS refclock. Without the
patch the PPS refclock will
always report LEAP_normal. But if a locked refclock (the SHM clock in my
case) does report a leap
state it should also be taken over by the PPS refclock, otherwise chrony
will still use LEAP_normal
w
On Thu, May 22, 2014 at 09:00:33AM +0200, Hattink, Tjalling [FINT] wrote:
> I've pasted a patch below that fixes leap second handling for the PPS
> refclock. Without the patch the PPS refclock will always report
> LEAP_normal. But if a locked refclock (the SHM clock in my case) does
> report a leap
Hi,
I've pasted a patch below that fixes leap second handling for the PPS
refclock. Without the patch the PPS refclock will always report
LEAP_normal. But if a locked refclock (the SHM clock in my case) does
report a leap state it should also be taken over by the PPS refclock,
otherwise chrony wil
