On 02/07/2014 11:39 AM, Sebastian Huber wrote:
On 2014-02-06 17:09, Joel Sherrill wrote:
Hi
In investigating Jennifer's SMP test failure issues, it appears
that a combination of the backtrace only including global
symbols and the lengthy test execution time make these
pretty unsuitable on a simulator.
Daniel was nice enough to gather some data for us on smplock01
+ 1 minute on 200 Mhz NGMP w/L2 holding the entire application
- expected to be 4x faster than LEON3
+ ~10 minutes for dual core on GRSIM
- expected to be at least 20 if quad-core
Daniel projected/guessed 10-15s on a 1.2Ghz QorIQ
The test uses 10 seconds per test case:
http://git.rtems.org/rtems/tree/testsuites/smptests/smplock01/init.c?id=893d66937a17c4bb9fb3b909cf884948b466a3b5#n341
So on real targets it runs 50 seconds no matter how fast it is. On a simulator
it depends on the host processor.
Ok. That means that the execution time is dependent on the system clock? If that's the case then we could try to lower the frequency of the simulated LEON in GRSIM, that way the clocks/instructions
per clock tick will be lower, thus executes faster. Joel you can try starting GRSIM with 'grsim -freq 5' to run a LEON system of 5MHz, that you be much faster is my guess :)
Can the longer running tests be scaled back in execution time and
meet their goals?
The longer they run the more likely it is to catch sporadic errors.
That is true.
Daniel
We plan to provide execution times for all as a reference point.
--
Daniel Hellstrom
Software Section Head
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kungsgatan 12
SE-411 19 Gothenburg, Sweden
Phone: +46 31 7758657
dan...@gaisler.com
www.Aeroflex.com/Gaisler
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
