On Fri, May 14, 2021 at 7:33 PM Richard Cochran <richardcoch...@gmail.com> wrote: > > On Thu, May 13, 2021 at 07:31:27PM +0200, Lars Munch wrote: > > On Sat, May 8, 2021 at 8:47 PM Richard Cochran <richardcoch...@gmail.com> > > wrote: > > > > > > On Sat, May 08, 2021 at 02:57:30PM +0200, Lars Munch wrote: > > > > > > > 1. Use the time provided by gpsd to ntpshm. This can be implemented > > > > without > > > > dependencies to gpsd. > > > > > > Doesn't sound aweful, but not great either. > > > > I kind of like the simplicity of this solution. No need for extra > > daemons to pipe the > > data from gpsd to ts2phc. The thing I do not like is the polling that > > it would have to > > do, but that's only a few times per second. Anything else that I have > > missed which > > is awful? > > > > Does this mean I should not waste my time implementing this as you can > > already > > now say it will not be accepted? > > There are two design questions that need answering. > > 1. Will this work reliably? That is, will the ntpshm (almost) always > have correct time? Or will this become a constant source of > questions on the list to the tune of, "I used linuxptp as a GPS GM > and it does not work ..." I do NOT want to become a support > channel for gpsd. > > 2. How can the GM logic determine whether the time in the ntpshm is > verified to be globally correct or not? > > With the present solution using RMC, we have a simple flag (field 2 is > either "A" or "V") that signals the validity. It is practically > impossible to determine generically whether the reading from a > particular GNSS radio is valid. For this reason we push the > responsibility to an external program.
Thank you for taking the time to share your thoughts on the subject. I will write an external program instead as the gpspipe | socat solution is too flaky. Regards Lars _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
