real_time.clock is not monotonic
in [ADA]
|
Prev: RSS/Atom reader?
Next: Text Processing in Ada 95
From: frederic.ormancey on 21 Feb 2007 11:16 I'm porting a GNAT application from Windows to Linux platform, and the application use two kinds of clock data : - Ada.Calendar.clock to obtain machine date and time, affect by NTP and daylight saving - Ada.real_Time.Clock, which use System.Os_Primitives.Monotonic_Clock to obtain a monotonic clock (for delays and time events generation) With Windows version of GNAT (3.15p), all is OK, monotonic clock use QueryPerformanceCounter() Win32 call to obtain a monotonic behaviour, but in Linux implementation of Gnat RunTime, Monotonic_Clock is a single rename of calendar.clock, which use gettimeofday() system call !!!! I'll alert Gnat community with this bad implementation, as gettimeofday() is affected by NTP and others date adjustements. in LRM, Ada.Real_Time.Clock shall be monotonic => Gnat runtime is not compliant This bug was detected with 3.15p Linux version, but implementation is still the same with latest source of gnat runtime (s-osprim.adb). Did someone have a solution for this problem ? another implementation using a Linux monotonic clock ?
From: Georg Bauhaus on 21 Feb 2007 14:46 On Wed, 2007-02-21 at 08:16 -0800, frederic.ormancey(a)atosorigin.com wrote: > in Linux implementation of Gnat RunTime, Monotonic_Clock is a > single rename of calendar.clock, which use gettimeofday() system > call !!!! > > I'll alert Gnat community with this bad implementation, as > gettimeofday() is affected by NTP and others date adjustements. in > LRM, Ada.Real_Time.Clock shall be monotonic => Gnat runtime is not > compliant What is a possible alternative when making calls to a garden variety Linux kernel? Is there real-time POSIX support in "normal" Linux based systems? > This bug was detected with 3.15p Linux version, but implementation is > still the same with latest source of gnat runtime (s-osprim.adb). > > Did someone have a solution for this problem ? another implementation > using a Linux monotonic clock ?
From: Simon Wright on 21 Feb 2007 15:17 frederic.ormancey(a)atosorigin.com writes: > I'll alert Gnat community with this bad implementation, as > gettimeofday() is affected by NTP and others date adjustements. in > LRM, Ada.Real_Time.Clock shall be monotonic => Gnat runtime is not > compliant I reported this with GNAT 3.16, not sure if there's a solution yet. > Did someone have a solution for this problem ? another implementation > using a Linux monotonic clock ? The Booch Components have a clock that might be a possibility: OK on Windows and Linux (not sure about Solaris x86, no idea for 64-bit OSs): with System.Machine_Code; separate (BC.Support.High_Resolution_Time) function Clock return Time is type Half is (Low, High); Lower, Upper : Interfaces.Unsigned_32; Results : array (Half) of Interfaces.Unsigned_32; Result : Time; for Result'Address use Results (Low)'Address; begin System.Machine_Code.Asm ("rdtsc" & ASCII.LF & ASCII.HT & "movl %%eax, %0"& ASCII.LF & ASCII.HT & "movl %%edx, %1", Outputs => (Interfaces.Unsigned_32'Asm_Output ("=g", Lower), Interfaces.Unsigned_32'Asm_Output ("=g", Upper)), Clobber => "eax, edx", Volatile => True); Results := (Low => Lower, High => Upper); return Result; end Clock;
From: Michael Bode on 21 Feb 2007 15:33 Georg Bauhaus <bauhaus(a)arcor.de> writes: > What is a possible alternative when making calls to a garden > variety Linux kernel? Is there real-time POSIX support in > "normal" Linux based systems? I'd say clock_gettime(CLOCK_MONOTONIC, tp) should work. -- No intelligent man has any respect for an unjust law. He simply follows the eleventh commandment. -- R.A. Heinlein
From: Adam Beneschan on 21 Feb 2007 21:05
On Feb 21, 8:16 am, frederic.orman...(a)atosorigin.com wrote: > I'm porting a GNAT application from Windows to Linux platform, and the > application use two kinds of clock data : > - Ada.Calendar.clock to obtain machine date and time, affect by NTP > and daylight saving > - Ada.real_Time.Clock, which use System.Os_Primitives.Monotonic_Clock > to obtain a monotonic clock (for delays and time events generation) > > With Windows version of GNAT (3.15p), all is OK, monotonic clock use > QueryPerformanceCounter() Win32 call to obtain a monotonic behaviour, > but in Linux implementation of Gnat RunTime, Monotonic_Clock is a > single rename of calendar.clock, which use gettimeofday() system > call !!!! > > I'll alert Gnat community with this bad implementation, as > gettimeofday() is affected by NTP and others date adjustements. in > LRM, Ada.Real_Time.Clock shall be monotonic => Gnat runtime is not > compliant Actually, I don't see in the LRM where it says "Ada.Real_Time.Clock shall be monotonic", in such forceful language. D.8(1) implies that it's supposed to be. However, D.8(36) says, "The implementation shall document any aspects of the external environment that could interfere with the clock behavior as defined in this clause", and a note in the AARM says, "For example, the implementation is allowed to rely on the time services of an underlying operating system, and this operating system clock can implement time zones or allow the clock to be reset by an operator. This dependence has to be documented". Unless I'm over-interpreting things, this last AARM note seems to imply that, in some cases (such as the user manually changing the date or time), Clock might *not* be monotonic. Is my interpretation correct? Does this mean that GNAT's implementation is correct (if possibly undesirable to some users) as long as it's documented? -- Adam |