Yo Eric! On Thu, 20 Oct 2016 07:34:18 -0400 "Eric S. Raymond" <e...@thyrsus.com> wrote:
> Hal Murray <hmur...@megapathdsl.net>:
> >
> > 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.
>
> Oh, now I see what you mean. You're right.
>
> 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.
Huh? POSIX in SHM has a semaphore! So there is an argument for
JSON in POSIX SHM.
> There's an easy way to take GPSD's heavy computation work out of the
> budget that we haven't used yet.
Uh, what heavy commputation? Prolly less than 100 LOC from KPPS to
done out the door to ntpd.
> You take a nanosecond-precision
> timestamp on the first read of data from the device. You take a second
> timestamp just before you ship. You bump the fix time by the
> difference between the second and first timestamps.
Oh, you mean like itt already does?
> You might be right that the noise from JSON encoding/decoding time
> does not add significantly to the jitter budget. We should test and
> see.
NO added noise. Obvious by inspection of the protocol.
> > The problem with semaphores is that I don't see a clean way to
> > initialize them and/or recover from crashes.
>
> Pre-POSIX SHM has the same problem and the same mitigation
> strategies. It hasn't been a problem in practice.
I disagree. PSOIX HSM is much better thought out.
> > The advantage of a pipe or socket is that they fit in to the select
> > we have. I don't believe the cycles associated with either will be
> > significant, but I don't have numbers to back that up.
> >
> > Maybe we should start a side project to write some clean sample
> > code an/or collect some timings.
>
> You are quite right. We should do exactly that.
So, we are bock to JSON (or something not binary) in POSIX SHM?
I suggest after 1.0 given the uncertainies...
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
pgpmAggIVoiez.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
