On Tue, Jan 19, 2016 at 8:57 AM, Sebastian Huber < sebastian.hu...@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.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
