milliseconds and delay until

milliseconds and delay until

[Thomas Bruns]

Hello

how can I handle the until delay statement, too do this: ????


with ADA.Calendar; use ADA.Calendar;

procedure ....

MS : INTEGER; --milliseconds

begin
MS:= INTEGER(FLOAT(seconds(clock)) * 1000);

MS := MS + 100;

delay until MS; ---???? it is wrong :-( it must be a time type :-( but I
        -- need the clock from a fixed time and add some milliseconds... 
--and then the until delay statement....How can I handle this???

end;


-- 
PS:
HW: ASUS P4PE, PIV 2.4 GHz, 768 MB RAM, Geforce 4200, 
SW: Suse 8.2, Kernel 2.4.20, KDE 3.1.2, QT3.1.2, KDEVELOP 2.1.5

Re: milliseconds and delay until

[Jano]

Thomas Bruns dice...
> Hello
> 
> how can I handle the until delay statement, too do this: ????
> 
> 
> with ADA.Calendar; use ADA.Calendar;
> 
> procedure ....
> 
> MS : INTEGER; --milliseconds
> 
> begin
> MS:= INTEGER(FLOAT(seconds(clock)) * 1000);
> 
> MS := MS + 100;
> 
> delay until MS; ---???? it is wrong :-( it must be a time type :-( but I
>         -- need the clock from a fixed time and add some milliseconds... 
> --and then the until delay statement....How can I handle this???

Why not use better a Time type from start?

Next : Time := Clock;

Next := Next + 0.1;

delay until Next;

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: milliseconds and delay until

[Thomas Bruns]

Jano wrote:

> Thomas Bruns dice...
> Why not use better a Time type from start?
> 
> Next : Time := Clock;
> 
> Next := Next + 0.1;
> 
> delay until Next;
mmhhhh... 0.1 is milliseconds :-) but I mean, that the time type + duration
(0.1) is not alright... I test it

Thx
Thomas

-- 
PS:
HW: ASUS P4PE, PIV 2.4 GHz, 768 MB RAM, Geforce 4200, 
SW: Suse 8.2, Kernel 2.4.20, KDE 3.1.2, QT3.1.2, KDEVELOP 2.1.5

Re: milliseconds and delay until

[Jano]

Thomas Bruns dice...
> Jano wrote:
> 
> > Thomas Bruns dice...
> > Why not use better a Time type from start?
> > 
> > Next : Time := Clock;
> > 
> > Next := Next + 0.1;
> > 
> > delay until Next;
> mmhhhh... 0.1 is milliseconds :-) but I mean, that the time type + duration
> (0.1) is not alright... I test it

Correct, durations are in seconds. However I don't quite understand you. 
What do you mean with that's is not right? What problem are you having?

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: milliseconds and delay until

[Simon Wright]

Thomas Bruns <newsgroup@donbruno.de> writes:

> how can I handle the until delay statement, too do this: ????
> 
> 
> with ADA.Calendar; use ADA.Calendar;
> 
> procedure ....
> 
> MS : INTEGER; --milliseconds
> 
> begin
> MS:= INTEGER(FLOAT(seconds(clock)) * 1000);
> 
> MS := MS + 100;
> 
> delay until MS; ---???? it is wrong :-( it must be a time type :-( but I
>         -- need the clock from a fixed time and add some milliseconds... 
> --and then the until delay statement....How can I handle this???
> 
> end;

   with Ada.Calendar;
   with Ada.Text_IO;

   procedure Delaying is

      Start : constant Ada.Calendar.Time := Ada.Calendar.Clock;
      Next : Ada.Calendar.Time := Start;
      Millisec : constant Duration := 0.001;

      use type Ada.Calendar.Time;


   begin

      for I in 1 .. 5_000 loop

         Next := Next + Millisec;
         delay until Next;

      end loop;

      Ada.Text_IO.Put_Line (".. that took"
                              & Duration'Image (Ada.Calendar.Clock - Start));

   end Delaying;

The output here (Mandrake 9.1, GNAT 3.16a) is

   .. that took 5.011935000

NB!! on most desktop machines you'll get a minimum actual delay of 10
ms (a tick) or even 2 ticks; what happens, I think, is that many of
the "delay until"s turn out to be delaying until a time that has
already passed, so the program spins until it catches up.

Re: milliseconds and delay until

[tmoran]

> NB!! on most desktop machines you'll get a minimum actual delay of 10
> ms (a tick) or even 2 ticks; what happens, I think, is that many of
> the "delay until"s turn out to be delaying until a time that has
  See
http://www.adapower.com/reuse/tt.html
for a benchmarking program that will tell you how often your clock ticks,
minimum nonzero delay, etc.

Re: milliseconds and delay until

[Dmitry A. Kazakov]

Simon Wright wrote:

> NB!! on most desktop machines you'll get a minimum actual delay of 10
> ms (a tick) or even 2 ticks; what happens, I think, is that many of
> the "delay until"s turn out to be delaying until a time that has
> already passed, so the program spins until it catches up.

It is a complicated issue which depends on great variety of factors [OS, 
whether Ada RT uses native threads etc.]

But usually I would expect a better performance. [Even under Windows NT, 
where the time slicing quant is 10ms, one can force it to 1ms. Under 2k/XP 
it is already 1ms.]

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: milliseconds and delay until

[Frank J. Lhota]

"Thomas Bruns" <newsgroup@donbruno.de> wrote in message
news:bc7smt$357$04$1@news.t-online.com...
> Hello
>
> how can I handle the until delay statement, too do this: ????

Let us take one step back, and take a look at what the delay statement is
supposed to accomplish. There are two different types of time measurements:

- There are relative time values that specify the length of a span  of time,
e.g. "1 hour, 38 minutes, and 5.385 seconds", and
- There are absolute time values that specify a particular point in time,
e.g. "24 June 1987 06:58:05".

In Ada, the Standard type Duration is used to represent relative time
values. Duration is a real type representing the length of time in seconds.
The range of Duration must be large enough to represent plus or minus one
day.

The Time type defined in Ada.Calendar represents an absolute time value,
i.e. "24 June 1987 06:58:05". The Ada.Calendar package provides utilities
for handling Time values, including the Clock function that returns the
current time, and the various arithmentic operations between relative and
absolute time.

There are two forms of the delay statement. The relative delay statement
takes the form

    delay Number_Of_Seconds;

This form of the delay statement is used to delay for a certain time span,
For example, to delay for one minute, you could use the relative delay
statement

    delay 60.0;

The other form of the delay statement is the "delay until" statement. This
form delays until an absolute time is reached. It takes the

    delay until Time_Expression;

Where Time_Expression is an Ada type (such as Ada.Calendar.Time) that
represents an absolute time. For example, to delay until 12 June 2003, 6:30
in the morning, you could use the following "delay until" statement:

    procedure ...

       Secs_Per_Min  : constant := 60.0;
       Secs_Per_Hour : constant := 60 * Secs_Per_Min;

    begin

       delay until Time_Of(
          Year    => 2003,
          Month   => 06
          Day     => 12
          Seconds => 6 * Secs_Per_Hour + 30 * Secs_Per_Min );

    end;

Now on to your problem. If you wish to delay for a certain time span, e.g.
delay for a tenth of a second; you should use the relative delay statement:

    delay 0.1;

To delay until some absolute time, use the "delay until" statement. The
Ada.Calendar package has the utilities you need to compute that absolute
time. For example

    procedure ...

       The_Cows_Come_Home : Ada.Calendar.Time;

    begin

       -- Compute absolute time for "Delay Until" to be a tenth of a second
from now.
       The_Cows_Come_Home := Ada.Calendar.Clock  + 0.1;
       ...
       delay until The_Cows_Come_Home;

    end;

Re: milliseconds and delay until

[Steve]

Instead of using Ada.Calendar, have a look at Ada.Real_Time;

Then you should be able to do something like (tested):

with Ada.Real_Time;

procedure Rt_Demo is

  package Real_Time renames Ada.Real_Time;
  use type Real_Time.Time_Span;
  use type Real_Time.Time;

  Start_Time  : Real_Time.Time;
  Target_Time : Real_Time.Time;

begin
  Start_Time := Real_Time.Clock;
  Target_Time := Start_Time + Real_Time.Milliseconds( 100 );
  delay until Target_Time;
end Rt_Demo;

My rule of thumb on deciding whether to use Ada.Calendar versus
Ada.Real_Time is:
  Use Ada.Calendar when you want numbers to print on a report.
  Use Ada.Real_Time when you want to do delays for timing.

Most of the work I do is time sensitive, where delays of more than a few
tens of milliseconds are not tolerated for some operation.  I use
Ada.Real_Time most of the time.

Steve
(The Duck)


"Thomas Bruns" <newsgroup@donbruno.de> wrote in message
news:bc7smt$357$04$1@news.t-online.com...
> Hello
>
> how can I handle the until delay statement, too do this: ????
>
>
> with ADA.Calendar; use ADA.Calendar;
>
> procedure ....
>
> MS : INTEGER; --milliseconds
>
> begin
> MS:= INTEGER(FLOAT(seconds(clock)) * 1000);
>
> MS := MS + 100;
>
> delay until MS; ---???? it is wrong :-( it must be a time type :-( but I
>         -- need the clock from a fixed time and add some milliseconds...
> --and then the until delay statement....How can I handle this???
>
> end;
>
>
> --
> PS:
> HW: ASUS P4PE, PIV 2.4 GHz, 768 MB RAM, Geforce 4200,
> SW: Suse 8.2, Kernel 2.4.20, KDE 3.1.2, QT3.1.2, KDEVELOP 2.1.5

Re: milliseconds and delay until

[Simon Wright]

"Steve" <nospam_steved94@attbi.com> writes:

> Instead of using Ada.Calendar, have a look at Ada.Real_Time;
> 
> Then you should be able to do something like (tested):
> 
> with Ada.Real_Time;
> 
> procedure Rt_Demo is
> 
>   package Real_Time renames Ada.Real_Time;
>   use type Real_Time.Time_Span;
>   use type Real_Time.Time;
> 
>   Start_Time  : Real_Time.Time;
>   Target_Time : Real_Time.Time;
> 
> begin
>   Start_Time := Real_Time.Clock;
>   Target_Time := Start_Time + Real_Time.Milliseconds( 100 );
>   delay until Target_Time;
> end Rt_Demo;
> 
> My rule of thumb on deciding whether to use Ada.Calendar versus
> Ada.Real_Time is:
>   Use Ada.Calendar when you want numbers to print on a report.
>   Use Ada.Real_Time when you want to do delays for timing.
> 
> Most of the work I do is time sensitive, where delays of more than a
> few tens of milliseconds are not tolerated for some operation.  I
> use Ada.Real_Time most of the time.

This depends on your compiler's runtime. I think you will find for
GNAT that it makes very little difference (certainly 3.15a1 fails to
comply with ARM D.8(32), "A clock jump is the difference between two
successive distinct values of the clock (as observed by calling the
Clock function). There shall be no backward clock jumps.". Of course
on a desktop machine it may be hard to manage this! but it would have
been nice if the VxWorks version had done so.)

Re: milliseconds and delay until

[Martin Dowie]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7vd6hjdoun.fsf@pushface.org...

> This depends on your compiler's runtime. I think you will find for
> GNAT that it makes very little difference (certainly 3.15a1 fails to
> comply with ARM D.8(32), "A clock jump is the difference between two
> successive distinct values of the clock (as observed by calling the
> Clock function). There shall be no backward clock jumps.". Of course

Which sentence doesn't it comply with?

> been nice if the VxWorks version had done so.)

VxWorks has a few interesting clock, cough, features ;-)

Re: milliseconds and delay until

[Simon Wright]

"Martin Dowie" <martin.dowie@btopenworld.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message
> news:x7vd6hjdoun.fsf@pushface.org...
> 
> > This depends on your compiler's runtime. I think you will find for
> > GNAT that it makes very little difference (certainly 3.15a1 fails
> > to comply with ARM D.8(32), "A clock jump is the difference
> > between two successive distinct values of the clock (as observed
> > by calling the Clock function). There shall be no backward clock
> > jumps.".
> 
> Which sentence doesn't it comply with?

The one with the requirement (the "shall") in it!