[ntp:questions] ntp-dev: PPS is a falseticker?

Brian Inglis Brian.Inglis at Shaw.ca
Sat Jun 14 20:47:09 UTC 2014


On 2014-06-14 12:03, Rob wrote:
> Brian Inglis <Brian.Inglis at SystematicSw.ab.ca> wrote:
>>> I see no problem, really no problem, in this configuration and I wonder
>>> why the software makers do see a problem in it and want me to make a
>>> configuration decision that introduces yet more problems.
>>
>> There may be no problem with time only messages: the NMEA driver page,
>> http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html
>> shows support of GLL and GGA which provide only time.
>> Other drivers may allow similarly limited information.
>
> There is NO NMEA in or near my system!
> Everyone seems to think that GPS equates NMEA.  Wrong.
>
>> Could you not put a Y or T from your DO GPS message output to your system
>> serial port, with the PPS on the DCD pin, providing a standard PPS+GPS
>> serial interface?
>
> The serial output of the device does not provide the date.
> Only the time.  It is not NMEA.

That was just an example that I was aware of.
It demonstrates that ntpd doesn't need the date.
Check the driver page (and code) for your device.

>> This is really a product where you have to RTFM!
>>
>> Check the dev doc sitemap page
>> http://www.eecis.udel.edu/~mills/ntp/html/sitemap.html
>> for Mitigation Rules and the prefer Keyword at
>> http://www.eecis.udel.edu/~mills/ntp/html/prefer.html
>> (appears twice under Special Topics section)
>> and the Ref Clock Drivers
>> http://www.eecis.udel.edu/~mills/ntp/html/refclock.html
>> http://www.eecis.udel.edu/~mills/ntp/html/refclock.html#list
>> esp.
>> http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver22.html
>> also read all the pages about PPS and Kernel model.
>
> Unfortunately the fact that the prefer keyword is required is buried deeply
> in the doc, and also it is still not clear why this restriction was
> added.  It apparently assumes anyone who has a PPS signal also has a
> device that provides date and time information, which is wrong.
>
> But of course the assumptions of the main author have been wrong before.
> This is no problem, everyone can sometimes be wrong.  But this person
> is a bit stubborn, as many contributors have experienced.
>
> On my other test system I had copied an example config which happens
> to include the prefer keyword, but it is not at all clear that ntpd
> will mark a PPS peer as "falseticker" BECAUSE there is no "prefer"
> keyword on at least one other server.
> (it DOES output other warnings, like that the "kod" restriction does
> nothing without the "limited" restriction, but nothing about this)
>
>> The reference implementation is produced by an EE/CE research group as
>> an accurate time control system, and is developed and supported by
>> volunteers, some of whom may have orgs paying for some of their time.
>
> I think the problem is not that it is free or who is going to pay.
> When other people would supply fixes, they would not be accepted anyway.

I have seen platform, driver, and doc patches accepted from many contributors.
But not when they would mess with the main discipline control engineering,
which may be a matter of direction and hard won experience across hostile
environments of many kinds.
Sometimes a blunt rejection is easier and may be kinder than a lengthy,
rigorous analysis andexplanation of why a simple minded approach or
idea is boneheadedly, obviously, stupid to the design engineer.
One may have to be prepared to patch the simulator, run all the regression
tests, and analyze the results, to prove rigorously that a proposed control
change would not adversely affect any possible setup.
(My first manager used to be a Control Systems EE/CS prof before he was
lured into commercial R&D, and everything from spelling, wording, grammar,
code, comments, tests, and docs would get the blue and red pen treatment.)
-- 
Take care. Thanks, Brian Inglis


More information about the questions mailing list