Pipe timings
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 25us, 6 over 50us
1.6 GHz Atom:
# max = 128649us, average = 36328us
# 1 over 25us, 198 over 50us
Pi-3
# max = 142761us, average = 21438us
# 278 over 25us, 30 over 50us
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Re: Proposal - drop the GPSD JSON driver
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 : > > > > 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 buffering jitter again. > > You're right, we need to build some test jigs and measure this stuff. > > I'll make a publishable white paper out of it. > -- > http://www.catb.org/~esr/";>Eric S. Raymond > ___ > devel mailing list > devel@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
POLICY: devel@ntpsec.org is the primary channel of developer discussion and coordination
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 changing devops and webapp environments, where a moderate sized team is constantly full time working on a large live "agile" project that is constantly deploying into production. That's not us, that is not the kind of project that NTPsec is. We will continue to operate the existing IRC channel irc:// freenode.net/#ntpsec which is very useful for semi-realtime interaction with the larger interest commnuity, and for public coordination with two or more developers are working in sync. But, again, please continue to consider this email list devel@ntpsec.org to be the primary channel of developer discussion and coordination. Thank you! ..m ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 until we have something better to replace it and/or a cleaned up SHM that we all like? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 driver makes all sorts of non-standard assumptions about how gpsd is configured. A configuration that is contorted and non-obvious to implement. I don't even want to begin to discuss the new bag of worms. So, yes, I now agree, kill it off. Just one thing to remember about the experience, #48 proves that using JSON adds no uncertainty to the time measurements and yields identical results when fed to ntpd. Please do not pull the driver until Eric sees, and agrees, with that result. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 pgpQJdnTa2XUw.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
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 SHM driver running > on a RasPi. I did not get it finished. The experience reminds me that > the #48 driver makes all sorts of non-standard assumptions about how > gpsd is configured. A configuration that is contorted and non-obvious > to implement. > > I don't even want to begin to discuss the new bag of worms. So, yes, > I now agree, kill it off. > > Just one thing to remember about the experience, #48 proves that using > JSON adds no uncertainty to the time measurements and yields identical > results when fed to ntpd. Please do not pull the driver until Eric > sees, and agrees, with that result. > > RGDS > GARY > --- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 > ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
