GNAT R/T Annex and Win95

GNAT R/T Annex and Win95

[Greg Bond]

My understanding is that Win95 uses a timesliced scheduling policy for 
threads, and that GNAT tasks are mapped to Win95 threads. How is 
GNAT's fixed priority preemptive scheduling policy supported if this 
is the case?

--
* Greg Bond                         * Dept. of Electrical Eng.  
* email: bond@ee.ubc.ca             * Univ. of British Columbia      
* voice: (604) 822 0899             * 2356 Main Mall                 
* fax:   (604) 822 5949             * Vancouver, BC              
* web: http://www.ee.ubc.ca/~bond   * Canada, V6T 1Z4

Re: GNAT R/T Annex and Win95

[Tom Griest]

In article <3174712D.71C7@ee.ubc.ca> Greg Bond <bond@ee.ubc.ca> writes:
>My understanding is that Win95 uses a timesliced scheduling policy for 
>threads, and that GNAT tasks are mapped to Win95 threads. 

Win32 threads are scheduled on a priority basis, but time-sliced
within a priority.

Right now GNAT/Win32 uses threads, but it is possible in the future
we will switch to "fibers" which provide even finer control over
scheduling.

-Tom

Re: GNAT R/T Annex and Win95

[Dale Pontius]

In article <4l2sliINNl7m@ra.dept.cs.yale.edu>,
        griest-tom@cs.yale.edu (Tom Griest) writes:
>
>Right now GNAT/Win32 uses threads, but it is possible in the future
>we will switch to "fibers" which provide even finer control over
>scheduling.
>
I can guess the general idea of fibers. I presume that the GNAT/Win32
runtime takes one Win32 thread and schedules it among fibers. How
much do you expect to gain? How is the Win32 thread switch compared
to other OS thread switches?

Is this done to get faster GNAT thread switching? I preume you know
more about the thread context and can do a more streamlined switch.

Tasks->threads->fibers... Will it stop at the single-strand polymer,
or will scheduling have to make it to the quantum cosmic string
level?

Dale Pontius
(NOT speaking for IBM)

Re: GNAT R/T Annex and Win95

[Robert Dewar]

Greg says

"My understanding is that Win95 uses a timesliced scheduling policy for
threads, and that GNAT tasks are mapped to Win95 threads. How is
GNAT's fixed priority preemptive scheduling policy supported if this
is the case?"

Time-slicing has nothing to do with fixed-priorities per se, or with
preemption. It *does* have to do with run-till-blocked.

Ada 95 does not require run-till-blocked semantics unless the RT annex
is supported fully. Not all OS's can support the real time annex, and
clearly GNAT on such a system does not support the annex (this is
assuming tasks are mapped to threads). On NT, you can map to the
real time threads, and all is well, but I don't know if this applies
to Win95. Anyway, Greg, you are making undocumented assjmptions here!

Re: GNAT R/T Annex and Win95

[Marin David Condic, 407.796.8997, M/S 731-93]

