[time-nuts] NTP jitter with Linux

Hal Murray hmurray at megapathdsl.net
Thu Apr 5 18:11:20 UTC 2012


My guess on the original question is that keeping the CPU busy puts junk into 
the cache so the whole interrupt processing path takes every possible cache 
miss.  NTP doesn't care how fast that code is as long as it's consistent.  
(Of course, you probably get a different answer, but we are discussing jitter 
rather than accuracy.)

If you want to investigate, you might hack the interrupt code to flap one of 
the printer port pins and put a scope on that, triggered from the PPS input 
signal.

Another hack would be to log all the PPS samples and make a histogram.


iteration69 at gmail.com said:
> If the architecture has cache or wait states, it is still subject to be a
> moving target. I'm naturally skeptical on all architectures that have
> multiple channels, show me an architecture with cache or waits states and
> i'll show you a problem ( in regards to real time, that is)

> I stand firm that the only proper way to do this is with a 100%
> deterministic architecture. 

If you find the right people, they can probably explain a lot of the details 
associated with this sort of problem.  With the complexity of modern systems, 
it's likely to take more than one person.  You probably need somebody who 
knows the hardware details of the system you are running on, somebody who 
knows the OS, and maybe even a compiler and/or library wizard.

Years ago, I showed some memory performance graphs to a couple of senior 
compiler geeks.  I thought I understood most of what was going on, but they 
dived in and started discussing minor bumps that I hadn't even paid attention 
to.  I remember one comment that was roughly, "We fixed that bug last week."


-- 
These are my opinions, not necessarily my employer's.  I hate spam.







More information about the Time-nuts_lists.febo.com mailing list