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.
