<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 11/26/2014 1:12 AM, Sebastian Huber
wrote:<br>
</div>
<blockquote cite="mid:54757D41.8010707@embedded-brains.de"
type="cite">
<pre wrap="">On 25/11/14 23:25, Joel Sherrill wrote:
</pre>
<blockquote type="cite">
<pre wrap="">How long is this test supposed to run?
It takes 4:42 using sis on my computer which is a 2.9 Ghz i7 .
</pre>
</blockquote>
<pre wrap="">
SIS is a slow simulator. On Qemu it runs much faster.
</pre>
</blockquote>
To repeat a statement by Jiri, SIS is an accurate simulator. Just<br>
a different goal.<br>
<blockquote cite="mid:54757D41.8010707@embedded-brains.de"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
Is there anything to do? Split it?
</pre>
</blockquote>
<pre wrap="">
Splitting it up doesn't reduce the overall test time. The test cases in
this test are standard test cases. I am not so fond of removing them,
but in case the test time is too long for you then you can drop the ones
with the many rounds.
</pre>
</blockquote>
I took the statement "doesn't reduce overall test time" earlier at
face value<br>
and didn't push back. It is a true statement to the extent that
splitting<br>
it results in N tests which run for the same combined time. But what<br>
was missed is that the run-time of this test is much longer than any<br>
other test. This results in having to set a timeout value that
accommodates<br>
this test while others could be timed out in the equivalent of 180<br>
seconds of CPU time.<br>
<br>
Thus it isn't the test time itself that is the problem. It is the
impact<br>
it has on setting the overall timeout value since this single test<br>
runs for 309.51s of simulated CPU time according to sis. Every test<br>
which times out is bound by the maximum allowed execution time<br>
of the slowest tests.<br>
<br>
RTEMS suffers from having many unwritten rules. Originally, all the<br>
sptests generally did not run much longer than ticker. That test
takes <br>
35 seconds of target time plus boot. Of course, this was never a
hard <br>
rule and many exceptions crept in. <br>
<br>
sis (and tsim) can be programmed to timeout after N seconds of
simulated<br>
CPU time. Based on sim-scripts, 180 seconds is sufficient as a
general<br>
timeout if you ignore crypt01. Splitting the test into multiple
tests would <br>
bring it back in line with the maximum execution time of any other
test.<br>
<br>
When testing with a simulator, we can run multiple instances in
parallel.<br>
It is just a matter of managing the maximum run-time of any test so<br>
they cluster rather than having a single outlier driving the
selection.<br>
<br>
This test should be easy to split. The code looks like this:<br>
<br>
<blockquote>static void Init(rtems_task_argument arg)<br>
{<br>
TEST_BEGIN();<br>
<br>
test_formats();<br>
test_md5();<br>
test_sha256();<br>
test_sha512();<br>
test_generic();<br>
<br>
TEST_END();<br>
rtems_test_exit(0);<br>
}<br>
</blockquote>
The test has five sub-parts and it is just a matter of dividing the
test <br>
into those subparts. The simplest way would be conditional
compilation<br>
driven from the Makefile.am to build part 1, 2, 3, ... as needed.<br>
<br>
FWIW it took 24.61 seconds to run on a 2.4 Ghz older CPU. I added a<br>
print of uptime to get a feel of how it would need to be split. <br>
<br>
<blockquote>*** BEGIN OF TEST CRYPT 1 ***<br>
UPTIME: 0: 2479000<br>
UPTIME: 0: 3537000<br>
test crypt_md5_r()<br>
UPTIME: 0: 404662000<br>
test crypt_sha256_r()<br>
UPTIME: 196: 135394000<br>
test crypt_sha512_r()<br>
UPTIME: 644: 629217000<br>
test crypt_r()<br>
UPTIME: 663: 426214000<br>
*** END OF TEST CRYPT 1 ***<br>
</blockquote>
Unfortunately, it looks like the big "chunks" are sha256 and<br>
sha512 which are both over 180 seconds. So the list of<br>
test input/output list for those would have to be split<br>
into different runs. <br>
<pre class="moz-signature" cols="72">--
Joel Sherrill, Ph.D. Director of Research & Development
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985</pre>
</body>
</html>