real_time.clock is not monotonic

real_time.clock is not monotonic

[frederic.ormancey]

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 ?

Re: real_time.clock is not monotonic

[Georg Bauhaus]

On Wed, 2007-02-21 at 08:16 -0800, frederic.ormancey@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 ?

Re: real_time.clock is not monotonic

[Simon Wright]

frederic.ormancey@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;

Re: real_time.clock is not monotonic

[Michael Bode]

Georg Bauhaus <bauhaus@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

Re: real_time.clock is not monotonic

[Adam Beneschan]

On Feb 21, 8:16 am, frederic.orman...@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

RE: real_time.clock is not monotonic

[Randy Brukardt]

Adam writes:

> Actually, I don't see in the LRM where it says "Ada.Real_Time.Clock
> shall be monotonic", in such forceful language.

D.8(32): "There shall be no backward clock jumps". What's not forceful about
that??

An implementation could allow setting the clock forward, but not back (so
Gnat is OK until fall ;-).

> 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.

I think it is a statement of reality, because 1.1.3(6) always allows
variations if they are "impossible or impractical" to avoid. I'm not sure
why there is an explicit mention in this case; when I tried to get something
similar added to D.14 (because Windows provides CPU information with a tick
of 0.01 seconds in practice, even if documentation claims to have greater
resolution), I was told to rely on 1.1.3(6).

> 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?

That's practically true of virtually any implementation: 1.1.3(6) is pretty
vague and the deviation would have to be pretty silly to not qualify.

                     Randy.

Re: real_time.clock is not monotonic

[Adam Beneschan]

On Feb 21, 6:34 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote:
> Adam writes:
> > Actually, I don't see in the LRM where it says "Ada.Real_Time.Clock
> > shall be monotonic", in such forceful language.
>
> D.8(32): "There shall be no backward clock jumps". What's not forceful about
> that??

Missed that.  Sorry.

                          -- Adam

Re: real_time.clock is not monotonic

[Duncan Sands]

>         ("rdtsc" & ASCII.LF & ASCII.HT &

I think the user needs to have appropriate permissions
for this to work.  In any case, the linux kernel time
support is getting a massive rework as we speak, so
hopefully everything will be perfect soon :)

Ciao,

Duncan.

Re: real_time.clock is not monotonic

[Simon Wright]

Duncan Sands <baldrick@free.fr> writes:

>>         ("rdtsc" & ASCII.LF & ASCII.HT &
>
> I think the user needs to have appropriate permissions
> for this to work.  In any case, the linux kernel time
> support is getting a massive rework as we speak, so
> hopefully everything will be perfect soon :)

Works for ordinary users on Windows (certainly up to 2K) and on all
the Linuxes I've tried it on (up to Ubunto DD).

Much better of course to use OS facilities.

But my primary interest was for a high resolution clock (1e-5 seconds
or better), the monotonicity was incidental.

I see that on Windows we have that already, lucky for those of us who
have Windows as their development and target platform.

On SPARC Solaris, there certainly are permission issues wrt the
equivalent feature. I haven't tried rtdsc on x86 Solaris.

Re: real_time.clock is not monotonic

[Duncan Sands]

On Thursday 22 February 2007 11:34:37 Simon Wright wrote:
> Duncan Sands <baldrick@free.fr> writes:
> 
> >>         ("rdtsc" & ASCII.LF & ASCII.HT &
> >
> > I think the user needs to have appropriate permissions
> > for this to work.  In any case, the linux kernel time
> > support is getting a massive rework as we speak, so
> > hopefully everything will be perfect soon :)
> 
> Works for ordinary users on Windows (certainly up to 2K) and on all
> the Linuxes I've tried it on (up to Ubunto DD).

I think you just got lucky with linux.

> Much better of course to use OS facilities.
> 
> But my primary interest was for a high resolution clock (1e-5 seconds
> or better), the monotonicity was incidental.

Yes of course.  This is one of the things that is being sorted out in
linux now.

Ciao,

Duncan.

[OT] Broken threading (was RE: real_time.clock is not monotonic)

[Alex R. Mosteo]

Randy Brukardt wrote:

Randy, all your posts break threading in my newsreader. I'm wondering in whose
end is the problem -- my knode or your newsreader.

Curiosly, I'm not sure it has been always like this. I'd say it's since some
weeks ago.

