From mboxrd@z Thu Jan  1 00:00:00 1970
From: Clint Bauer <CLBAUER@INTELECTINC.COM>
To: ecos-discuss@sourceware.cygnus.com
Subject: RE: [ECOS] bogus clock interrupt handling numbers?
Date: Mon, 01 Nov 1999 15:54:00 -0000
Message-id: <56F9E4591D75D211885500600865B50675365A@MAIL.INTELECTINC.com>
X-SW-Source: 1999-11/msg00003.html

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