Ada.Real_Time - alternate implementation (fwd)

Ada.Real_Time - alternate implementation (fwd)

[W. Wesley Groleau (Wes)]

In another group, there has recently been a discussion about the
package Ada.Real_Time.Clock and what its requirements are.  Some of
the participants were concerned that some implementations would not
meet the RM requirements if a user having sufficient privilege changed
the system clock, i.e., the clock the is used to put the time stamps on
email.

Others said that if your system has real-time requirements, then there
is NO WAY to protect against that except by prevent such outside
tampering.  I found a way to get linear monotonic time on several systems
although with a lower accuracy than RM D.8 requires.  Although some of these
platforms have clocks available that meet ALL of the D.8 requirements,
I personally prefer this method because it is more portable.

In a later message, I will post C source for this method.
:>
:> 1.  I am not going to post the Ada source, because I expect that most
:> people, if they are even interested at all, will use this with pragmas
:> to alter the implementation of Ada.Real_Time
:>
:> 2. I have embedded the results of the tests done so far in comments in the
:> C source.  Some WARNINGS about the precision of the tests:
:>
:>    a. Some tests were done by " read;sleep xx;read " on multi-user systems.
:>       Thus one must assume that the two clock reads are not exactly
:>       xx seconds apart.
:>    b. One test was done by "read;date" repeated with nearly a half hour
:>       between.  Since 'date' is either rounded or truncated to integer
:>       seconds, and since the read is not at the same instant as the 'date',
:>       some inaccuracy must be expected.
:>    c. It became obvious during the testing that the "seconds" result in
:>       the gcc versions was not accurate; even though "tick" was always
:>       either 50 or 100, the floating point often had non-zeros in the
:>       "wee bits"  (No doubt an integer times a power of two.)
:>       The  cc  version, on the other hand, always had the last four decimal
:>       places zero.  But from comparing each quotient ("seconds" with the
:>       "tick" and "RTC" lines, it was apparent that about half the time,
:>       the quotient was 0.01 higher than correct, for example:
:>       RTC:     1875181l
:>       Tick:    100l
:>       Seconds:      18751.820000
:>    d. My C book said I should use 'l' (lowercase L) in a format string
:>       to tell printf the item is a long.  But (as above) all compilers
:>       actually put the 'l' on the end of the number--I had to be very
:>       not to think it was the digit '1' :-)
:>
:> 3. The C code contains two simple functions.
:>    Ada_Real_Time_Tick is intended to provide the value for Real_Time.Tick
:>    Ada_Real_Time_Tick via pragma can provide raw input for Real_Time.Clock
:>    which can use Tick to derive a Real_Time.Time value that will make the
:>    rest of the package portable among platforms providing times(2).
:>    These platforms include all those listed in the test results.
:>
:>    For SunOS 4.1.4, times(2) is provided, but instead of getting CLK_TCK
:>    from a header file, the user has to know and hard-code it at SIXTY (60).
:>
:>    Anyone interested in trying this on other platforms and emailing to me
:>    the results?  I can summarize and post.
:>
:> 4. If you consider the range of 'long' and the values of 'CLK_TCK' it
:>    will be apparent that this does not meet the accuracy requirement of
:>    RM D.8(30).  It CAN meet the range requirement of that paragraph IF
:>    you watch for wraparound and add the appropriate bias to each Clock
:>    output after wrap occurs.  Without such a correction, the range is
:>    still longer than the support required for delay statements
:>    in 9.6 (27-29)  I haven't found anything in Annex D that increases
:>    that range.
:>
:> The C will be posted after a short delay.... :-)  (to give people a
   chance to read this first!)

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Hughes Defense Communications (MS 10-40)                 Home: 219-471-7206
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------