On Thu, 20 May 2010, Nikolay Marusov wrote:
Does anyboby know why DSR latency and thead resuming time may SUDDENLY increase?
Hi Nikolay, There are important notes about influences on performance in the eCos documentation: http://ecos.sourceware.org/docs-latest/ref/kernel-characterization.html So, what would pend your DSRs you have to dig by yourself. [snip]
Beside all, it is interesting what may delay THE MOST PRIOTITY interrupt handler and thread? Maybe eCos scheduler is not so determinate?
The eCos `tm_basic` test is a good source to get own testcase and get a clue. First, what DSR/ISR latency/deviation you get for real-time clock timer in the test for your target? (RT ISR handler has the highest ISR priority by default). Import the below (to measure and RT clock ISR latency), build and run `tm_basic` test on your target. cdl_option CYGVAR_KERNEL_COUNTERS_CLOCK_LATENCY { user_value 1 }; Perhaps, you need to increase NSAMPLES value to get more continuous run of the test. Note: you may get differ results for the differ types of startup (ROM, RAM. GDB, etc.) and differ compiler optimization levels. Well, tm_basic with alone RT ISR/DSR != your_app. But looking on its output (ideal world) you will be know what you would expect for real world. I'm sorry, we can only guess about your DSR "issue". For example, if your program has continuous sections where scheduler locks itself those can pend your DSR sometimes, etc. Try bitmap scheduler if you can. Investigate! :-) Sergei -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss