RE: [ECOS] bogus clock interrupt handling numbers?

RE: [ECOS] bogus clock interrupt handling numbers?

[Clint Bauer]

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
 

RE: [ECOS] bogus clock interrupt handling numbers?

[Gary Thomas]

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

[ECOS] Turning off gdb

[Lance Uyehara]

I'm trying to build a minimum sized ecos codeset, and have run into some
odd behavior in the configuration tool. 

Since CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT and
CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT require each other, I can't turn off
either without crashing the configuration tool (in win32).

But I look in the .cfg file and see nothing which I associate with these
settings. So how can I turn this off in the configuration tool?

Thanks,
Lance

Re: [ECOS] Turning off gdb

[Lance Uyehara]

My original question went unanswered.

I guess the real question is what are the names of the things to put into
the .cfg file to turn off settings in the configuration tool (win32). Using
-enable and -disable.

Am I to assume no one knows how to do this, or it's so obvious that no one
took the time to reply? It's quite possible the answer is rtfm but I
couldn't find it anywhere. Even a pointer to where to look would be nice.

Help please...

Thanks,
Lance

At 09:55 AM 11/3/99 -0800, Lance Uyehara wrote:
>I'm trying to build a minimum sized ecos codeset, and have run into some
>odd behavior in the configuration tool. 
>
>Since CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT and
>CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT require each other, I can't turn off
>either without crashing the configuration tool (in win32).
>
>But I look in the .cfg file and see nothing which I associate with these
>settings. So how can I turn this off in the configuration tool?
>
>Thanks,
>Lance
>
>
>
>
>

Re: [ECOS] Turning off gdb

[Jonathan Larmour]

Lance Uyehara wrote:
> At 09:55 AM 11/3/99 -0800, Lance Uyehara wrote:
> >I'm trying to build a minimum sized ecos codeset, and have run into some
> >odd behavior in the configuration tool.
> >
> >Since CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT and
> >CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT require each other, I can't turn off
> >either without crashing the configuration tool (in win32).

It crashes the config tool? Obviously that shouldn't happen. Does it
actually cause an application error? What if you disable "Suggest fixes for
consistency check failures" under Tools->Options, does that allow you to
unset them both? Or possibly set the "Check rules" in the same place to
"Never".

What *should* happen is that disabling one of them should pop up a dialog
box saying something like "Yadayada requires foobarfoobar, disable? Yes/No"

> >But I look in the .cfg file and see nothing which I associate with these
> >settings. So how can I turn this off in the configuration tool?
>
> I guess the real question is what are the names of the things to put into
> the .cfg file to turn off settings in the configuration tool (win32). Using
> -enable and -disable.

When you have saved the configuration, you can manually edit the options by
going into the build tree directory (i.e. the place you saved the
configuration), and editting the pkgconf/hal.h file. The two options you are
after can be disabled in there.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] Turning off gdb

[Lance Uyehara]

At 08:39 PM 11/5/99 +0000, Jonathan Larmour wrote:
>Lance Uyehara wrote:
>> At 09:55 AM 11/3/99 -0800, Lance Uyehara wrote:
>> >I'm trying to build a minimum sized ecos codeset, and have run into some
>> >odd behavior in the configuration tool.
>> >
>> >Since CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT and
>> >CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT require each other, I can't turn
off
>> >either without crashing the configuration tool (in win32).
>
>It crashes the config tool? Obviously that shouldn't happen. Does it
>actually cause an application error? What if you disable "Suggest fixes for
>consistency check failures" under Tools->Options, does that allow you to
>unset them both? Or possibly set the "Check rules" in the same place to
>"Never".

Selecting "Never" allows me to change both places.

Thanks for the help.

-Lance

