On Wed, Jan 20, 2016 at 12:38 AM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> > > On 19/01/16 16:44, Joel Sherrill wrote: > >> >> >> On Tue, Jan 19, 2016 at 9:15 AM, Sebastian Huber < >> sebastian.hu...@embedded-brains.de <mailto: >> 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> >> <mailto: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. >> > > I guess this violation of the original intent exists since v1 of RTEMS. > > Unfortunately, that does appear to be the case. We just didn't have an obvious way to know it. > In the early days you had no nanoseconds extension. Let t0 be the time of > a clock tick, and so on. If you set the TOD at t0 + d with some time > interval d < clock tick interval, then you effectively set the time > reference point to t0. If you wait n ticks, then you will later observe > that n ticks time passed. > > Yep. So there was no way via software to notice this. > The nanoseconds extension did change nothing here, since it uses the last > clock tick as its reference point. > > Yep. > With the FreeBSD timecounters the reference point is no longer the last > clock tick. This is the reason why you now observe the problem. > > Agreed 100%. > >> This negatively impacts periods and timeouts also. >> > > For the Classic API I think this is now a feature. I would change nothing > here (e.g. all ticks users at the API level) since it would alter the > behaviour of existing applications. That would be the case. I am surprised no one has noticed this before but adding a tick would impact every RTEMS application. And that would be bad. > > > >> 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. >> > > For POSIX, which uses an absolute time, its clearly a bug. This bug shows > up in the libstdc++ testsuite for example. I didn't bother to fix this, > since the thread cancellation bugs are more important from my point of view > and I am currently a bit overloaded. > > I have been looking at support for CLOCK_THREAD_CPUTIME_ID and this is also requires tinkering. I think it is just another logical event which could fire as part of the API CPU budget support. But I have to think more about the POSIX requirements and what the behavior really needs to be. > > -- > 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
