<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 12:38 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:44, 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"><span class="">
<br>
<br>
On Tue, Jan 19, 2016 at 9:15 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 16:08, Joel Sherrill wrote:<br>
<br>
<br>
<br>
On Tue, Jan 19, 2016 at 8:57 AM, Sebastian Huber<br>
<<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
<mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>><br></span>
<mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><div><div class="h5"><br>
<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<br>
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<br>
the requester wants to wait for 2 seconds, then the input<br>
parameter will be 100*2, or 200 ticks."<br>
<br>
I think you have to add 1 internally to all "ticks" based<br>
operations to ensure this requirement is met.<br>
<br>
<br>
If you add 1, then you have a potential integer overflow. How was<br>
it implemented in RTEMS v1? I guess this problem existed also in<br>
this version.<br>
<br>
<br>
That was a long time ago. :)<br>
<br>
The git history goes back to May 1995. I looked at release 3.2.1 on the ftp site and<br>
it appears to be from the same time frame.<br>
<br>
I do not anywhere that the 3.2.1 code added 1 to the ticks value.<br>
<br>
I do recall math on the POSIX side having to add 1 to meet the minimum. In<br>
fact, score/src/timespectoticks.c does it now.<br>
<br>
That said, I don't know if I personally every measured anything like this. The TOD<br>
as reported matched expectations and the ticks since boot value matched what<br>
was requested. I do know clock tick accuracy on specific BSPs was measured.<br>
<br>
What really bothers me now is this:<br>
<br>
TA1 599562000:1088<br>
TA2 599562000:2143<br>
TA3 599562000:3199<br>
TA1 599562004:997954<br>
TA2 599562009:977896<br>
TA1 599562009:978937<br>
TA3 599562014:957903<br>
TA1 599562014:958944<br>
TA2 599562019:957907<br>
<br>
Notice that per the RTEID specification, the request delay for TA1 was 5 seconds.<br>
The delay period between the first two reported is < 5 seconds. That violates the<br>
original intent.<br>
</div></div></blockquote>
<br>
I guess this violation of the original intent exists since v1 of RTEMS.<br>
<br></blockquote><div><br></div><div>Unfortunately, that does appear to be the case. We just didn't have an obvious way to know it.</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">
In the early days you had no nanoseconds extension. Let t0 be the time of a clock tick, and so on. If you set the TOD at t0 + d with some time interval d < clock tick interval, then you effectively set the time reference point to t0. If you wait n ticks, then you will later observe that n ticks time passed.<br>
<br></blockquote><div>Yep. So there was no way via software to notice this.</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">
The nanoseconds extension did change nothing here, since it uses the last clock tick as its reference point.<br>
<br></blockquote><div><br></div><div>Yep.</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">
With the FreeBSD timecounters the reference point is no longer the last clock tick. This is the reason why you now observe the problem.<span class=""><br>
<br></span></blockquote><div><br></div><div>Agreed 100%.</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>
This negatively impacts periods and timeouts also.<br>
</blockquote>
<br></span>
For the Classic API I think this is now a feature. I would change nothing here (e.g. all ticks users at the API level) since it would alter the behaviour of existing applications.</blockquote><div><br></div><div>That would be the case. I am surprised no one has noticed this before but adding a tick would impact every RTEMS application. And that would be bad. </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=""><br>
<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>
Although there may have been a similar behavior in previous versions, I think it is<br>
very apparent now that the original requirement is not met. Classic API intervals<br>
need 1 tick added and apparently there are paths through POSIX where the<br>
current +1 tick is either not being tripped or not being executed.<br>
<br>
I think this is a bug. Delays are always a minimum of the specified period.<br>
</blockquote>
<br></span>
For POSIX, which uses an absolute time, its clearly a bug. This bug shows up in the libstdc++ testsuite for example. I didn't bother to fix this, since the thread cancellation bugs are more important from my point of view and I am currently a bit overloaded.<div class=""><div class="h5"><br></div></div></blockquote><div>I have been looking at support for CLOCK_THREAD_CPUTIME_ID and this is also requires tinkering. I think it is just another logical event which could fire as part of the API CPU budget support. But I have to think more about the POSIX requirements and what the behavior really needs to be.</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>
-- <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>