Re: ADA task

["Samuel T. Harris" <u61783@gsde.hso.link.com>]

David C. Hoos, Sr. wrote:
> 
> You're right about VADS on SGI "out of the box".  However, we (Hughes
> Aircraft -- Huntsville, AL) run our process which needs higher-fidelity
> delays at non-degrading priority 39 (IRIX 5 & 6), with the fast_Hz clock
> set to 2 KHz.  You may also need to change v_usr_conf_b.a (I don't remember
> off the top of my head) to reduce that 10 ms. fudge factor to 0.  We have
> found worst-case infidelity of 2-3 ms. on a heavily-loaded (development)
> machine, but typically under 500 micro-sec., as would be expected.  The Ada
> run time gets to check for expired delays usually every 500 micro-sec.
> Normally to get priority 39, you have to run with super-user privileges,
> but we reconfigured the kernel to allow just the one priority level (the
> lowest level using the Fast_Hz clock instead of the 10 ms. sginap) to be
> run by users.  Since most don't care enough to find out how to run at that
> priority, generally only the "official" executables needing RT priority run
> this way.
> --

Except for the requirement to be super-user and the limitations
on priority levels, that is a good way to "configure" VADS to
meet the need. Some folks might find the limitations a problem
but it seems to work for you.

For us, the clock driven approach is best since we MUST stay in sync
with other distributed session hosts. All simulation assets are driven
by a central GPS coordinated CTE clock setup.

As a side note related to another thread, the package v_usr_conf_b.a
is also were one would place a custom heap memory manager, perhaps
with garbage collection (which is being discussed elsewhere in the
group).

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"