Re: Proposal - drop the GPSD JSON driver

Yo Eric! On Sat, 22 Oct 2016 09:21:59 -0400 "Eric S. Raymond" wrote: > Hal Murray : > > >> I assume that using a pipe or socket rather than SHM would fix > > >> that. > > > > > Probably, but then we run unto buffering jitter again. > > > > Are

Re: Proposal - drop the GPSD JSON driver

Yo Hal! On Sat, 22 Oct 2016 03:15:01 -0700 Hal Murray wrote: > >> Word-length mismatch between two programs built under the same OS > >> never happens, or close enough to never that I don't care. > > Uh, no. remember when intel OS went from 32 bit to 64-bit? It was

Re: Proposal - drop the GPSD JSON driver

Yo Hal! On Sat, 22 Oct 2016 02:31:01 -0700 Hal Murray wrote: > >> I assume that using a pipe or socket rather than SHM would fix > >> that. > > > Probably, but then we run unto buffering jitter again. > > Are we on the same wavelength yet? Have we agreed that

Re: Proposal - drop the GPSD JSON driver

Hal Murray : > >> I assume that using a pipe or socket rather than SHM would fix that. > > > Probably, but then we run unto buffering jitter again. > > Are we on the same wavelength yet? Have we agreed that latency is not > critical? If so, why is jitter important?

Re: Proposal - drop the GPSD JSON driver

>> Word-length mismatch between two programs built under the same OS >> never happens, or close enough to never that I don't care. > Uh, no. remember when intel OS went from 32 bit to 64-bit? It was a huge > issue with ntpd. RasPi is about to have the same problems. What sort of problem do

Re: Proposal - drop the GPSD JSON driver

Got it, thanks! On Fri, Oct 21, 2016, 5:20 PM Gary E. Miller wrote: > Yo Mark! > > On Fri, 21 Oct 2016 21:00:24 + > Mark Atwood wrote: > > > We should remove the GPSD JSON driver from NTPsec. > > I spend 40 minutes last night trying to get the GPSD

Re: Proposal - drop the GPSD JSON driver

Yo Mark! On Fri, 21 Oct 2016 21:00:24 + Mark Atwood wrote: > We should remove the GPSD JSON driver from NTPsec. I spend 40 minutes last night trying to get the GPSD SHM driver running on a RasPi. I did not get it finished. The experience reminds me that the #48

Re: Proposal - drop the GPSD JSON driver

fallenpega...@gmail.com said: > We should remove the GPSD JSON driver from NTPsec. > It is an attractive nuisance. The SHM driver, possibly with improvements, > is a better interface between NTPsec and GPSD. It's useful for collecting data on non-SHM approaches. How about we defer dropping it

Re: Proposal - drop the GPSD JSON driver

Hal Murray : > > e...@thyrsus.com said: > >> Yes, I've been thinking about mechanisms for this. They're all rather > >> irrelevant. > > Argh. I meant "inelegant". > > I assume that using a pipe or socket rather than SHM would fix that. Probably, but then we run unto

Re: Proposal - drop the GPSD JSON driver

Yo Hal! On Thu, 20 Oct 2016 14:19:05 -0700 Hal Murray wrote: > e...@thyrsus.com said: > >> The SHM interface is deltas. gpsd figures out the offset and > >> sends that over to ntpd. How gpsd figures out that offset has > >> nothing to do with SHM or JSON or anything

Re: Proposal - drop the GPSD JSON driver

Yo Eric! On Thu, 20 Oct 2016 16:52:06 -0400 "Eric S. Raymond" wrote: > > The SHM interface is deltas. gpsd figures out the offset and sends > > that over to ntpd. How gpsd figures out that offset has nothing to > > do with SHM or JSON or anything else involved with getting

Re: Proposal - drop the GPSD JSON driver

Yo Eric! On Thu, 20 Oct 2016 16:11:41 -0400 "Eric S. Raymond" wrote: > Gary E. Miller : > > > What sort of problems are there with the current one? > > > > Do we really need to go over this yet again? These have been > > covered for years. > > > > First,

Re: Proposal - drop the GPSD JSON driver

e...@thyrsus.com said: >> Yes, I've been thinking about mechanisms for this. They're all rather >> irrelevant. > Argh. I meant "inelegant". I assume that using a pipe or socket rather than SHM would fix that. -- These are my opinions. I hate spam.

Re: Proposal - drop the GPSD JSON driver

e...@thyrsus.com said: >> The SHM interface is deltas. gpsd figures out the offset and sends that >> over to ntpd. How gpsd figures out that offset has nothing to do with SHM >> or JSON or anything else involved with getting the data to ntpd. The offset >> won't change much in a short time so

Re: Proposal - drop the GPSD JSON driver

Hal Murray : > sem_wait doesn't work with select. You would have to do something like setup > another thread and have it send a byte down a pipe. (The DNS lookup path > does that. It may be on end-of-thread rather than data-ready.) Yes, I've been thinking about

Re: Proposal - drop the GPSD JSON driver

e...@thyrsus.com said: > Hm. That's an argument for something with a wait or ready signal. Not an > argument for JSON in SHM. Might mean we need an auxiliary semaphore to do > sem_wait on; not a problem. I was never interested in JSON in SHM. sem_wait doesn't work with select. You would

Re: Proposal - drop the GPSD JSON driver

Gary E. Miller : > > What sort of problems are there with the current one? > > Do we really need to go over this yet again? These have been covered > for years. > > First, the structure needs to be polled, sometimes leading to long > delayed and even missed samples. This will

Re: Proposal - drop the GPSD JSON driver

Yo Eric! On Thu, 20 Oct 2016 07:34:18 -0400 "Eric S. Raymond" wrote: > Hal Murray : > > > > e...@thyrsus.com said: > > > Same thing with JSON. The client can't predict when JSON will > > > come up the wire. > > > > The client is normally

Re: Proposal - drop the GPSD JSON driver

Yo Hal! On Thu, 20 Oct 2016 03:38:00 -0700 Hal Murray wrote: > g...@rellim.com said: > > Not a POSIX sharde memory one. > > What do you mean by POSIX in this context? How would I recognize one > if I was looking at it? We are talking about the shared memory

Re: Proposal - drop the GPSD JSON driver

Gary E. Miller : > Oh, please not! That is one of the big problems in the existing driver. > Way too compiler, CPU and OS dependent. Plus not extensible. The > exsting C struct has been nothing but problems. Maybe you don't buy into > JSON, but the C struct is a non-starter.

Re: Proposal - drop the GPSD JSON driver

Hal Murray : > > e...@thyrsus.com said: > >> So, we all vote for JSON in POSIX SHM? > > I don't. I think this is one of the very rare cases where passing a C stru= > > ct as a binary blob makes sense. We want to minimize offset and jitter and > > there's no

Re: Proposal - drop the GPSD JSON driver

g...@rellim.com said: > Not a POSIX sharde memory one. What do you mean by POSIX in this context? How would I recognize one if I was looking at it? > Say what? The existing protocol has serious problems. What sort of problems are there with the current one? -- These are my opinions.

Re: Proposal - drop the GPSD JSON driver

e...@thyrsus.com said: >> So, we all vote for JSON in POSIX SHM? > I don't. I think this is one of the very rare cases where passing a C stru= > ct as a binary blob makes sense. We want to minimize offset and jitter and > there's no cross-architecture problem. Don't forget to include a

Re: Proposal - drop the GPSD JSON driver

e...@thyrsus.com said: > Same thing with JSON. The client can't predict when JSON will come up the > wire. The client is normally waiting in the big select. It will get woken up as soon as data is available. > Originally GPSD JSON wasn't really supposed to be an externally exposed >

Re: Proposal - drop the GPSD JSON driver

Gary E. Miller : > So, a shared memory driver for ntpd? It already has one. I think the one it has would be as good as we need if not for the fact that that version of SHM is obsolete and unstandardized. > > I don't think either is going to match the performance of a > >

Re: Proposal - drop the GPSD JSON driver

Yo Eric! On Wed, 19 Oct 2016 21:30:28 -0400 "Eric S. Raymond" wrote: > Hal Murray : > > It has a different type of noise. There is no "ready" signal on > > SHM so the driver polls and the timing on that is just the luck of > > when ntpd was started.

Re: Proposal - drop the GPSD JSON driver

Hal Murray : > It has a different type of noise. There is no "ready" signal on SHM so the > driver polls and the timing on that is just the luck of when ntpd was started. Same thing with JSON. The client can't predict when JSON will come up the wire. > I'm missing the

Re: Proposal - drop the GPSD JSON driver

I think you should leave it until we get our act together, and I think you should put that on the back burner until 1.0 is out. > For communication with GPSD, the SHM driver seems superior; it certainly has > lower processing overhead and therefore introduces less noise into the > delivery