<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 19, 2016 at 9:15 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"><br>
<br>
On 19/01/16 16:08, Joel Sherrill wrote:<span class=""><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">
<br>
<br>
On Tue, Jan 19, 2016 at 8:57 AM, Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>> wrote:<br>
<br>
<br>
<br>
On 19/01/16 15:39, Joel Sherrill wrote:<br>
<br>
The tasks are delaying 500, 1000, and 1500 ticks with<br>
nanoseconds_per_tick = 10000000. Delay operations are<br>
guaranteed to be a minimum of the requested amount and this is<br>
not being honored.<br>
<br>
<br>
For the ticks based services this is not true, you wait to the<br>
n-th tick. If you are 1ps before it, you wait 1ps + interrupt<br>
processing time.<br>
<br>
<br>
That is not how the original requirements for RTEID were written:<br>
<br>
<a href="https://ftp.rtems.org/pub/rtems/people/joel/RTEID-ORKID/RTEID-2.1/merged/" rel="noreferrer" target="_blank">https://ftp.rtems.org/pub/rtems/people/joel/RTEID-ORKID/RTEID-2.1/merged/</a><br>
<br>
See page 65 for tm_wkafter. Quoting:<br>
<br>
"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."<br>
<br>
I think you have to add 1 internally to all "ticks" based operations to ensure this requirement is met.<br>
</blockquote>
<br></span>
If you add 1, then you have a potential integer overflow. How was it implemented in RTEMS v1? I guess this problem existed also in this version.<div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div>That was a long time ago. :)</div><div><br></div><div>The git history goes back to May 1995. I looked at release 3.2.1 on the ftp site and</div><div>it appears to be from the same time frame. </div><div><br></div><div>I do not anywhere that the 3.2.1 code added 1 to the ticks value. </div><div><br></div><div>I do recall math on the POSIX side having to add 1 to meet the minimum. In </div><div>fact, score/src/timespectoticks.c does it now. </div><div><br></div><div>That said, I don't know if I personally every measured anything like this. The TOD</div><div>as reported matched expectations and the ticks since boot value matched what</div><div>was requested. I do know clock tick accuracy on specific BSPs was measured.</div><div><br></div><div>What really bothers me now is this:</div><div><br></div><div><span style="font-size:12.8px">TA1 599562000:1088</span><br style="font-size:12.8px"><span style="font-size:12.8px">TA2 599562000:2143</span><br style="font-size:12.8px"><span style="font-size:12.8px">TA3 599562000:3199</span><br style="font-size:12.8px"><span style="font-size:12.8px">TA1 599562004:997954</span><br style="font-size:12.8px"><span style="font-size:12.8px">TA2 599562009:977896</span><br style="font-size:12.8px"><span style="font-size:12.8px">TA1 599562009:978937</span><br style="font-size:12.8px"><span style="font-size:12.8px">TA3 599562014:957903</span><br style="font-size:12.8px"><span style="font-size:12.8px">TA1 599562014:958944</span><br style="font-size:12.8px"><span style="font-size:12.8px">TA2 599562019:957907</span><br></div><div><br></div><div>Notice that per the RTEID specification, the request delay for TA1 was 5 seconds.</div><div>The delay period between the first two reported is < 5 seconds. That violates the</div><div>original intent.</div><div><br></div><div>This negatively impacts periods and timeouts also.</div><div><br></div><div>Although there may have been a similar behavior in previous versions, I think it is</div><div>very apparent now that the original requirement is not met. Classic API intervals </div><div>need 1 tick added and apparently there are paths through POSIX where the</div><div>current +1 tick is either not being tripped or not being executed.</div><div><br></div><div>I think this is a bug. Delays are always a minimum of the specified period. </div><div> <br></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>
-- <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>