Pipes are basically not good enough since there can be only one reader.
(assuming we want ntpd to get all the data)
1 samples, sender waits 1 ms between sends.
data is:
struct data {
struct timespec time;
int foo[12];
};
2 GHz Pentium:
# max = 150899us, average = 12821us
# 107 over 25u
Hi!
I've been following this discussion.
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.
..m
On Thu, Oct 20, 2016 at 2:53 PM Eric S. Raymond wrote:
> Hal Murray :
> >
Hi!
I would like to formalize a policy about development communication, which
can be touch-in-cheek expressed as:
If it wasn't in email, it didn't happen.
It is currently popular and trendy to use a "chat-centric" developer
communication model. Chat-centric dev does make sense for rapidly chang
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
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 driver makes all sorts of n
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 SHM driver running
> on a RasPi. I did no
