On 2012-11-15, David Taylor <david-tay...@blueyonder.co.uk.invalid> wrote: > On 15/11/2012 07:22, unruh wrote: > [] >> Actually more like 2 microseconds accuracy should be possible, unless >> the Raspberry Pi's servicing of the GPIO interrupt is really very bad. >> >>> >>> http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html >> >> Nice page. > > Glad you liked the write-up. Just some notes for myself, really! > > If you search for "latency" here: > > http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=13883 > > "jbeale" says: "My experiments with NTP-PPS timing in the 3.1.9 kernel > with a relatively unloaded system indicate that my R-Pi has an interrupt > latency ranging between 10 and 80 microseconds, and occasionally gets as > long as 150 microseconds (see below)"
Hm. Looks pretty bad. I once did tests with a 300MHz Linux machine, where I would send out a signal on one of the output pins on the parallel port, reading the time at which I did so, and then read in the time on the Ack interrupt driven pin and found delays typically of 1-2 microseconds (timing only to the microsecond due to the clock reading function I used). That he seems to be betting up to 150us delay is really bad. > > and provides a graph of some values he has seen. I haven't made any > direct measurements. On my system here, the offsets reported by NTP are > less, but it would not show any fixed interrupt latency. It's all well > within the 10 milliseconds requirement, of course. > > http://www.satsignal.eu/ntp/2012-11-01-02-03-raspi1_ntp-day.png > http://www.satsignal.eu/ntp/2012-11-08-09-10-raspi1_ntp-day.png > > with glitches due to restarts. Zero offset is plotted as 20 microseconds. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions