e...@thyrsus.com said: >> My strawman for REFCLOCKD is something like the touring test. >> You can't tell the difference by poking around with ntpq. (Maybe >> you don't get to poke too deep.)
> It'd need its own UDP port. I don't understand. All I was trying to say is that splitting out the refclock drivers to another process shouldn't make any difference that is easily visible. --------- > I like Unix named pipes for this kind of scenario. They're very > straightforward, no buffering or hidden magic, no interaction with the > network code (thus no possibility of remote exploits), and an ironclad > atomicity if you keep your writes 512 bytes or below. Sounds good. I suspect the hard part will be coordinating start/stop/crash/recovery. How do we get 2 processes to read the same data? -------- [kernel PLL] > This is an area I don't understand well. But I'm willing to learn. ntpd is a PLL tuned for network time scales. Ages ago, they put another PLL into the kernel. It works off PPS with different tuning parameters. It works significantly better. I think we should be able to do as well from userland. The idea is to get a wakeup from the PPS logic, grab the data, do the same math, then reach back into the kernel via ntp_adjtime. With modern processors, that should be a tiny fraction of a second and thus very close to what the kernel would have done. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
