Odd Time of Day Reported with Ticker

[Sebastian Huber]

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.

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.

The nanoseconds extension did change nothing here, since it uses the 
last clock tick as its reference point.

With the FreeBSD timecounters the reference point is no longer the last 
clock tick. This is the reason why you now observe the problem.

>
> 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.

>
> 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.

-- 
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.