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,e81fd3a32a1cacd2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.hanau.net!noris.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: accuracy Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.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: <1170071840.010200.85210@s48g2000cws.googlegroups.com> <1173089302.125025.31370@t69g2000cwt.googlegroups.com> <0dmdnZIAd76ZpXPYnZ2dnUVZ_uCinZ2d@comcast.com> <1lq9zxgrnvfjx$.17ip3w3ei4xdb.dlg@40tude.net> <1lo7kf2cw2mog$.94hkrwmeyhqy.dlg@40tude.net> Date: Tue, 13 Mar 2007 10:33:44 +0100 Message-ID: NNTP-Posting-Date: 13 Mar 2007 10:33:44 CET NNTP-Posting-Host: 5ca98024.newsspool3.arcor-online.net X-Trace: DXC=aegn:=M26E7_A0jCfgHO6>McF=Q^Z^V384Fo<]lROoR1Fl8W>\BH3Y2\TG?<^IdHj3DNcfSJ;bb[5FCTGGVUmh?4LK[5LiR>kg2W@a_]MTJE`6 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:14506 Date: 2007-03-13T10:33:44+01:00 List-Id: On Mon, 12 Mar 2007 15:20:46 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:1lo7kf2cw2mog$.94hkrwmeyhqy.dlg@40tude.net... >> On Sat, 10 Mar 2007 21:03:41 -0600, Randy Brukardt wrote: > Janus/Ada certainly does this. It uses the performance counter, and only > checks the real clock periodically to check for massive changes. Moreover, > it only re-bases if the time has changed more then 5 minutes in either > direction from the one determined by the performance counter (else we > believe the performance counter). > > Tom Moran also designed code to fix the "clock leap" problem of the > performance counter (he had a computer with that problem), and the is also > part of our Calendar package. I read somewhere that it is also possible to access the processor ticks which have resolution of nanoseconds and are very lightweight to read. The problem is that they fluctuate with the processor frequency. It would be interesting to try to tie them to slower, but more reliable performance counters in Ada.Real_Time.Clock, and the later to the system time in Ada.Calendar.Clock: ns ticks <-----> perf. counter <-----> sys time (Ada.Real_Time.Clock) (Ada.Calendar.Clock) So basically Ada.Real_Time.Clock would read ns ticks and adjust them according to the accumulated statistics from performance counters. That should be extremely fast comparing to a call QueryPerformanceCounter. Ada.Calendar.Clock would do the same but adjust further to the system time. The drawback is that the statistic would be accumulated in an extra task. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de