>
>What *should* happen is that disabling one of them should pop up a dialog
>box saying something like "Yadayada requires foobarfoobar, disable? Yes/No"
>
>> >But I look in the .cfg file and see nothing which I associate with these
>> >settings. So how can I turn this off in the configuration tool?
>>
>> I guess the real question is what are the names of the things to put into
>> the .cfg file to turn off settings in the configuration tool (win32). Using
>> -enable and -disable.
>
>When you have saved the configuration, you can manually edit the options by
>going into the build tree directory (i.e. the place you saved the
>configuration), and editting the pkgconf/hal.h file. The two options you are
>after can be disabled in there.
>
>Jifl
>-- 
>Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
>"I used to have an open mind but || Get yer free open source RTOS's here...
> my brains kept falling out."    || http://sourceware.cygnus.com/ecos
>Help fight spam! http://spam.abuse.net/  These opinions are all my own fault
>
>

Re: [ECOS] Turning off gdb

[Gary Thomas]

BTW - what version of Windows are you running?  "in win32" doesn't really
say much.  

On 05-Nov-99 Lance Uyehara wrote:
> At 08:39 PM 11/5/99 +0000, Jonathan Larmour wrote:
>>Lance Uyehara wrote:
>>> At 09:55 AM 11/3/99 -0800, Lance Uyehara wrote:
>>> >I'm trying to build a minimum sized ecos codeset, and have run into some
>>> >odd behavior in the configuration tool.
>>> >
>>> >Since CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT and
>>> >CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT require each other, I can't turn
> off
>>> >either without crashing the configuration tool (in win32).
>>
>>It crashes the config tool? Obviously that shouldn't happen. Does it
>>actually cause an application error? What if you disable "Suggest fixes for
>>consistency check failures" under Tools->Options, does that allow you to
>>unset them both? Or possibly set the "Check rules" in the same place to
>>"Never".
> 
> Selecting "Never" allows me to change both places.
> 
> Thanks for the help.
> 
> -Lance
> 
>>
>>What *should* happen is that disabling one of them should pop up a dialog
>>box saying something like "Yadayada requires foobarfoobar, disable? Yes/No"
>>
>>> >But I look in the .cfg file and see nothing which I associate with these
>>> >settings. So how can I turn this off in the configuration tool?
>>>
>>> I guess the real question is what are the names of the things to put into
>>> the .cfg file to turn off settings in the configuration tool (win32). Using
>>> -enable and -disable.
>>
>>When you have saved the configuration, you can manually edit the options by
>>going into the build tree directory (i.e. the place you saved the
>>configuration), and editting the pkgconf/hal.h file. The two options you are
>>after can be disabled in there.
>>
>>Jifl
>>-- 
>>Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
>>"I used to have an open mind but || Get yer free open source RTOS's here...
>> my brains kept falling out."    || http://sourceware.cygnus.com/ecos
>>Help fight spam! http://spam.abuse.net/  These opinions are all my own fault
>>
>>
> 

Re: [ECOS] Turning off gdb

[Lance Uyehara]

At 02:30 PM 11/5/99 -0700, Gary Thomas wrote:
>BTW - what version of Windows are you running?  "in win32" doesn't really
>say much.  

I'm running win98. I was specifying win32 because I didn't want to get a
bunch of replies regarding how to do this in linux.

I'm running configuration tool 1.2.9 if that helps you guys to eliminate
the crash.

-Lance

>
>On 05-Nov-99 Lance Uyehara wrote:
>> At 08:39 PM 11/5/99 +0000, Jonathan Larmour wrote:
>>>Lance Uyehara wrote:
>>>> At 09:55 AM 11/3/99 -0800, Lance Uyehara wrote:
>>>> >I'm trying to build a minimum sized ecos codeset, and have run into some
>>>> >odd behavior in the configuration tool.
>>>> >
>>>> >Since CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT and
>>>> >CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT require each other, I can't turn
>> off
>>>> >either without crashing the configuration tool (in win32).
>>>
>>>It crashes the config tool? Obviously that shouldn't happen. Does it
>>>actually cause an application error? What if you disable "Suggest fixes for
>>>consistency check failures" under Tools->Options, does that allow you to
>>>unset them both? Or possibly set the "Check rules" in the same place to
>>>"Never".
>> 
>> Selecting "Never" allows me to change both places.
>> 
>> Thanks for the help.
>> 
>> -Lance
>> 
>>>
>>>What *should* happen is that disabling one of them should pop up a dialog
>>>box saying something like "Yadayada requires foobarfoobar, disable? Yes/No"
>>>
>>>> >But I look in the .cfg file and see nothing which I associate with these
>>>> >settings. So how can I turn this off in the configuration tool?
>>>>
>>>> I guess the real question is what are the names of the things to put into
>>>> the .cfg file to turn off settings in the configuration tool (win32).
Using
>>>> -enable and -disable.
>>>
>>>When you have saved the configuration, you can manually edit the options by
>>>going into the build tree directory (i.e. the place you saved the
>>>configuration), and editting the pkgconf/hal.h file. The two options you
are
>>>after can be disabled in there.
>>>
>>>Jifl
>>>-- 
>>>Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223)
728762
>>>"I used to have an open mind but || Get yer free open source RTOS's here...
>>> my brains kept falling out."    || http://sourceware.cygnus.com/ecos
>>>Help fight spam! http://spam.abuse.net/  These opinions are all my own
fault
>>>
>>>
>> 
>
>

