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
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
he same wavelength yet? Have we agreed that latency is
> not critical? If so, why is jitter important?
Latency is critical, jitter is important, but the GPSD-JSON driver does
not add any. As you said ealier, the deltas are computed in the kernel
(for KPPS) or in gpsd (for PPS). The gpsd s
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?
>> 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
Got it, thanks!
On Fri, Oct 21, 2016, 5:20 PM Gary E. Miller <g...@rellim.com> wrote:
> Yo Mark!
>
> On Fri, 21 Oct 2016 21:00:24 +
> Mark Atwood <fallenpega...@gmail.com> wrote:
>
> > We should remove the GPSD JSON driver from NTPsec.
>
> I spend 40 mi
Yo Mark!
On Fri, 21 Oct 2016 21:00:24 +
Mark Atwood <fallenpega...@gmail.com> 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 tha
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
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
questioning. I didn't question it before either, which is why the
> > above hack is not implemented.
>
> We can test it with the current code. Just setup ntpd to use both
> SHM and JSON.
Been there, done that, when Pearly wrote the GPSD JSON driver. Except
for all the bugs in his
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
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,
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.
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
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
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
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
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
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
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.
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
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.
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
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
>
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
> >
mory transport specifically for use by real-time embedded
> systems.
So, a shared memory driver for ntpd?
> From my point of view, the JSON driver in ntpd is a cute stunt that
> doesn't really fit the context very well. I'm mildly flattered that
> somebody thought GPSD JSON was co
e wire.
> I'm missing the big picture. The JSON driver was written because I (and
> probably others) thought you thought that JSON was the right way to talk to
> gpsd. Was that wrong and/or did anything change?
That's complicated.
Originally GPSD JSON wasn't really supposed to be an ext
I think we should rewrite it to use
the 2 counters trick so the readers are read-only. But let's save that
discussion for another time.
I'm missing the big picture. The JSON driver was written because I (and
probably others) thought you thought that JSON was the right way to talk to
gp
I have come to think the best thing to do about the GPSD/JSON driver is
just remove it. This note explains why. Please reply with agreement,
disagreement, or comment.
One brute fact is that this driver works poorly, if at all. See these
tracker issues:
https://gitlab.com/NTPsec/ntpsec/issues
hink it's barely adequate. I wrote a much more powerful library for GPSD
that parses JSON data directly into C structure slots, and spun it out
as a project called microjson. I say "library" but it's one fairly short
C file and a header, both very stable. Including them in the tree
would be
30 matches
Mail list logo