Fred Wright via devel writes: > I get a kick out of you guys fussing over "thermal stability" when the > largest source of time error is the interrupt latency in timing the PPS > signal.
The median interrupt latency shows up as an additional offset on top of other such offsets. The variability on that latency gets filtered pretty nicely by ntpd, especially the long tail at large latencies. Now, interrupts never have been a particularly strong point for ARM, I give you that. > Just because you can't see the error in the graphs doesn't mean > it isn't there. :-) Again, that number isn't materially affecting the frequency stability, only the time offset. If you look at that, you will quickly find that your assertion of thermal effects getting dominated by the interrupt latency is wrong. > On the Beaglebone, it's typically around 15us with the > CPU running at 1GHz, going up to around 42us at 300MHz. It's directly > measurable because the "real" PPS timing is via counter capture, with a > total capture uncertainty (the equivalent of NTP RTT) of typically 583ns > at 1GHz and 1083ns at 300MHz. If you have histograms, I'd like to see them. But that seems to be in the right ballpark. Note that you could do something similar by running the PPS capture on the VC4 instead of ARM subsystem, but that part of the rasPi is woefully under-documented. In principle the hardware should allow capturing PPS at up to 250MHz and sending the timestamp via mailbox to the ARM is not timing-critical at all. If you wanted to eliminate that, you'd better use an FPGA or some other microcontroller that has capture units and hardware timestamps for the NIC. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
