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

[Alexander Carver]

On 2016-08-15 12:22, Gary E. Miller wrote:
> Yo Alexander!
> 
> On Mon, 15 Aug 2016 11:57:37 -0700
> Alexander Carver <address@hidden> wrote:
> 
>>> Many many people do this just fine.  I have 8 boxes doing this
>>> now. Eric has a simliar number.  We have a lot of beta testers doing
>>> similar.  There are zero open bugs on anything like this.  I can
>>> provide many graphs showing it works fine, and has for many years.  
>>
>> Yes, I hear this but I have not been able to replicate the results.
> 
> So what are your results and what is your setup?

A couple Sparc R220 servers, an SS20 pizza box, a couple IPXes (for fun)
an AMD Athalon, an Intel P2, an Intel P4 and an older 486DX.    All of
them using hardware serial ports (no USB dongles).  OS was Windows XP,
Debian wheezy, NetBSD and Solaris.  GPSes were Garmin 18LVCs or
GlobalSat ET212 modules.  Mix and match various combinations of the
three categories to rule out individual components.

All the GPSes are outdoors with a nearly full view of the sky (minus a
mountain to my east) so they usually have 6-8 birds in view with strong
signals.

All of them resulted in good performance from PPS via Driver 22
(microseconds) or poor performance via SHM (milliseconds).  There is
minimal drift with the Driver 22 configurations (less than 30
microseconds) unless the server is heavily loaded.  SHM PPS wanders
around and doesn't stay stable.  It usually gets called a false ticker
within a day.


> 
> 
>>> Totally bizare.  Single digit microSeconds are the universal result.
>>> Are you sure your kernel PPS driver is installed correctly and seen
>>> by gpsd when it is built?  
>>
>> Yes, it's seen and installed correctly.  Works fine with Driver 22,
>> it's awful with gpsd.
> 
> 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.


>>> If those do not work for anyone we would jump on it right away to
>>> get a fix.  
>>
>> I haven't tried it with a Raspberry Pi but I've tried it on several
>> normal machines (Intel motherboards, Sun, all with real serial ports)
>> using multiple OSes (Linux, Windows, Solaris, BSD) and several GPS
>> receivers with PPS outputs and they've all done miserably using SHM
>> PPS.
> 
> Ditto here.  A ton of hosts, a ton of OS, no reported problems but yours.
> 
> Details please.

See above.

> 
>>>> In any event, is NTPsec a replacement or is this a fork of ntpd?  
>>>
>>> Yes.  
>>
>> Is it an official replacement of the ntpd code base (i.e. ntpd's
>> current code will cease to exist and yours will replace it)?  I see no
>> documentation anywhere that suggests ntpd's code base is disappearing.
> 
> Depends on who gets to be 'official'.  Funding is shifting from NTP
> Classic to NTPsec.  Take look at the NTP Classic git.  Last commit seven
> months ago.
> 
> https://github.com/ntp-project/ntp
> 
> 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.