Indeed, I'm looking forward to getting a few raspberry pis to play with. NTP is but one of the interesting time related projects possible with a $35(us) Linux platform. The system has a number of i/o pins directly exposed that will make interfacing interesting.
On a side note, speaking of deterministic systems, why has no one built a GPSDO with an FPGA yet? Or an NTP server? :) Bob On Apr 5, 2012, at 1:15, MailLists <[email protected]> wrote: > As a rule of thumb, any general purpose architecture will be less effective > at a specific task than a specially designed one. That applies more and more > to the "modern" way of solving tasks: software. > The PC is one of the classical examples of GPA, and as such it is best to > know its limitations, so as to not have exaggerated expectations. > The first limitation, in that specific case, is the way the PPS source is > connected to the system. LinuxPPS tries to optimize it. > The serial port is far from being a precision path, the "newer" > implementations being optimized for throughput (FIFOs) are even worse. Any > additional layer (USB especially) makes things just more and more worse. > As for linux itself, to increase predictability, any disturbing factor should > be minimized, if not eliminated. That would mean especially laptop power > consumption optimization gimmicks, which are useless in a high performance > server/workstation environment (eco, green, and the other trendy > marketingdroid buzzwords are lately more, and more abused for a few percent > power consumption reduction). > The suggested RTOS approach is workable, but it represents just another > example of tweaking a GPA to a specific task, which for a server is usually > not desired. The low latency patches are another example, used usually for > DAWs, but with the reverse side of increased processor loading. > First you must define what your goals, and necessities are, and then optimize > your system for the desired task - here linux is your friend, with its almost > unlimited tweaking options (no comparison to windumb.) Also, don't use a > dumbed down distro, and (learn to) patch/compile your own special kernels > (best stripped down of all useless ballast of a "generic" one). > > > On 4/5/2012 1:22 AM, Mike S wrote: >> I asked this on an NTP list, got some guesses, but no knowledgeable >> responses. >> >> I've got a Trimble Thunderbolt PPS source for NTP, Linux 2.6.35, on a >> quad core CPU. PPS source is coming into a multiport serial card, which >> /proc/interrupts shows is sharing IRQ with some inactive USB ports (IRQ >> 17). It's a PCI-E card, so it would be using MSI interrupts. My >> understanding is that those aren't really "shared," in the traditional >> sense, but IDK. The kernel clocksource is TSC, which is claimed to be >> core invariant on my processor (AMD Athlon II 610e). Changing to HPET >> doesn't help. >> >> Running normally, I'll get about +- 20 us ptp of jitter (as reported by >> ntpq -p, and in loopstats). If I load up the CPU (load average >4 is >> swell), jitter will shrink to +- 1-2 us. I've played around with >> different cpufreq setting, thinking it might be related to the processor >> speed during an IRQ varying, but that seems to have minimal impact >> (performance vs. conservative vs. ondemand). >> >> I've also tried irqbalance, with no change in performance. >> >> So, running a process(es) which keep the CPU completely busy reduces the >> jitter. The busier, the better. Why? I'm guessing it has something to do >> with interrupt latency, but why does a busy CPU make it more consistent >> - I'd expect the opposite? The difference is very obvious. >> >> Is there something else I can do to keep the jitter low? >> >> Aside: Something which I believe was discussed here a few weeks ago - >> clocksource speeds changing between reboots. I patched the kernel to >> allow statically setting the TSC frequency ( >> http://old.nabble.com/-PATCH--tsc_khz%3D-boot-option-to-avoid-TSC-calibration-variance-td23494975.html >> ). This eliminates the semi-random, often 30-40 ppm change in frequency >> reported by NTP between reboots. After tweaking, it's now consistently < >> 1 us, reboots be damned. This should be in the mainline kernel! This >> made no difference to the jitter mentioned above, although non was >> expected. >> >> _______________________________________________ >> time-nuts mailing list -- [email protected] >> To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
