[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:	VAX and Alpha VMS
Notice:	This is a new VMSnotes, please read note 2.1
Moderator:	VAXAXP::BERNARDO

Created:	Wed Jan 22 1997
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	703
Total number of notes:	3722

305.0. "Reserving CPU for realtime processes?" by IMPERO::BELLONI (CHMP = Change mode to Paraglide) Tue Mar 11 1997 11:47

	Hello,

  In a joint venture between two major European aerospace industries, one of
their development team is proposing to use several alpha machines running
OpenVMS to realize a multiprocessor system where there will be a mix (!) of
realtime processes and normal general purpose processes. Someone is thinking to
build the realtime applications (which need, by the way, to perform I/O
operations toward and from external acquisition systems) reserving one or more
processors for this specific use. Due to these strange ideas the question they
ask us are: 

1) Is it possible, on OpenVMS, to reserve  one or more CPU for specific
realtime-like operations, excluding them from being used by other processes?

2) if yes, with what kind of code this could be done (something similar to a 
PPL$ routines, or only with macro code)?

3) if yes, there should be also the capability to help these realtime- like
processes to have a sort of realtime access to the I/O devices on the bus. Is
this possible, and how? 

  I know that these are weird requests (personally I never think to mix 
realtime with gp processes!), but I need some good answer (if this is the case)
to give to the Development team so to avoid this kind of implementation.
Any answer, maybe helped with pointers to specific literature, is very
appreciated. 

	Many thanks in advance for any help.
						Max

T.R	Title	User	Personal Name	Date	Lines
305.1	Try to make it real compared to what	GREGOR::OPP		`Tue Mar 11 1997 13:11`	22
	Regardless of the fact that OpenVMS offers the "real-time" process priority range from 16-31, it's not a true real-time operating system due to several factors, such as the lack of a maximum time to service an interrupt. I've had painful experi- ences with customers trying to mix real-time processes and time- sharing processes on VAX Systems running OpenVMS. It's a dif- ficult task and one which most customers do not have the disci- pline or skills to manage. It's much better if the real-time tasks can be assigned to dedicated real-time systems with well- defined interfaces between the time-sharing systems and the real-time systems. You might try asking this question in the REALTIME Notes conference. I believe it's at HELIX::NOTES$LIBRARY. From a historical perspective, the real-time operating systems that Digital sold (and which I recall) were RT-11 and VAXeln. If there are any descendents of these for Alpha, they are probably good candidates for the most time-sensitive tasks. Greg
305.2	Yes, DECthreads, Fast I/O or Driver Context...	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Tue Mar 11 1997 14:21`	26
	:1) Is it possible, on OpenVMS, to reserve one or more CPU for specific :realtime-like operations, excluding them from being used by other processes? :2) if yes, with what kind of code this could be done (something similar to a :PPL$ routines, or only with macro code)? :3) if yes, there should be also the capability to help these realtime- like :processes to have a sort of realtime access to the I/O devices on the bus. Is :this possible, and how? See HELP SET PROCESS /AFFINITY on an OpenVMS Alpha V7.0 or later system, and see Chapter 4 (CPU Scheduling) in the V7.0 New Features Manual. If you need real-time access from a real-time process beyond what $qio[w] or the fast-I/O services can provide, I'd look at creating a device driver, and operating in kernel mode. Under OpenVMS Alpha, one can write device drivers in C. DECthreads superceded PPL quite some time ago, and -- with V7.0 and later (noticing a trend in OpenVMS version numbers? :-) -- can take advantage of Kernel Threads and can run the threads of a process on seperate processors. And again, see the V7.0 New Features Manual. Depending on what these folks mean by "real-time" -- there is no general definition of this phrase --- mixing real-time and time-share may not be a good idea -- even with the dedicated processors and/or user-written (class) scheduler...