<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 19, 2016 at 8:57 AM, Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<br>
On 19/01/16 15:39, Joel Sherrill wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The tasks are delaying 500, 1000, and 1500 ticks with nanoseconds_per_tick = 10000000. Delay operations are guaranteed to be a minimum of the requested amount and this is not being honored.<br>
</blockquote>
<br></span>
For the ticks based services this is not true, you wait to the n-th tick. If you are 1ps before it, you wait 1ps + interrupt processing time.<span class=""><br>
<br></span></blockquote><div><br></div><div>That is not how the original requirements for RTEID were written:</div><div><br></div><div><a href="https://ftp.rtems.org/pub/rtems/people/joel/RTEID-ORKID/RTEID-2.1/merged/">https://ftp.rtems.org/pub/rtems/people/joel/RTEID-ORKID/RTEID-2.1/merged/</a><br></div><div><br></div><div>See page 65 for tm_wkafter. Quoting:</div><div><br></div><div>"If the system clock frequency is 100 ticks per second, and the requester wants to wait for 2 seconds, then the input parameter will be 100*2, or 200 ticks."</div><div><br></div><div>I think you have to add 1 internally to all "ticks" based operations to ensure this requirement is met.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I know this is a duration specified in clock ticks but it is really (ticks * nanoseconds per tick) long in real time.<br>
<br>
I have not checked delays like sleep() and nanosleep() but tick based ones are 1 tick too short.<br>
</blockquote>
<br></span>
This is a known issue and results for example in libstdc++ testsuite failures.<div class=""><div class="h5"><br>
<br></div></div></blockquote><div>Similar issue to above. Delays are always a minimum of the specified length of time. The change is making it less then the specified time.</div><div><br></div><div>Example sleep() from <a href="http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sleep.html">http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sleep.html</a></div><div><br></div><div>"The sleep utility shall suspend execution for at least the integral number of seconds specified by the time operand."</div><div><br></div><div>Due to implementation changes, the one tick needs to be added. Or we miss the requirements for RTEID and POSIX.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116" target="_blank">+49 89 189 47 41-16</a><br>
Fax     : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109" target="_blank">+49 89 189 47 41-09</a><br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</div></div></blockquote></div><br></div></div>