#Rhealstone Benchmark
3 messages in this thread
Dear DDJ,
I was very interested in your Rhealstone Real-Time Benchmark code in the
April issue. As a result I have developed the Rhealstone code for testing
DESQview using the DESQview C API. Now I am not suggesting that DESQview is
a real-time system but since it implements many of the capabilities of a
real-time systems I was interested in seeing the results.
When I reached the interrupt latency test I was stopped cold. I cannot see
where it measures anything but the CPU cycles to save the stack and perform
the 8254 latch operation. The way the test is constructed there is no
measurement of the operating system induced latency.
Throughout an operating system there are various tables which are updated
continuously. During updates to these tables interrupts are disabled to
prevent erroneous data entry. These disabled periods introduce delays in
responding to interrupts. It is these delays that cause interrupt latency.
The largest latency is typically during the processing of the real-time
clock tick when pre-emptive scheduling is required.
[More]
[Continued]
Actually what is presented is the measurement of the interrupt processing
without an operating system present. This is the time which would be
subtracted from the interrupt processing time with an operating system. The
result would be the latency introduced by the operating system.
Even that might not fully measure the interrupt latency. Some real- time
operating systems directly control the interrupt controller chip. In these
cases the operating system receives the interrupt, determines the level,
and then invokes the user supplied interrupt driver. This mode of operation
would be necessary when additional hardware control was required to ensure
the interrupt driver was available for usage. An example would be in a bank
switched memory environment. The interrupt driver might be in a bank that
was switched out at the time the interrupt occurred. This would require the
operating system to switch in the interrupt driver.
I cannot see how to measure the interrupt latency through software
techniques. By its definition the interrupt latency can only occur when the
operating system is executing. Invoking a software interrupt or even
causing a hardware interrupt (such as raising a serial port control signal
which is looped back into the serial port) from a task are invalid
situations, by definition.
Sincerely, Rudyard Merriam Consultant Compusult, Inc. Houston, Tx.
You're right, it's a hole in the design. However, you can approximate the
latency by building some code around a forced interrupt call to see what
the overhead in the kernel is for a simple task switch. Not accurate, but
it will get you within an order of magnitude.