Robert Dewar <dewar@CS.NYU.EDU> writes:
>
>Ada 95 does not require run-till-blocked semantics unless the RT annex
>is supported fully. Not all OS's can support the real time annex, and
>clearly GNAT on such a system does not support the annex (this is
>assuming tasks are mapped to threads). On NT, you can map to the
>real time threads, and all is well, but I don't know if this applies
>to Win95. Anyway, Greg, you are making undocumented assjmptions here!
>
    Here's an interesting question which we've been thinking about
    around here a lot:

    Do you consider Windows NT capable of being a "realtime" operating
    system? (It doesn't seem to be advertised as such.... yet.)

    We'd like to build some of our data systems and ground support
    systems around Ada and NT, but we're not sure we can get the
    needed behavior out of it for a realtime system. (GNAT might even
    be usable here since most of this is "in house" development and
    not a contract deliverable. More leeway with what you do in this
    case.)

    We need to know things like "If I execute a delay statement, will
    I wake up and have a deterministic span of time between the clock
    going off and my code resuming?" Similar questions for interrupt
    processing and such. Or "will the OS dynamically rescale my task
    priorities and screw everything up?" Or priority inversions that
    can occur if a low priority thread uses an uninterruptable OS
    routine. Lots of things are uncertain about NT WRT its use as a
    realtime OS.

    (Of course, you can always buy a processor that executes a
    quintillion instructions per second and hope the latencies never
    get big enough to matter! ;-)

    Opinions? I'd really like to have some best guesses to pass on to
    the folks here who do these sort of systems.

    Pax,
    Marin

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-93                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        407.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   MDCONDIC@AOL.COM
===============================================================================
    "You spend a billion here and a billion there. Sooner or later it
    adds up to real money."

        --  Everett Dirksen
===============================================================================

Re: GNAT R/T Annex and Win95

[Robert Dewar]

Marin said

"    Do you consider Windows NT capable of being a "realtime" operating
    system? (It doesn't seem to be advertised as such.... yet.)

    We'd like to build some of our data systems and ground support
    systems around Ada and NT, but we're not sure we can get the
    needed behavior out of it for a realtime system. (GNAT might even
    be usable here since most of this is "in house" development and
    not a contract deliverable. More leeway with what you do in this
    case.)"

First, of course Windows NT is capable of realtime operatoin. You need to
examine its specs closely, and probably stick to the realtime thread
priority group if you want Ada-style run-till-blocked absolute
priorities.

Second, GNAT is being used in many projects involving contract deliverables.
The Airfields project, one of the first, perhaps the first deployed
applications using Ada 95 was done using GNAT, and many other significant
projects inside and outside the DoD, including for example, the high
reliability medical equipment programs done by JEOL and the Aegis program,
are using GNAT, which was the first validated general purpose Ada 95
compiler, and is still the only Ada 95 techology that covers the full
language including all the annexes.

Now you might have meant "GNAT without support" might be usable here, in
which case that's a little more understandable, although personally I
would not use unsupported software even for internal development.

For more information on the NT version of GNAT, contact Tom Griest
at Labtek (labtek@cs.yale.edu). For more information on GNAT generally,
send email to info@gnat.com.

Robert Dewar
Ada Core Technologies

Re: GNAT R/T Annex and Win95

[Wiljan Derks]

Marin David Condic, 407.796.8997, M/S 731-93 wrote:
> 
>     Here's an interesting question which we've been thinking about
>     around here a lot:
> 
>     Do you consider Windows NT capable of being a "realtime" operating
>     system? (It doesn't seem to be advertised as such.... yet.)
> ...
>     We need to know things like "If I execute a delay statement, will
>     I wake up and have a deterministic span of time between the clock
>     going off and my code resuming?" Similar questions for interrupt
>     processing and such. Or "will the OS dynamically rescale my task
>     priorities and screw everything up?" Or priority inversions that
>     can occur if a low priority thread uses an uninterruptable OS
>     routine. Lots of things are uncertain about NT WRT its use as a
>     realtime OS.
> 
>     (Of course, you can always buy a processor that executes a
>     quintillion instructions per second and hope the latencies never
>     get big enough to matter! ;-)
> 
>     Opinions? I'd really like to have some best guesses to pass on to
>     the folks here who do these sort of systems.To my opinion NT performs real good when it comes to real-time behaviour.
To demonstrate this I wrote I program that shows this.
The program determines the maximum variation that it takes to be
rescheduled by the kernel.
It gave me a maximum of 800 microsecond variation on a pentium 120.
In the mean time I was copying files and clicking around on the desktop.
This means that the variation of the time between the clock interrupt
and the next procedure call in the waiting program is about 400 microseconds.
Notice that this program runs at real time priority on NT.
It will only run properly when it has the right priviledge.
In practice you also whould need to lock your code into memory to avoid
paging but that is another issue.
But anyway here is the code. I think it shows how NT performs.
When you ant to build the program you need GNAT and the NT bindings.

with ada.text_io; use ada.text_io;
with win32; use win32;
with win32.winbase; use win32.winbase;
with win32.winnt; use win32.winnt;
with interfaces; use interfaces;
with interfaces.C; use interfaces.C;
procedure testnttime is
   failed:exception;
   Counter,Previous,Freq:aliased Large_Integer;
   Min:Longlong;
   Max:Longlong;
   Dif:Longlong;
   First:Longlong;
begin
   if SetPriorityClass(GetCurrentProcess,
                       REALTIME_PRIORITY_CLASS)=win32.false then
      raise failed;
   end if;
   if QueryPerformanceFrequency(Freq'Unchecked_Access)=win32.false then
      raise failed;
   end if;
   Put_Line("Performance Frequency is "&Freq.Quadpart'img);
   loop
      Min:=LongLong'Last;
      Max:=LongLong'First;
      sleep(1);
      sleep(1);
      if QueryPerformanceCounter(Previous'Unchecked_Access)=win32.false then
         raise failed;
      end if;
      First:=Previous.Quadpart;
      for i in 1..1000 loop
         sleep(1);
         if QueryPerformanceCounter(Counter'Unchecked_Access)=win32.false then
            raise failed;
         end if;
         Dif:=Counter.Quadpart-Previous.Quadpart;
         If Dif<Min then
            Min:=Dif;
         End if;
         If Dif>Max then
            Max:=Dif;
         End if;
         Previous:=Counter;
      end loop;
      put_line("Maximum count "&Max'Img&" is "&
               Longlong'Image(Max*1000000/Freq.Quadpart)&" us");
   end loop;
end testnttime;

Wiljan

ADA, Windows NT and Real-Time (was GNAT R/T Annex and Win95)

[Brian K. Catlin]

Marin David Condic, 407.796.8997, M/S 731-93 wrote:
> 
> Robert Dewar <dewar@CS.NYU.EDU> writes:
> >
> >Ada 95 does not require run-till-blocked semantics unless the RT annex
> >is supported fully. Not all OS's can support the real time annex, and
> >clearly GNAT on such a system does not support the annex (this is
> >assuming tasks are mapped to threads). On NT, you can map to the
> >real time threads, and all is well, but I don't know if this applies
> >to Win95. Anyway, Greg, you are making undocumented assjmptions here!
> >
>     Here's an interesting question which we've been thinking about
>     around here a lot:
> 
>     Do you consider Windows NT capable of being a "realtime" operating
>     system? (It doesn't seem to be advertised as such.... yet.)
> 

 A couple of years ago, I wrote a paper on using Windows NT for real-time systems 
(no, I can't send it to anyone - See the Microsoft Developer Network CDROM, where 
Microsoft "rewrote" my paper as "Real-Time Systems and Windows NT").  I made 
several measurements with a logic analyzer and some custom drivers and kernel-mode 
software, and found that NT is quite good for soft and even firm real-time systems.  
Interrupt latency (time from interrupt to starting Interrupt Service Routine) was 
typically less than 10 microseconds.

 The reason Microsoft won't publicly state that Windows NT can be used for 
real-time systems is two-fold: too much liability, and PC hardware varies too much.  
If you are thinking of using NT for real-time work, you must carefully pick your 
platform, and then make your own measurements on its performance.  Contrary to what 
most people believe, PC hardware varies greatly (in some cases 5X for the same 
processor clock rate !). NOTE: The granularity of the timer service on PC (Intel) 
platforms is 10 milliseconds (ancient PC architecture standard).

 To build a real-time system with a small latency window (less than 1 millisecond) 
would require that you write your system as an NT device driver (you may also want 
to get a programmable timer board for fine granularity timers).  But if your 
latency window is larger, then writing it in user-mode is fine.

 -Brian
-- 

Brian Catlin, Sannas Consulting (310) 798-8930
Contracting to Lockheed Martin Real-3D (407) 356-0637
Windows NT Internals and Device Driver Consulting

Re: GNAT R/T Annex and Win95

[Tom Griest]

"Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM> writes:

[snip]

>    Do you consider Windows NT capable of being a "realtime" operating
>    system? (It doesn't seem to be advertised as such.... yet.)

That's correct.  NT is not designed for real-time use.  But many are
using it for soft real-time applications.

>    We'd like to build some of our data systems and ground support
>    systems around Ada and NT, but we're not sure we can get the
>    needed behavior out of it for a realtime system. (GNAT might even
>    be usable here since most of this is "in house" development and
>    not a contract deliverable. More leeway with what you do in this
>    case.)
>
>    We need to know things like "If I execute a delay statement, will
>    I wake up and have a deterministic span of time between the clock
>    going off and my code resuming?" Similar questions for interrupt
>    processing and such. Or "will the OS dynamically rescale my task
>    priorities and screw everything up?"

No.  NT does not do this.  Of course this means you can lock out rather
important operations... but usually your real-high priority stuff should
be fairly short duration.

> Or priority inversions that
>    can occur if a low priority thread uses an uninterruptable OS
>    routine. Lots of things are uncertain about NT WRT its use as a
>    realtime OS.

True.  There are multithreaded libraries, but you always have to
be aware of any locks that might be held.  NT does not have priority
inheritence.

>    (Of course, you can always buy a processor that executes a
>    quintillion instructions per second and hope the latencies never
>    get big enough to matter! ;-)

Or you can take a two-processor system and run NT on one and some
real-time code on the other, using shared memory and interprocessor
interrupts.

>    Opinions? I'd really like to have some best guesses to pass on to
>    the folks here who do these sort of systems.

In the end it depends on two things:
  1) what happens if you miss a deadline
  2) how much laxity do you have in your timeline?

If the answer to #1 is: loss of life/property, I'd recommend not using NT.
On the other hand, if it is system runs a little slower then you're probably
ok depending on #2.

-Tom

Re: ADA, Windows NT and Real-Time (was GNAT R/T Annex and Win95)

[steved]

In <317916B0.A5C@ccmail.orl.mmc.com>, "Brian K. Catlin" <tpcatlib@ccmail.orl.mmc.com> writes:
>processor clock rate !). NOTE: The granularity of the timer service on PC (Intel) 
>platforms is 10 milliseconds (ancient PC architecture standard).

Details, details but:  According to the OS/2 Control Programming Guide (regarding timers on
PC hardware) "On most hardware, clock ticks occur approximately 32 times a second, so each
tick interval lasts approximately 31.25 milliseconds."

The 10 msec number didn't sound right, since most of the real time OS's I've usd have had
a 10 msec timer.  But then again on the systems I've done they're mostly event driven
so the resolution of the system timer isn't that significant.

> To build a real-time system with a small latency window (less than 1 millisecond) 
>would require that you write your system as an NT device driver (you may also want 
>to get a programmable timer board for fine granularity timers).  But if your 
>latency window is larger, then writing it in user-mode is fine.
>
> -Brian
>-- 
>
>Brian Catlin, Sannas Consulting (310) 798-8930
>Contracting to Lockheed Martin Real-3D (407) 356-0637
>Windows NT Internals and Device Driver Consulting

Re: ADA, Windows NT and Real-Time (was GNAT R/T Annex and Win95)

[Brian K. Catlin]

Steve Doiel wrote:
> 
> In <317916B0.A5C@ccmail.orl.mmc.com>, "Brian K. Catlin" <tpcatlib@ccmail.orl.mmc.com> writes:
> >processor clock rate !). NOTE: The granularity of the timer service on PC (Intel)
> >platforms is 10 milliseconds (ancient PC architecture standard).
> 
> Details, details but:  According to the OS/2 Control Programming Guide (regarding timers on
> PC hardware) "On most hardware, clock ticks occur approximately 32 times a second, so each
> tick interval lasts approximately 31.25 milliseconds."
> 

I guess I should have said "running Windows NT"

> The 10 msec number didn't sound right, since most of the real time OS's I've usd have had
> a 10 msec timer.  But then again on the systems I've done they're mostly event driven
> so the resolution of the system timer isn't that significant.
> 

I agree that most real-time applications are event driven, but regarding the timers:

Every "IBM PC Architecture" compliant system includes at least one 8254 Programmable 
Interrupt Timer (or equivalent), which contains three independent 16-bit timers.  Timer 0 is 
used as the primary system timer.  Timer 1 is used for DRAM refresh on ISA systems, and is 
not supported on MCA systems.  Timer 2 is for general application use, including speaker 
tones.  MCA and EISA systems alos provide a fourth counter, Timer 3, used as a Watchdog 
timer.  EISA systems also have a fifth counter, Timer 5 (not 4), used for optional CPU speed 
control.

From MS Developer Network CDROM:
 Windows NT Workstation version 3.5 makes it possible for applications to use the basic 
system timer with the GetTickCount( ) API.  The resolution of this timer is 10 milliseconds.  
Several CPUs support a high-resolution counter that can be used to get very granular 
resolution.  The Win32 QueryPerformanceCounter( ) API returns the resolution of a 
high-resolution performance counter.  For Intel-based CPUs, the resolution is about 0.8 
microseconds.  For MIPS-based CPUs, the resolution is about twice the clock speed of the 
processor.  You need to call QueryPerformanceFrequency( ) to get the frequency of the 
high-resolution performance counter.

 Now that we've beat this timer issue into the ground, the original question was, "Can NT be 
used for real-time systems ?".  As I said originally, it can, *provided* that you understand 
your platform thoroughly.

 -Brian

-- 

Brian Catlin, Sannas Consulting (310) 798-8930
Contracting to Lockheed Martin Real-3D (407) 356-0637
Windows NT Internals and Device Driver Consulting

Re: GNAT R/T Annex and Win95

[Theodore E. Dennison]

Marin David Condic, 407.796.8997, M/S 731-93 wrote:
> 
>     Here's an interesting question which we've been thinking about
>     around here a lot:
> 
>     Do you consider Windows NT capable of being a "realtime" operating
>     system? (It doesn't seem to be advertised as such.... yet.)
> 

A straight NT question in an Ada group, huh? Oh well...

When you say "real-time", typically I think of a system with a clock
which is capable of generating software iterrupts every 10msec or
better, and some way of knowing when you have failed to service
an interrupt.

According to my NT book, there are two ways to do Timers with NT. The
first uses the SetTimer system call. This will put a WM_TIMER event
in the thread's normal message queue.  The resolution is ABOUT 55
milliseconds, but there can be message queue delays. Not very useful.

The second is the "Multimedia Timer". This timer allows you to define
a callback that will get called directly by an interrupt, without any
message queue processing overhead. The resolution is said to be 
"about 16 (Intel) milliseconds". Whatever that means, you can get the
exact resolution on your system via a call to "timeGetDevCaps". (Oddly
enough, Microsoft's example uses a resolution of 5 milliseconds) This
is a little more useful, but still not what we would like to see. 

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: GNAT R/T Annex and Win95

[Greg Bond]

Marin David Condic, 407.796.8997, M/S 731-93 wrote:
> 
>     Here's an interesting question which we've been thinking about
>     around here a lot:
> 
>     Do you consider Windows NT capable of being a "realtime" operating
>     system? (It doesn't seem to be advertised as such.... yet.)
> Stuff deleted...

The suitability of NT for real-time has been discussed on and off on 
comp.realtime. Here's one posting that may be of peripheral interest.


     Subject: 
            Re: Realtime NT 
       Date: 
            Sat, 13 Apr 1996 03:22:47 GMT 
      From: 
            dszlucha@eznet.net (David Szlucha)
Newsgroups: 
            comp.realtime
  References: 
            1


dszlucha@eznet.net (David Szlucha) wrote:

By the way, Jim's reply address is: jfox@ultranet.com and VenturCom's
WWW address is: www.vci.com.



>Hi,

>I recently attended an Embedded show in Boston and found out that
>microsoft is working with a company called VenturCom (Cambridge, MA)
>to
>develop hard realtime extension for NT.  They also have some products
>for
>building 'embedded versions of NT' - they let you pick and choose what
>goes
>into the NT build and according to their web page you can fit NT on a
>system
>with no monitor, 8 MB ram and 16 MB disk.

>I'm having trouble posting so if this works and anybody is interested
>I'll write more about what I found out - also, they have a web site.

>Jim Fox

>---
>David Szlucha http://home.eznet.net/~dszlucha



---
David Szlucha http://home.eznet.net/~dszlucha

Re: GNAT R/T Annex and Win95

[Greg Bond]

Robert Dewar wrote:
> 
> Greg says
> 
> "My understanding is that Win95 uses a timesliced scheduling policy for
> threads, and that GNAT tasks are mapped to Win95 threads. How is
> GNAT's fixed priority preemptive scheduling policy supported if this
> is the case?"
> 
> Time-slicing has nothing to do with fixed-priorities per se, or with
> preemption. It *does* have to do with run-till-blocked.

Or even more precisely, prioritized run-until-blocked scheduling and 
prioritized time-sliced scheduling can both be considered fixed priority 
preemptive scheduling policies, so my terminology is ambiguous.

However, I've found that the majority of the literature in rate 
monotonic analysis refers to fixed priority preemptive scheduling when I 
thought what was really being referred to was fixed priority, 
run-until-blocked scheduling. I've just adopted this terminology. To be 
precise I should have referred to the Ada RT Annex Fifo_Within_Priority 
dispatching policy (although other respondents to my posting knew that 
that is what I was referring too).

Wondering out loud: On the other hand, it only just occurred to me that 
rate monotonic analysis techniques might also apply equally well to 
prioritized time-sliced schedulers if each task is assigned a unique 
priority (disclaimer: I'm new to this area!).

> Ada 95 does not require run-till-blocked semantics unless the RT annex
> is supported fully. Not all OS's can support the real time annex, and
> clearly GNAT on such a system does not support the annex (this is
> assuming tasks are mapped to threads). On NT, you can map to the
> real time threads, and all is well, but I don't know if this applies
> to Win95. Anyway, Greg, you are making undocumented assjmptions here!

To follow up on my thoughts above: Although a system that only supports 
prioritized time-sliced scheduling (like Win95) does not support the  
Fifo_Within_Priority dispatching policy required by the RT annex, it 
seems that most (all?) of the other features of the RT annex are 
supportable. Is this the case for Win95? Counter-example anyone?


--
* Greg Bond                         * Dept. of Electrical Eng.  
* email: bond@ee.ubc.ca             * Univ. of British Columbia      
* voice: (604) 822 0899             * 2356 Main Mall                 
* fax:   (604) 822 5949             * Vancouver, BC              
* web: http://www.ee.ubc.ca/~bond   * Canada, V6T 1Z4

Re: GNAT R/T Annex and Win95

[Wiljan Derks]

Theodore E. Dennison wrote:
> According to my NT book, there are two ways to do Timers with NT. The
> first uses the SetTimer system call. This will put a WM_TIMER event
> in the thread's normal message queue.  The resolution is ABOUT 55
> milliseconds, but there can be message queue delays. Not very useful.
> 

This remark gives the wrong impression for NT. Gnat uses things
like waitforsingleobject in its tasking implementation. For this service
one can specify a time in milliseconds, but as far as I know and any intel
system it has a resolution of 10ms.
Normally services like this one will be use for timing on NT.

> The second is the "Multimedia Timer". This timer allows you to define
> a callback that will get called directly by an interrupt, without any
> message queue processing overhead. The resolution is said to be
> "about 16 (Intel) milliseconds". Whatever that means, you can get the
> exact resolution on your system via a call to "timeGetDevCaps". (Oddly
> enough, Microsoft's example uses a resolution of 5 milliseconds) This
> is a little more useful, but still not what we would like to see.

I did not really use the multimedia timers upto now but I think one can
get resolutions upto 1 ms. I called the function timeGetDevCaps and it
reports me a minimum of 1 and a maximum of 1000000 milliseconds for
multimedia timer resolution range.

Wiljan

Re: GNAT R/T Annex and Win95

[Marin David Condic, 407.796.8997, M/S 731-93]

"Theodore E. Dennison" <dennison@ESCMAIL.ORL.MMC.COM> writes:
>A straight NT question in an Ada group, huh? Oh well...
>
>When you say "real-time", typically I think of a system with a clock
>which is capable of generating software iterrupts every 10msec or
>better, and some way of knowing when you have failed to service
>an interrupt.
>
    Well, not quite a "straight NT question." It's related to using
    Ada & WNT in real-time data acquisition systems. A quality
    compiler capable of real-time work may be pathetic in behavior if
    the underlying OS doesn't support what you need to do the job.

    Around here, 10mSec is considered pretty slow. For some of our
    monitor equipment, we are running in the neighborhood of 10mSec to
    acquire data off of a bus. But it's not at all uncommon to see
    1mSec interrupts floating about in many apps. (Not many of them
    would be targets for a WNT environment - but a WNT app may see
    data from such systems and may need that sort of granularity from
    clocks, etc.)

    Also, in most of the things we do around here, failing to service
    an interrupt is not always an option. Some systems can tolerate
    this and others can't.

>
>The second is the "Multimedia Timer". This timer allows you to define
>a callback that will get called directly by an interrupt, without any
>message queue processing overhead. The resolution is said to be
>"about 16 (Intel) milliseconds". Whatever that means, you can get the
>exact resolution on your system via a call to "timeGetDevCaps". (Oddly
>enough, Microsoft's example uses a resolution of 5 milliseconds) This
>is a little more useful, but still not what we would like to see.
>
    That's useful to know about the clock. Would you happen to know if
    this is the mechanism used by GNAT (or other implementations) for
    the "delay" statement?

    I think that one of our biggest concerns is not necessarily clock
    resolution, but more one of behavior in a non-dedicated
    environment. Some of our systems run stand-alone and in such a
    case you can generally make things work because there won't be any
    suprises. But in other systems, we may be collecting data in
    real-time from an engine test and an operator might be using the
    same computer system to run a variety of applications
    simultaneously with the engine test. We've got to insure that the
    real-time process is still going to respond properly because we
    can't afford to miss transient data or events. We may need to
    terminate a test based on transients and folks aren't generally
    amused if they have to sweep their engine up off the floor because
    the OS quit servicing the real-time process to do some
    uninterruptable job for a low priority background process.

    That's the sort of question which is being asked around here
    regarding WNT's suitability for our applications. And of course if
    WNT has mechanisms to do the job, you need to feel comfortable
    that your language mechanisms map nicely to this as well.

    Thanks for the feedback.

    Pax,
    Marin

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-93                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        407.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   MDCONDIC@AOL.COM
===============================================================================
    "If you can count your money, you don't have a billion dollars."

        --  J. Paul Getty
===============================================================================

Re: GNAT R/T Annex and Win95

[Theodore E. Dennison]

Marin David Condic, 407.796.8997, M/S 731-93 wrote:
> 
>     Well, not quite a "straight NT question." It's related to using
>     Ada & WNT in real-time data acquisition systems. A quality
>     compiler capable of real-time work may be pathetic in behavior if
>     the underlying OS doesn't support what you need to do the job.

I know where you are comming from here, but if it isn't a "straight
NT question", it at least ends up being a straight NT answer. You 
typically don't want to rely on language facilities like the delay
statement (especially the delay statement) in a true real-time 
environment. You HAVE to use OS calls, which are (mostly) language
independent. 

> >The second is the "Multimedia Timer". This timer allows you to define
> >a callback that will get called directly by an interrupt, without any
> >message queue processing overhead. The resolution is said to be
> >"about 16 (Intel) milliseconds". Whatever that means, you can get the
> >exact resolution on your system via a call to "timeGetDevCaps". (Oddly
> >enough, Microsoft's example uses a resolution of 5 milliseconds) This
> >is a little more useful, but still not what we would like to see.
> >
>     That's useful to know about the clock. Would you happen to know if
>     this is the mechanism used by GNAT (or other implementations) for
>     the "delay" statement?

I don't happen to know, but I do know enough about NT to tell you that
that would be HIGHLY unlikley. I'd expect to see a delay on NT use the
SleepEx call to suspend the thread for a given number of milliseconds.

You can't really use "delay" for real-time timing anyway (how do you
account for processing time between delay statements?) You need
something that iterrupts you at a given, reliable interval no matter
what other processing you are doing.

>     I think that one of our biggest concerns is not necessarily clock
>     resolution, but more one of behavior in a non-dedicated
>     environment. Some of our systems run stand-alone and in such a
>     case you can generally make things work because there won't be any
>     suprises. But in other systems, we may be collecting data in
>     real-time from an engine test and an operator might be using the

It looks like a multimedia timer iterrupt actually puts the rest of the
OS on hold to call your interrupt callback (my manual isn't real 
specific about this). So no matter what priority your process/thread is,
your ISR will get called at the specified interval. The manual warns 
about degragated system performance when using small intervals.

The other option, I guess, would be to set up a timer, and jack up the
priority of the process that services its message queue to real-time.
This solution isn't hard real-time, but does prevent your servicing 
thread from having the CPU witheld when its needs it.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: GNAT R/T Annex and Win95

[Dave Wood]

Robert Dewar wrote:
> 
> Marin said
> 
> "    Do you consider Windows NT capable of being a "realtime" operating
>     system? (It doesn't seem to be advertised as such.... yet.)
> 
> First, of course Windows NT is capable of realtime operatoin. You need to
> examine its specs closely, and probably stick to the realtime thread
> priority group if you want Ada-style run-till-blocked absolute
> priorities.
> 
> Second, GNAT is being used in many projects involving contract deliverables.
> The Airfields project, one of the first, perhaps the first deployed
> applications using Ada 95 was done using GNAT, and many other significant
> projects inside and outside the DoD, including for example, the high
> reliability medical equipment programs done by JEOL and the Aegis program,
> are using GNAT, which was the first validated general purpose Ada 95
> compiler, and is still the only Ada 95 techology that covers the full
> language including all the annexes.
> 
> Now you might have meant "GNAT without support" might be usable here, in
> which case that's a little more understandable, although personally I
> would not use unsupported software even for internal development.

Goodness, Robert, I can't imagine why you would say that!  ;-)

(Skip the following to avoid a semi-advertisment...)

Marin, you might also consider looking into ObjectAda for Windows from
Thomson Software Products, which is currently in beta release.  This
is the first (and still the only... *wink*) validated Ada 95 compiler 
for Windows 95 and Windows NT.  This validation was awarded last 
December and includes the real-time annex.

True, the final product with all the nice environment goodies (GUI Builder,
MFC bindings, etc.) won't ship until the summertime, but you might find
it worth the wait.

For your harder real-time needs, we're also working on an embedded Win32
solution that will be available in roughly the same time frame.

For further information, feel free to contact me directly.

-- Dave Wood dpw@thomsoft.com
-- Windows Product Manager
-- Thomson Software Products (for now, at least)
-- http://www.thomsoft.com

Re: GNAT R/T Annex and Win95

[Robert Dewar]

Dave Wood said

"Marin, you might also consider looking into ObjectAda for Windows from
Thomson Software Products, which is currently in beta release.  This
is the first (and still the only... *wink*) validated Ada 95 compiler
for Windows 95 and Windows NT.  This validation was awarded last
December and includes the real-time annex."

It is interesting to note that the Thomson compiler for NT is validated
for the full real-time annex. Actually there is one respect in which
there is a slight clash between the RT annex requirements and NT,
which is that the RT annex requires 32 priority levels, and there are
only 7 (suitable) levels in NT.

During the rather extended conversation about whether this discrepancy
was enough to say that NT could not meet the RT annex requires, or
whether this is a legitimate capacity-type restriction, I and others
insisted that Ada's definition of real time should be broad enough
to accomodate the NT approach. Ada would do itself no good being
too legalistic here. 

It's good to see that the AVO agreed, and that the Thomson compiler
is RT validated. Sure, this compiler won't meet *all* real-time
requirements, probably no compiler will, but it will meet many
real-time requirements, and if NT real-time applications are going
to me written, writing them in Ada makes sense!