Re: GNAT R/T Annex and Win95

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

"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
===============================================================================