This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
bogus clock interrupt handling numbers?
- To: "'ecos-discuss at sourceware dot cygnus dot com'" <ecos-discuss at sourceware dot cygnus dot com>
- Subject: [ECOS] bogus clock interrupt handling numbers?
- From: Clint Bauer <CLBAUER at INTELECTINC dot COM>
- Date: Mon, 1 Nov 1999 15:51:22 -0600
I was trying to confirm/duplicate the numbers from the tests run from
tm_basic.cxx. In looking at the code, the following looks really suspicious
--
(from run_all_tests())
// Try and measure how long the clock interrupt handling takes
for (i = 0; i < nsamples; i++) {
tick0 = cyg_current_time();
while (true) {
tick1 = cyg_current_time();
if (tick0 != tick1) break;
}
HAL_CLOCK_READ(&tv[i]);
}
tv1 = 0;
for (i = 0; i < nsamples; i++) {
tv1 += tv[i] * 1000;
}
tv1 = tv1 / nsamples;
tv1 -= overhead; // Adjust out the cost of getting the timer value
diag_printf("Clock interrupt took");
show_ticks_in_us(tv1);
diag_printf(" microseconds (%d raw clock ticks)\n", tv1/1000);
Granted, the comment does say _Try_. But for those targets that can read
the hardware clock with 0 ticks of latency (the Toshiba JMR3904 Evaluation
Board, for instance), the above code reduces to just computing the median of
the
clock samples.
No account is made of the start of the test run, as is done in the
computation of tv0, immediately before the code segment copied above.
Am I missing something obvious, or is this a feature?
----
Clint Bauer - 972 367 2216 clbauer@intelectinc.com
Intelect Network Technologies