Re: [gpsd-users] Garmin 18X-5Hz

[Alexander Carver]

On 2016-08-15 14:37, Gary E. Miller wrote:
> Yo Alexander!
> 
> On Mon, 15 Aug 2016 14:18:54 -0700
> Alexander Carver <address@hidden> wrote:
> 
>>> So what are your results and what is your setup?  
>>
>> A couple Sparc R220 servers, an SS20 pizza box, a couple IPXes (for
>> fun)
> [...]
> 
> Nice, but none of it answers my questions:
> 
> What are your results, hard numbers and graphs please.  A/B preferred.
> 
> What is your setup: exact configuration files please.

I don't have any of the setup anymore and I wasn't originally planning
on reporting it so I didn't generate plots or collect data permanently.
I did a test, didn't like the results, then changed the configurations
of the hardware and software until I got something that worked.  This
set of threads piqued my interest.

Maybe if I have some tuits available again I can set things back up to
collect data especially  if there's been any change to SHM code in gpsd
and/or ntpd.  However, on some of the older systems it takes me much
longer to get around to setting up because I have to make a makefile for
gpsd since the scons code it uses requires a much newer version of
python than is available for those machines.

>>> How can you tell it is correct?  Does ppstest work?  Does gpsd say
>>> it see kpps on startup?  
>>
>> Yes, ppstest worked fine in all cases, ntpd driver 22 registered the
>> pulses as well, and gpsd claimed it saw kpps.
> 
> Odd, what versions of gpsd and ntpd?

ntpd was 4.2.2 or thereabouts, gpsd was around 3.13 I think (mid 2015)


>>> Then check out the number of CERT advisories this year for NTP
>>> Classic versus NTPsec.
>>>
>>> Does that look healthy to you?  
>>
>> Doesn't entirely scare me.  What actually scares me is if this is the
>> full replacement for ntpd and and you decide Driver 22 or remote
>> monitoring (e.g. ntpq) will go away.  At that point I'm left with no
>> choices but to run old ntpd code.
> 
> I'm not deciding anything, take it up with them.  I just happen to
> agree, too many problems with driver 22.  But it wil not be going away
> soon.
> 
> The remote ntpq turned out to be a security nightmare.  I do agree that
> it was probably ripped out a bit prematurely.  My preference is always
> to have the replacemennt done before ripping out the old badness.  If I
> were to try to read Eric's min, and I am a bad mindreader, I think he
> feels that ripping out the old badness will cause people to code up the
> replaecment faster.
> 
> In neither case do I get a vote, feel free to take up those complaints 
> with them; address@hidden
> 
> The gpsd-users list is for how to get gpsd/ntpd to play well together.
> Driver 22 is known to be an inferior solution.  Driver 28, SHM(), for
> now is the superior solution.  At least until you can provide hard
> data, and hard configurations to prove otherwise.

True it's for gpsd but my experience is gpsd not playing nicely with
ntpd and the fault is lying with gpsd because ntpd plays nicely with the
GPS receiver on its own.  In the absence of a functional pairing of
gpsd-ntpd the use of Driver 22 is my only solution.

> 
> I'm not saying there are not problems withh the SHM() driver, some were
> discussed today on #ntpsec.  At least on NTPsec progress is being made.
> With 7 months without an NTP classic commit you are stuck with old
> grotty code.

I have to take grotty code when it's the code that actually works.