e...@thyrsus.com said: > 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.
I was never interested in JSON in SHM. 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.) > 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. I'd expect the latency to get interesting if you are doing something like minpoll=0. With longer polling the "latency" between collecting the data and actually using it is already over a second except for the last sample. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
