Re: [gpsd-dev] [PATCH] Time Service HOWTO: Clarify state of RFC2783 on NetBSD.

[Hal Murray]

address@hidden said:
>> ntpd uses the RFC2783 interface.  There is no reference to
>> TIOCMIWAIT in the ntpd code.
> Confirmed, but then operating without RFC2783 does not work. 

ntpd won't be able to use the PPS info, but how many OSes support TIOCMIWAIT 
but don't support RFC2783?


[ntpd uses links]
> So the gpsd approach, when it works, is smarter as it finds the required
> device.  We could hard code something as a fallback, but how would we handle
> multiple GPS and dynamic ports? 

I wasn't trying to suggest any changed to gpsd, just describing how ntpd 
works.

[PLL in kernel for RFC2783]
> By several  removing the kernel/user and user/kernel context switched the
> latency and accuracy are seriously improved.  Probably two deciaml places
> depending on a bunch of factors like load and CPU count. 

Grabbing the timestamp is the critical part.  All the code is going to do is 
tweak what ntpd calls the drift - the fudge factor that corrects the rate the 
clock is ticking.  I don't see how a few ms delay there will make any 
difference.

The problem may be that they didn't implement the wakeup part of RFC2783 and 
didn't have TIOCMIWAIT back in those days so they couldn't wakeup userland at 
the right time.  I'm a bit surprised they didn't implement and use the 
wakeup.  It seems simpler/cleaner to me.  ????

[setting up /dev/pps<n> with ldattch
> Nope.  Here is how gopsd does it in ppsthread.c:

Sorry I wasn't clear.  I was trying to describe the way ntpd works.

Thanks for the code sample.



-- 
These are my opinions.  I hate spam.