[time-nuts] NTP jitter with Linux

[MailLists]

Nice toy, but the question of the necessity of a fully fledged OS for 
most tasks thrown at such a small system still remains (integrated 
network connectivity is a plus).
NTP isn't capable to improve the precision of a system's clock, as it 
works over a heterogeneous path, which is quite unpredictable (NTP being 
specifically optimized to compensate for such effects). It can only 
improve the long term accuracy, similarly to a GPSDO. If the internal 
clock of the system to get synchronized isn't precise enough, NTP won't 
help.
While FPGAs excel at high throughput/parallel processing, the GPSDO 
process is mostly a quite slow one (with the notable exception of phase 
comparison - for which a CPLD is more than enough), so they would be 
overkill. A NTP server needs a network stack, and those are mostly 
included in full OSs - there are some small uC ones, but it's debatable 
if such a uC is capable of servicing more requests, and/or having a low 
enough and predictable processing overhead.
There are a few implementations of linux systems in a FPGA, but a bigger 
uC/SoC would be enough for such a task, costs being another factor - 
that task would fit nicely a PI.


On 4/5/2012 8:36 AM, Gmail wrote:
> 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<lists at medesign.ro>  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 -- time-nuts at febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.