Odd Time of Day Reported with Ticker

[Joel Sherrill]

On Wed, Jan 20, 2016 at 12:38 AM, Sebastian Huber <
sebastian.huber at 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.huber at embedded-brains.de <mailto:
>> 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>
>>         <mailto: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.
>>
>
> 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.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/20160120/5fc60319/attachment.html>