Odd Time of Day Reported with Ticker
joel at rtems.org
Tue Jan 19 15:44:52 UTC 2016
On Tue, Jan 19, 2016 at 9:15 AM, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:
> On 19/01/16 16:08, Joel Sherrill wrote:
>> On Tue, Jan 19, 2016 at 8:57 AM, Sebastian Huber <
>> sebastian.huber at embedded-brains.de <mailto:
>> sebastian.huber at embedded-brains.de>> wrote:
>> On 19/01/16 15:39, Joel Sherrill wrote:
>> 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.
>> 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.
>> That is not how the original requirements for RTEID were written:
>> See page 65 for tm_wkafter. Quoting:
>> "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
>> I think you have to add 1 internally to all "ticks" based operations to
>> ensure this requirement is met.
> 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.
That was a long time ago. :)
The git history goes back to May 1995. I looked at release 3.2.1 on the ftp
it appears to be from the same time frame.
I do not anywhere that the 3.2.1 code added 1 to the ticks value.
I do recall math on the POSIX side having to add 1 to meet the minimum. In
fact, score/src/timespectoticks.c does it now.
That said, I don't know if I personally every measured anything like this.
as reported matched expectations and the ticks since boot value matched what
was requested. I do know clock tick accuracy on specific BSPs was measured.
What really bothers me now is this:
Notice that per the RTEID specification, the request delay for TA1 was 5
The delay period between the first two reported is < 5 seconds. That
This negatively impacts periods and timeouts also.
Although there may have been a similar behavior in previous versions, I
think it is
very apparent now that the original requirement is not met. Classic API
need 1 tick added and apparently there are paths through POSIX where the
current +1 tick is either not being tripped or not being executed.
I think this is a bug. Delays are always a minimum of the specified period.
> Sebastian Huber, embedded brains GmbH
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail : sebastian.huber at embedded-brains.de
> PGP : Public key available on request.
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel