On Tue, 05 Apr 2005 09:33:00 +1200, Evan Hillas <evanh@clear.net.nz> wrote:
I don’t know speed of Jochen’s CPU but I know I got at least 40us peak
jitter on my 500MHz K6-2 using InterruptAttach(), the average was more
like 5us. I can imagine a slower PC using an OS timer would approach
the 400us mark no trouble.
The real cause seems to be just the instrumented kernel doing it’s job.
An ISR would most likely have priority over such logging so having the
critical code in an ISR would be a temporary work-around or even final
solution depending on how comfortable the project is with such coding.
Well, put it this way:
I tried the code (without the instrumented kernel) on a
PC104 Pentium I 166 MHz.
Added some code to toggle a printer port data line
every time the pulse was received, put a logic analyser on it.
Pulse train of 500 Hz is seen. (1ms high, 1ms low)
(With only a few microseconds jitter either way, by the way,
just as expected).
Set triggering to detect a low level for >1 ms.
With the original code, analyzer triggers every few seonds.
With the modified code, triggers … never.
There may be other things happening on the specific
hardware and other processes running e.g. tracelogger,
but with the pulse delivery mechanism on an unloaded
properly configured system, there is nothing that can
cause 400 us jitter.
I would first remove this obvious reason for the pulse being
“lost”, & see if the OS still goes away for 400us.
If it is SMI, even hooking to an IRQ will not help things…
Instrumented kernel will have been written very carefully
to minimise affecting the sysem under test, otherwise it will
be of limited usefulness.
I just don’t want this thread to stand unchallenged
that the OS can just go away for 400 us for no reason
with a simple 2 thread program as shown.
Been burned by this before…