Odd Time of Day Reported with Ticker

[Joel Sherrill]

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:
>>
>> https://ftp.rtems.org/pub/rtems/people/joel/RTEID-ORKID/RTEID-2.1/merged/
>>
>> 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
>> ticks."
>>
>> 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
site and
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.
The TOD
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:

TA1 599562000:1088
TA2 599562000:2143
TA3 599562000:3199
TA1 599562004:997954
TA2 599562009:977896
TA1 599562009:978937
TA3 599562014:957903
TA1 599562014:958944
TA2 599562019:957907

Notice that per the RTEID specification, the request delay for TA1 was 5
seconds.
The delay period between the first two reported is < 5 seconds. That
violates the
original intent.

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
intervals
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...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160119/37788957/attachment-0002.html>