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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,d1f23f0bd3971bec X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news2.google.com!proxad.net!proxad.net!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Timing Block of GNAT code in milliseconds Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1114090119.383842.20950@l41g2000cwc.googlegroups.com> <1KydnfadqcK30fXfRVn-qw@comcast.com> Date: Fri, 29 Apr 2005 10:11:03 +0200 Message-ID: <10m95m5yelieq$.kj1rktb792s3.dlg@40tude.net> NNTP-Posting-Date: 29 Apr 2005 10:11:04 MEST NNTP-Posting-Host: a4219544.newsread4.arcor-online.net X-Trace: DXC=6B4P:R?SaB64B[hADX>N=3:ejgIfPPld4jW\KbG]kaM8liQbn6H@_E9AY4fihD2m0;[6LHn;2LCV>7enW;^6ZC`4<=9bOTW=MN> X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:10804 Date: 2005-04-29T10:11:04+02:00 List-Id: On 28 Apr 2005 21:26:00 +0100, Simon Wright wrote: > "Dmitry A. Kazakov" writes: > >> I presume Real_Time uses Windows' performance counter which never >> jumps. But I have no idea how Calendar behaves, especially in >> presence of some external time synchronization software like NTP. >> >> Alas, both clock models are quite useless in a distributed >> environment. > > I think that's going a bit far -- it has to depend what your > requirements are! > > We are running on plain VxWorks and need millisecond sync over our > local network. If GNAT separated Real_Time from Calendar we could > probably have used Calendar; as it is we have our own similar package > which manages an offset from Calendar. > > Any requirement much finer than millisecond sync is going to need > something more appropriate than plain old ethernet with a plain old > network stack (which takes about 150 us to traverse on this hardware > in the best of conditions!) Neither clock is usable in a WAN. We need time stamps synchronized across the network. The accuracy of synchronization is the second problem. The first problem is that the very idea of synchronized time stamps cannot be expressed in Ada terms. There is no portable way to get say UTC from either Calendar or Real_Time, or to convert UTC to them. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de