* [ECOS] bogus clock interrupt handling numbers?
@ 1999-11-01 13:51 Clint Bauer
1999-11-01 14:08 ` Gary Thomas
0 siblings, 1 reply; 4+ 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] 4+ messages in thread
* RE: [ECOS] bogus clock interrupt handling numbers?
1999-11-01 13:51 [ECOS] bogus clock interrupt handling numbers? Clint Bauer
@ 1999-11-01 14:08 ` Gary Thomas
0 siblings, 0 replies; 4+ messages in thread
From: Gary Thomas @ 1999-11-01 14:08 UTC (permalink / raw)
To: Clint Bauer; +Cc: ecos-discuss
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).
^ permalink raw reply [flat|nested] 4+ messages in thread
* 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; 4+ 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] 4+ messages in thread
* RE: [ECOS] bogus clock interrupt handling numbers?
1999-11-01 15:54 Clint Bauer
@ 1999-11-03 9:15 ` Gary Thomas
0 siblings, 0 replies; 4+ messages in thread
From: Gary Thomas @ 1999-11-03 9:15 UTC (permalink / raw)
To: Clint Bauer; +Cc: ecos-discuss
On 01-Nov-99 Clint Bauer wrote:
> 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.
>
No, you misunderstand these calculations. I'm sorry that the nomenclature
is confusing but I'll try again.
eCos has a system clock which is running [typically] at 100Hz. This "clock"
is based on some hardware device, normally a timer of some sort. The timer
typically is being driven by hardware "ticks" - signals that tell it to count
up or down - at some rate. This rate is normally *much* higher than 100Hz.
Thus, we program the timer in such a way that the system gets an interrupt
after some number of these hardware "ticks" have occurred. If the hardware
timer was running at 1MHz, then we would use a value of 10000 ticks / interrupt.
The 'HAL_CLOCK_READ()' function is a way of reading this hardware timer. It
is designed to return the number of hardware "ticks" since the last interrupt.
Thus, in this example, it could have a value from 0..9999, representing (again
in this idealized example) time from 0us to 9999us since the last interrupt.
'tm_basic' uses this value to calculate a number of critical timings. Using
this value, we can measure the overhead involved in certain operations, such
as a "C" function call, a loop, etc. On some systems though, the CPU may be
capable of executing many of these functions faster than the hardware timer
"ticks". The JMR3904 can execute a large number of instructions within the
span of a single tick, thus you get the overhead value of 0. Some care is
taken to reduce the error inherant in these calculations, such as performing
a measured calculations a large number of times and taking the average. Also,
most values calculated/used within 'tm_basic' are actually in nano-seconds
(1e-9), with the results converted to micro-seconds (1e-6) for display.
The problem with the nomenclature is that sometimes "ticks" (as I have just
described them) are called "clocks", and timer interrupts are called "ticks",
and so on. It can be quite confusing.
> 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.
>
I just tried this on the JMR3904 in our test farm. Here are the values I saw:
Reading the hardware clock takes 0 'ticks' overhead
... this value will be factored out of all other measurements
Sample 0: 43
Sample 1: 49
Sample 2: 39
Sample 3: 39
Sample 4: 39
Sample 5: 39
Sample 6: 42
Sample 7: 39
Sample 8: 39
Sample 9: 39
Sample 10: 39
Sample 11: 41
Sample 12: 39
Sample 13: 39
Sample 14: 39
Sample 15: 39
Sample 16: 42
Sample 17: 39
Sample 18: 39
Sample 19: 39
Sample 20: 39
Sample 21: 41
Sample 22: 39
Sample 23: 39
Sample 24: 39
Sample 25: 39
Sample 26: 42
Sample 27: 39
Sample 28: 39
Sample 29: 39
Sample 30: 39
Sample 31: 41
Clock interrupt took 25.98 microseconds (39 raw clock ticks)
As you can see, the result of 'HAL_CLOCK_READ(&tv[i])' are nearly
constant, not ascending. These values represent the number of hardware
"ticks" to the timer since the last interrupt. This is a useful
[and fairly accurate] indication of how long the clock interrupt
processing takes.
If you don't see values like this, we need to know. What version of
eCos are you using/testing from? (My values are based on the latest
version which is available from sourceware.cygnus.com).
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-11-03 9:15 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-11-01 13:51 [ECOS] bogus clock interrupt handling numbers? Clint Bauer
1999-11-01 14:08 ` Gary Thomas
1999-11-01 15:54 Clint Bauer
1999-11-03 9:15 ` 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).