RE: [ECOS] bogus clock interrupt handling numbers?

[Gary Thomas <gthomas@cygnus.co.uk>]

On 01-Nov-99 Clint Bauer wrote:
> 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?
> 

I think you're misinterpreting 'HAL_CLOCK_READ()'.  This is the number of
raw clock ticks since the last system timer interrupt.  We are using this
measurement to see how long after the actual interrupt takes place until
the system clock value (based on 'cyg_current_time()') changes.  As long
as there are more than one hardware clock ticks (raw clocks going to the
hardware counter before an interrupt occurs), this value can be used for
this measurement.  It doesn't matter how fast we can actually read this
counter (that's what the "overhead" is about), but rather how much it has
changed from the time the interrupt was generated and the time the system
clock value gets updated.

We don't need a base value ('tv0' in your remark) since the 'HAL_CLOCK_READ()'
function is designed to return a positive value 0 <= N < t, where 't' is
the number of raw clocks required to generate an interrupt of the desired
system timer frequency (typically 100Hz).