Re: Timing Block of GNAT code in milliseconds

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 24 Apr 2005 19:57:24 +0100, Simon Wright wrote:

> "Steve" <nospam_steved94@comcast.net> writes:
> 
>> "Simon Wright" <simon@pushface.org> wrote in message 
>> news:x7vsm1i2gs7.fsf@smaug.pushface.org...
>>> "Steve" <nospam_steved94@comcast.net> writes:
>>>
>>>> I tend to think of the Real_Time package as the one to use when
>>>> you are timing events and the Calendar package as the one to use
>>>> when you don't care about precise timing and want the time of day
>>>> for reporting, etc.
>>>
>>> It used to be the case with GNAT that there was an amazing
>>> similarity between these two clocks! Looking on 5.02a1, on a first
>>> glance it seems that Real_Time is derived as follows (the first
>>> two letters are the encoding in the distribution, eg if building
>>> on NT the file s-taprop.adb is copied from 5wtaprop.adb).
>>>
>> [snip]
>> 
>> It would also be interesting to know whether there is a difference
>> in the time base for Ada.Calendar and Ada.Real_Time for the
>> different systems.
> 
> There are two things, the tick rate and the epoch. All the ones that
> use the system clock or gettimeofday or clock_gettime are going to
> have identical Calendar and Real_Time (and, incidentally, fail to meet
> the ARM requirement in D.8(32), "There shall be no backward clock
> jumps.", if the system's time-of-day changes; the only one that
> obviously meets that is VxWorks/Cert).

Yes, but that shouldn't prevent them from using the same source. They could
run synchronized, experiencing rare and short periods when Calendar jumps
here and there.

> I don't know about Windows NT.

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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de