public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* RE: [ECOS] bogus clock interrupt handling numbers?
@ 1999-11-01 15:54 Clint Bauer
  1999-11-03  9:15 ` Gary Thomas
  0 siblings, 1 reply; 11+ messages in thread
From: Clint Bauer @ 1999-11-01 15:54 UTC (permalink / raw)
  To: ecos-discuss

Sorry to be dense.  The numbers I am seeing for tv[] after 

    // overhead calculations
    for (i = 0;  i < nsamples;  i++) {
        HAL_CLOCK_READ(&tv[i]);
    }

are for instance, 
	tv[0]  = 4
	tv[1]  = 4
	tv[2]  = 4
	...
	tv[31] = 4

This leads to the result of zero ticks of overhead, and seems plausible
given the clock interval period (10 ms for me in this case), and the fact
the other evaluation boards also get this calculation.

For the overhead calculation -

    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]);
    }

The observed values are
	tv[0]  = 19
	tv[1]  = 20
	tv[2]  = 21
	...
	tv[31] = 50

Each value is one greater than previous (you are waiting until the kernel is
informed of a clock increment, before reading the value).  Since there is no
overhead in reading the values, (from first test), the values seem valid to
me.

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

Since the data does not fit the case you are describing (>1 tick), is this
simply not a valid calculation/result?

That would be perfectly acceptable, but three of the boards listed in 
doc\guides\user-guides\sample-numbers.html would then fall into this
category.  

Thanks for your time...


----
Clint Bauer - 972 367 2216 clbauer@intelectinc.com 
Intelect Network Technologies
 

^ permalink raw reply	[flat|nested] 11+ messages in thread
* [ECOS] bogus clock interrupt handling numbers?
@ 1999-11-01 13:51 Clint Bauer
  1999-11-01 14:08 ` Gary Thomas
  0 siblings, 1 reply; 11+ messages in thread
From: Clint Bauer @ 1999-11-01 13:51 UTC (permalink / raw)
  To: 'ecos-discuss@sourceware.cygnus.com'

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
 

^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~1999-11-05 13:21 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-11-01 15:54 [ECOS] bogus clock interrupt handling numbers? Clint Bauer
1999-11-03  9:15 ` Gary Thomas
1999-11-03  9:57   ` [ECOS] Turning off gdb Lance Uyehara
1999-11-05 11:12     ` Lance Uyehara
1999-11-05 12:39       ` Jonathan Larmour
1999-11-05 12:59         ` Lance Uyehara
1999-11-05 13:08           ` Gary Thomas
1999-11-05 13:13             ` Lance Uyehara
1999-11-05 13:21               ` Gary Thomas
  -- strict thread matches above, loose matches on Subject: below --
1999-11-01 13:51 [ECOS] bogus clock interrupt handling numbers? Clint Bauer
1999-11-01 14:08 ` Gary Thomas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).