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. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
