[ntp:bugs] [Bug 1783] PPS range gate check throws away valid samples

[bugzilla-daemon at ntp.org]

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

--- Comment #11 from Dave Hart <hart at ntp.org> 2011-03-17 18:57:45 UTC ---
(In reply to comment #9)
> the sequence numbers are part of the PPSAPI RFC-2783. It is not wrong
> to use these to detect duplicates and missed samples. It is the sole
> point for these sequence numbers.
> 
> Your notion that ntpd never depended on PPSAPI sequence numbers in only true if
> you don't consider following refclocks being part of ntpd:
> jupiter
> mx4200
> oncore
> parse
> ripencc

I did not say PPSAPI sequence numbers are nonstandard.  I did not say it would
be wrong to use PPSAPI serial numbers, I said I would rather avoid it.  Since
we seem to have a failure to communicate here, let me elaborate.

If we can achieve our goal solely by looking at the retrieved PPS timestamp and
ignore the sequence number, we avoid breaking working scenarios where ntpd has
not used the sequence number in the past.  Given the variety of PPSAPI
implementations and the relatively small userbase of any sort of PPSAPI, I
would rather be conservative.

Along the same lines, most/all PPSAPI consumers in ntpd retrieve timestamps in
timeval format, despite PPSAPI requiring support for l_fp format as well.  I
fixed our included timepps-Solaris.h where fudges were treated as timeval in
l_fp mode, a bug that no one noticed because no one used that code path.  I
noticed it while porting that timepps-Solaris.h to use with Windows.

In general PPSAPI exposes a lot more functionality that ntpd typically uses.  I
don't want to break our users in the interest of engineering perfection of all
PPSAPI implementations, which is mostly pointless as there are so few non-ntpd
consumers of PPSAPI.


> So to resolve the issue we must either have a correct rangegate
> implementation (Dave just removed the wrong implementation
> without any replacement).

Dr. Mills disagrees.  He's decided the range gate was never terribly useful and
we're better off with only duplicate rejection.  I do plan to proceed with
changing the duplicate test to compare tv_usec as well.  If there remains a
demonstrable problem after that point, please post another comment.

-- 
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.