Hal Murray <[email protected]>:
> 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 mechanisms for this. They're all rather
irrelevant.
> > There's an easy way to take GPSD's heavy computation work out of the budget
> > that we haven't used yet. 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.
>
> I can't figure out what you are trying to do.
>
> 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 modest latency doesn't matter.
Your last sentence is one of the assumptions we're now questioning. I didn't
question it before either, which is why the above hack is not implemented.
As you say, we need to try several methods and measure.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
devel mailing list
[email protected]
http://lists.ntpsec.org/mailman/listinfo/devel
