From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cf6d5074f59b1de1,start X-Google-Attributes: gid103376,public From: "W. Wesley Groleau (Wes)" Subject: Ada.Real_Time - alternate implementation (fwd) Date: 1996/12/16 Message-ID: <9612162153.AA18457@most>#1/1 X-Deja-AN: 204649585 sender: Ada programming language comments: Gated by NETNEWS@AUVM.AMERICAN.EDU mailer: Elm [revision: 70.85] newsgroups: comp.lang.ada Date: 1996-12-16T00:00:00+00:00 List-Id: 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 ---------------------------------------------------------------------------