Re: [ECOS] Turning off gdb

[Gary Thomas]

Sadly, this is a known problem.

The ConfigTool is only officially supported on Windows/NT.
It is known to have problems, including crashing, on Windows/9x.

On 05-Nov-99 Lance Uyehara wrote:
> At 02:30 PM 11/5/99 -0700, Gary Thomas wrote:
>>BTW - what version of Windows are you running?  "in win32" doesn't really
>>say much.  
> 
> I'm running win98. I was specifying win32 because I didn't want to get a
> bunch of replies regarding how to do this in linux.
> 
> I'm running configuration tool 1.2.9 if that helps you guys to eliminate
> the crash.
> 
> -Lance
> 
>>
>>On 05-Nov-99 Lance Uyehara wrote:
>>> At 08:39 PM 11/5/99 +0000, Jonathan Larmour wrote:
>>>>Lance Uyehara wrote:
>>>>> At 09:55 AM 11/3/99 -0800, Lance Uyehara wrote:
>>>>> >I'm trying to build a minimum sized ecos codeset, and have run into some
>>>>> >odd behavior in the configuration tool.
>>>>> >
>>>>> >Since CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT and
>>>>> >CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT require each other, I can't turn
>>> off
>>>>> >either without crashing the configuration tool (in win32).
>>>>
>>>>It crashes the config tool? Obviously that shouldn't happen. Does it
>>>>actually cause an application error? What if you disable "Suggest fixes for
>>>>consistency check failures" under Tools->Options, does that allow you to
>>>>unset them both? Or possibly set the "Check rules" in the same place to
>>>>"Never".
>>> 
>>> Selecting "Never" allows me to change both places.
>>> 
>>> Thanks for the help.
>>> 
>>> -Lance
>>> 
>>>>
>>>>What *should* happen is that disabling one of them should pop up a dialog
>>>>box saying something like "Yadayada requires foobarfoobar, disable? Yes/No"
>>>>
>>>>> >But I look in the .cfg file and see nothing which I associate with these
>>>>> >settings. So how can I turn this off in the configuration tool?
>>>>>
>>>>> I guess the real question is what are the names of the things to put into
>>>>> the .cfg file to turn off settings in the configuration tool (win32).
> Using
>>>>> -enable and -disable.
>>>>
>>>>When you have saved the configuration, you can manually edit the options by
>>>>going into the build tree directory (i.e. the place you saved the
>>>>configuration), and editting the pkgconf/hal.h file. The two options you
> are
>>>>after can be disabled in there.
>>>>
>>>>Jifl
>>>>-- 
>>>>Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223)
> 728762
>>>>"I used to have an open mind but || Get yer free open source RTOS's here...
>>>> my brains kept falling out."    || http://sourceware.cygnus.com/ecos
>>>>Help fight spam! http://spam.abuse.net/  These opinions are all my own
> fault
>>>>
>>>>
>>> 
>>
>>
> 

RE: [ECOS] bogus clock interrupt handling numbers?

[Gary Thomas]

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

[ECOS] bogus clock interrupt handling numbers?

[Clint Bauer]

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