On Tue, Jan 19, 2016 at 9:15 AM, Sebastian Huber < sebastian.hu...@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.hu...@embedded-brains.de <mailto: >> 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. >> > > 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.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
