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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8c564a80b820db35 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.224.230 with SMTP id rf6mr13761870pbc.4.1330980972508; Mon, 05 Mar 2012 12:56:12 -0800 (PST) Path: h9ni43335pbe.0!nntp.google.com!news2.google.com!goblin1!goblin2!goblin.stu.neva.ru!newsfeed1.swip.net!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Any leap year issues caused by Ada yesterday? Date: Mon, 05 Mar 2012 20:56:09 +0000 Organization: A noiseless patient Spider Message-ID: References: <4f4f746a$0$6565$9b4e6d93@newsspool3.arcor-online.net> <20608866.730.1330963171058.JavaMail.geo-discussion-forums@ynbq18> <1t8v4akrmapkl.1xwfi9yxtw2ji$.dlg@40tude.net> Mime-Version: 1.0 Injection-Info: mx04.eternal-september.org; posting-host="dFCm8HWntFqmDIilBLqEJQ"; logging-data="1546"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+U2UJ9Y5jPWHWtCMtkL69UVmbaAhxxNBU=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (darwin) Cancel-Lock: sha1:jsu9OIVLExnAbZlHEpO5l9zFrRo= sha1:waN2HD/gq5KJjYAvrA+Wk/eBbqI= Content-Type: text/plain; charset=us-ascii Date: 2012-03-05T20:56:09+00:00 List-Id: "Dmitry A. Kazakov" writes: > On Mon, 05 Mar 2012 18:30:46 +0000, Simon Wright wrote: > >> "Dmitry A. Kazakov" writes: >> >>> BTW, I would not wonder to see Real_Time.Time and Calendar.Time same >>> or correlated. >> >> We were surprised and disappointed to find that earlier releases of GNAT >> did have them the same. What happens to your precise timing if you get >> an NTP update in the middle of it? > > Nothing, because I would expect the NTP client to leave alone the clock > readings and the arithmetic of. It should rather adjust Split and Time_Of. Some people would arrange time sync such that if: a) you read the clock b) time sync sets the clock back 1 second c) after 1 second you read the clock again that the time read at a) and c) would be the same. > In our setups we are using a different schema anyway. Instead of > adjusting clocks we do the time stamps when sending them from host to > host. Because of the GNAT bug we couldn't use Ada.Real_Time. So we left Ada.Calendar untouched and made our own .Calendar with offsets, as you say. Fun with I/O of time, >> OK, this is slightly GNAT-related, since (at that time, anyway) "delay >> 0.5" translated under the hood into "delay until now + 0.5" on VxWorks, > > Yes, but NTP should not mingle in that. [I don't know how the VxWorks NTP > client works.] I don't understand? What else would it do but change the value of Ada.Calendar.Clock? >> so you were always related to the actual clock. > > VxWorks clock on i7 is a garbage. It is driven by the timer interrupts, > i.e. to get 1ms resolution you need 1000 interrupts per second. > > We keep on asking Wind River to fix the mess, but without much success so > far. GNAT simply uses that clock. So delay 0.001 may mean absolutely > anything under VxWorks. To fix that one should rewrite the time driver. We were quite happy with 1 ms ticks. So delay 0.001 meant "delay at least 1 and no more than 2 ms" (like always). >> AdaCore accepted the bug report (after we pointed out the "shall" in >> ARM95 D.8(32)). > > Well, I would not blame AdaCore for that, it is Wind River's fault, > IMO. This was *Ada* running on VxWorks; so it needed fixing. We didn't care who fixed it (well, as far as we were concerned, who didn't fix it, actually). It should have been easy enough on VxWorks: taskDelay(period + 1); (but there may be all sorts of complicated reasons why that wouldn't be enough).