Anyone else suffering this?

Re: [OT] Broken threading (was RE: real_time.clock is not monotonic)

[Georg Bauhaus]

On Thu, 2007-02-22 at 12:04 +0100, Alex R. Mosteo wrote:
> Randy Brukardt wrote:
> 
> Randy, all your posts break threading in my newsreader. I'm wondering in whose
> end is the problem -- my knode or your newsreader.

Does knode support the In-Reply-To: header?

> Curiosly, I'm not sure it has been always like this. I'd say it's since some
> weeks ago.
> 
> Anyone else suffering this?

Re: [OT] Broken threading (was RE: real_time.clock is not monotonic)

[Alex R. Mosteo]

Georg Bauhaus wrote:

> On Thu, 2007-02-22 at 12:04 +0100, Alex R. Mosteo wrote:
>> Randy Brukardt wrote:
>> 
>> Randy, all your posts break threading in my newsreader. I'm wondering in
>> whose end is the problem -- my knode or your newsreader.
> 
> Does knode support the In-Reply-To: header?

I don't really know, but it's the only regular poster I have this problem. Any
other messages are properly threaded, even with changes in subject.

It claims to be GNKSA compliant, which I don't know if this includes that
header. OTOH, it's still at version 0.8 so who knows, it may be a bug or
unimplemented feature. I guess you don't have problems with Randy's post.

[Few moments later]
I have just tried with thunderbird and it doesn't break at Randy's post, so
I'll file a bug for knode.

>> Curiosly, I'm not sure it has been always like this. I'd say it's since some
>> weeks ago.
>> 
>> Anyone else suffering this?

Re: real_time.clock is not monotonic

[Simon Wright]

Duncan Sands <baldrick@free.fr> writes:
> On Thursday 22 February 2007 11:34:37 Simon Wright wrote:
>> Duncan Sands <baldrick@free.fr> writes:
>> 
>> >>         ("rdtsc" & ASCII.LF & ASCII.HT &
>> >
>> > I think the user needs to have appropriate permissions
>> > for this to work.  In any case, the linux kernel time
>> > support is getting a massive rework as we speak, so
>> > hopefully everything will be perfect soon :)
>> 
>> Works for ordinary users on Windows (certainly up to 2K) and on all
>> the Linuxes I've tried it on (up to Ubunto DD).
>
> I think you just got lucky with linux.

I guess this would be a kernel thing and not a distro thing -- I've
run it on 2.2, 2.4, and 2.6, which others were you thinking of?

Apparently the TSD flag in CR4 can turn of rdtsc, why anyone would
particularly want to I can't think.

Re: [OT] Broken threading (was RE: real_time.clock is not monotonic)

[Randy Brukardt]

"Alex R. Mosteo" <devnull@mailinator.com> wrote in message
news:545blhF1ttrphU2@mid.individual.net...
...
> Randy, all your posts break threading in my newsreader. I'm wondering in
whose
> end is the problem -- my knode or your newsreader.
>
> Curiosly, I'm not sure it has been always like this. I'd say it's since
some
> weeks ago.

