On Thu, Oct 20, 2016 at 12:02 AM, Gary E. Miller <g...@rellim.com> wrote:
I think your graph only shows 1/2 of the problem. It is the easy part because all that code is written and likely already installed on the OP's computer. The other half of the problem is responding to events and getting them time stamped with very low latency and jitter. In other words the harder job is actually putting to use that well sync's internal clock. I think the best way is to copy the design of the Linux PPS system. Then assume the error in time stamp is a little larger than double your graph. But if the event time stamp code is not so well designed the results might to 10X worse not just 2x worse. > How about a graph, or two? See attached. From the histogram, I suspect > the > granularity is about 200 nano sec. From the offset graph you can > see how the offset jumps. > > Here is the offset data on PPS v. the system clock: > Percentiles...... > Min 1% 5% 50% 95% 99% Max > -21.645 -2.587 -0.834 -0.020 0.991 0.991 13.557 µs > > Ranges...... > 90% 95% StdDev Mean Units > 1.825 5.318 0.850 -0.006 µs > > Or see a lot more live graphs here: https://pi4.rellim.com/day/ > > > RGDS > GARY > ------------------------------------------------------------ > --------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > g...@rellim.com Tel:+1 541 382 8588 > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/m > ailman/listinfo/time-nuts > and follow the instructions there. > -- Chris Albertson Redondo Beach, California _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.