There are a lot of problems here. I'm not even sure where to start, but here goes. ;)
I suspect if you keep within the input period, ie, of 1pps you may not see long term problems. All the pase shifting will average out to 1 in the long run. 1 second is a lot of time for a PC to miss, but it could theoretically happen. Consider a page out pr fault in combination with and idle cpu and idle disk, or worse powered down disk.--that would be very expensive and you may see a second or more with no signal, then all the signals show up in a very tight window. Back to the problem, breaking the 1pps down as far as 10micro seconds,The most obviously problem is that you are trying to use an inaccurate clock source(the pc) to sample a precise and accurate source. --A PC is not a frequency standard so it can't be used for (2/f) ..(3/f) ..(n/f) measurements. After if it could do this, we would see PC based high precision and accuracy frequency standards. One way to achieve your goal is to use a higher source frequency standard to drive a cacheless microcontroller(most like a low end 8bit model), derive a precision timer from the high frequency source, log the 1pps signal and apply a time stamp to each sample. Pull those samples via USB/Serial, whatever... Though this all defeats the purpose of NTP doesn't it? I think the simple answer here is that PC architecture is not intended for such precise, accurate measurements. Steve Trying to tweak a PC to get 10microseconds (nyquist, 5microseconds max)... I don't think you'll ever do it, or at least not in a way that can be peer reviewed. On Wed, Apr 4, 2012 at 6:22 PM, Mike S <[email protected]> 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.
