<div dir="ltr">Hi Mr. Huber,<div><br></div><div>Thanks for checking in.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I suggested to enable your new scheduler implementation as the default<br>to check if it is in line with the standard schedulers. I would first<br>get some high level data. Select a BSP with good test results on a<br>simulator (for example sparc/leon3 or arm/realview_pbx_a9_qemu). Run the<br>tests and record the test data. Then enable the SMP EDF scheduler as the<br>default, run the tests, record the data. Then enable your scheduler as<br>the default, run the tests, record the data. Then get all tests which<br>fail only with your scheduler.</blockquote><div>Yes, this is something I've already done based on your previous suggestion. I set SCHEDULER_STRONG_APA(the current RTEMS master's version) as the default scheduler for both sp and SMP and ran the test (on both sparc/leon3 and arm/realview_pbx_a9_qemu). Then I set SCHEDULER_STRONG_APA(my version) as the default scheduler for both sp and SMP and ran the test and compared it with the master's strong apa result. The following (extra) tests failed:</div><div><br></div><div> sp02.exe<br> sp16.exe<br> sp30.exe<br> sp31.exe<br> sp37.exe<br> sp42.exe<br> spfatal29.exe<br><div> tm24.exe</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Do a high level analysis of all failing</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">tests. Try to figure out a new scenario for the test smpstrongapa01.</blockquote><div>Okay, I would look into this. This is a great suggestion, thanks!</div><div><br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Do all the development with RTEMS_DEBUG enabled!<br>Add _Assert() stuff to your scheduler. Check pre- and post-conditions of<br>all operations. Check invariants.</blockquote><div>How do I check postconditions? Using _Assert() or by manually debugging each function call? </div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 10, 2020 at 6:09 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Richi,<br>
<br>
I suggested to enable your new scheduler implementation as the default <br>
to check if it is in line with the standard schedulers. I would first <br>
get some high level data. Select a BSP with good test results on a <br>
simulator (for example sparc/leon3 or arm/realview_pbx_a9_qemu). Run the <br>
tests and record the test data. Then enable the SMP EDF scheduler as the <br>
default, run the tests, record the data. Then enable your scheduler as <br>
the default, run the tests, record the data. Then get all tests which <br>
fail only with your scheduler. Do a high level analysis of all failing <br>
tests. Try to figure out a new scenario for the test smpstrongapa01.<br>
<br>
Do all the development with RTEMS_DEBUG enabled!<br>
<br>
Add _Assert() stuff to your scheduler. Check pre- and post-conditions of <br>
all  operations. Check invariants.<br>
<br>
</blockquote></div>