I started using the Ada-France e-mail service a couple of weeks ago after
changing ISPs (the new ISP doesn't have a news server, the installer said
that since they only support businesses, they don't support news, as "it's
more for home users". Uh-huh.) I'd expect that you'd see issues with other
people using that service (I doubt they're specially handling messages from
me... ;-)

Anyway, someone offered to give me an account on their personal news server;
I posted this message with that account. Does this help??

                                 Randy.

Re: [OT] Broken threading (was RE: real_time.clock is not monotonic)

[Alex R. Mosteo]

Randy Brukardt wrote:

> "Alex R. Mosteo" <devnull@mailinator.com> wrote in message
> news:545blhF1ttrphU2@mid.individual.net...
> ...
>> Randy, all your posts break threading in my newsreader. I'm wondering in
> whose
>> end is the problem -- my knode or your newsreader.
>>
>> Curiosly, I'm not sure it has been always like this. I'd say it's since
> some
>> weeks ago.
> 
> I started using the Ada-France e-mail service a couple of weeks ago after
> changing ISPs (the new ISP doesn't have a news server, the installer said
> that since they only support businesses, they don't support news, as "it's
> more for home users". Uh-huh.) I'd expect that you'd see issues with other
> people using that service (I doubt they're specially handling messages from
> me... ;-)
> 
> Anyway, someone offered to give me an account on their personal news server;
> I posted this message with that account. Does this help??

Yes, this message appears properly threaded :)

When digging for bugs in knode I found the one that's causing this: knode only
relies on reference headers, and doesn't consider the subject in absence of
references. 

Obviously, not being your fault, is very kind of you to use an alternative, but
since I'll get the problem with other people until this is fixed in knode, you
may as well use whatever is more comfortable for you.

Thanks in any case,

Alex.

Re: [OT] Broken threading

[Björn Persson]

Alex R. Mosteo wrote:

> When digging for bugs in knode I found the one that's causing this: knode
> only relies on reference headers, and doesn't consider the subject in
> absence of references.
> 
> Obviously, not being your fault, is very kind of you to use an
> alternative, but since I'll get the problem with other people until this
> is fixed in knode, you may as well use whatever is more comfortable for
> you.

Threading by subject can put a message in the right thread, but not at the
right position in the thread. It will also sometimes associate a new
message with an old dead thread because they happen to have identical
subject lines. It's a kludge really. Not having it could be considered lack
of a feature but it's not a bug.

I'd say the bug is the absence of reference headers. Either Ada-France's
gateway removes them or else Randy's Outlook Express supports reference
headers for Usenet but not for email. Both seem like rather odd behaviour.

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: real_time.clock is not monotonic

[Florian Weimer]

* Simon Wright:

>         ("rdtsc" & ASCII.LF & ASCII.HT &

This is not monotonic, either, because on some (most?) architectures,
the cycle counters of the different CPUs are not synchronized.

Re: [OT] Broken threading

[Alex R. Mosteo]

Bj�rn Persson wrote:

> Alex R. Mosteo wrote:
> 
>> When digging for bugs in knode I found the one that's causing this: knode
>> only relies on reference headers, and doesn't consider the subject in
>> absence of references.
>> 
>> Obviously, not being your fault, is very kind of you to use an
>> alternative, but since I'll get the problem with other people until this
>> is fixed in knode, you may as well use whatever is more comfortable for
>> you.
> 
> Threading by subject can put a message in the right thread, but not at the
> right position in the thread. It will also sometimes associate a new
> message with an old dead thread because they happen to have identical
> subject lines. It's a kludge really. Not having it could be considered lack
> of a feature but it's not a bug.

I see your point. I think they also consider it a lack more than a bug. I read
that kmail already has it and that a merge is planned.

> I'd say the bug is the absence of reference headers. Either Ada-France's
> gateway removes them or else Randy's Outlook Express supports reference
> headers for Usenet but not for email. Both seem like rather odd behaviour.

I'm afraid my knowledge of nntp is not enough to comment on this.

Re: real_time.clock is not monotonic

[Simon Wright]

Florian Weimer <fw@deneb.enyo.de> writes:

> * Simon Wright:
>
>>         ("rdtsc" & ASCII.LF & ASCII.HT &
>
> This is not monotonic, either, because on some (most?)
> architectures, the cycle counters of the different CPUs are not
> synchronized.

As I said, it was for hi-res timing, and if you get swapped in the
timed code the result is an outlier even if there's onlu one CPU.

Re: [OT] Broken threading

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

"Bj�rn Persson" <spam-away@nowhere.nil> wrote in message
news:bV4Eh.34800$E02.13755@newsb.telia.net...
...
> I'd say the bug is the absence of reference headers. Either Ada-France's
> gateway removes them or else Randy's Outlook Express supports reference
> headers for Usenet but not for email. Both seem like rather odd behaviour.

I doubt that any mail client would include any old headers in reply e-mail,
as replies are newly created messages. The headers belong to the old
message; the new message has new headers appropriate for it. I'm pretty sure
that Outlook discards all headers, even on forwards.

Indeed, I'd never even realized that RFC-822 even defines reference headers
(they're so rarely used; the Ada-France messages do have them, but that's
the first time I've seen them in any mail - and I look at a lot of mail
headers). I doubt that it would make sense to copy those headers in e-mail,
unless the client knows what they are for (as in a newsreader). (How would
you know if they apply to the reply? How do you know what to add to them?
The contents of the reference header is not standardized for mail.)

                            Randy.