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@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.
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@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.
