Odd Time of Day Reported with Ticker

[Joel Sherrill]

On Tue, Jan 19, 2016 at 8:57 AM, Sebastian Huber <
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.



>
>> I know this is a duration specified in clock ticks but it is really
>> (ticks * nanoseconds per tick) long in real time.
>>
>> I have not checked delays like sleep() and nanosleep() but tick based
>> ones are 1 tick too short.
>>
>
> This is a known issue and results for example in libstdc++ testsuite
> failures.
>
>
> 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.

Example sleep() from
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sleep.html

"The sleep utility shall suspend execution for at least the integral number
of seconds specified by the time operand."

Due to implementation changes, the one tick needs to be added. Or we miss
the requirements for RTEID and POSIX.



> --
> 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/d3be95d1/attachment-0001.html>