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