* 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; 9+ 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] 9+ messages in thread
* RE: [ECOS] bogus clock interrupt handling numbers? 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 0 siblings, 1 reply; 9+ 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] 9+ messages in thread
* [ECOS] Turning off gdb 1999-11-03 9:15 ` Gary Thomas @ 1999-11-03 9:57 ` Lance Uyehara 1999-11-05 11:12 ` Lance Uyehara 0 siblings, 1 reply; 9+ messages in thread From: Lance Uyehara @ 1999-11-03 9:57 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] Turning off gdb 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 0 siblings, 1 reply; 9+ messages in thread From: Lance Uyehara @ 1999-11-05 11:12 UTC (permalink / raw) To: ecos-discuss 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 > > > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] Turning off gdb 1999-11-05 11:12 ` Lance Uyehara @ 1999-11-05 12:39 ` Jonathan Larmour 1999-11-05 12:59 ` Lance Uyehara 0 siblings, 1 reply; 9+ messages in thread From: Jonathan Larmour @ 1999-11-05 12:39 UTC (permalink / raw) To: Lance Uyehara; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] Turning off gdb 1999-11-05 12:39 ` Jonathan Larmour @ 1999-11-05 12:59 ` Lance Uyehara 1999-11-05 13:08 ` Gary Thomas 0 siblings, 1 reply; 9+ messages in thread From: Lance Uyehara @ 1999-11-05 12:59 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-discuss 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 > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] Turning off gdb 1999-11-05 12:59 ` Lance Uyehara @ 1999-11-05 13:08 ` Gary Thomas 1999-11-05 13:13 ` Lance Uyehara 0 siblings, 1 reply; 9+ messages in thread From: Gary Thomas @ 1999-11-05 13:08 UTC (permalink / raw) To: Lance Uyehara; +Cc: ecos-discuss 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 >> >> > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] Turning off gdb 1999-11-05 13:08 ` Gary Thomas @ 1999-11-05 13:13 ` Lance Uyehara 1999-11-05 13:21 ` Gary Thomas 0 siblings, 1 reply; 9+ messages in thread From: Lance Uyehara @ 1999-11-05 13:13 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss 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 >>> >>> >> > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [ECOS] Turning off gdb 1999-11-05 13:13 ` Lance Uyehara @ 1999-11-05 13:21 ` Gary Thomas 0 siblings, 0 replies; 9+ messages in thread From: Gary Thomas @ 1999-11-05 13:21 UTC (permalink / raw) To: Lance Uyehara; +Cc: ecos-discuss 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 >>>> >>>> >>> >> >> > ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1999-11-05 13:21 UTC | newest] Thread overview: 9+ 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
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).