barnett@vdsvax.steinmetz.UUCP (Bruce G Barnett) (08/24/87)
I have always heard that Unix isn't real time because: If a real-time event causes a change in priorities and scheduling while a system call was executing, the system call won't be interrupted. That is, the system does not reschedule in the middle of a system call, and the potential delay for an urgent real-time event is equal to the length of time of the longest system call. I am not talking about interrupts, but a change in priorities as a result of a real-time event ( i.e. the device driver handling an interrupt). I have believed, but never implemented, that if you need fast response you do it in the device driver. If necessary, you can write a pseudo-device driver, and bind it into the kernal. This can give you procedures that any process can have access to with the same overhead as a system call. I assume if you can specify which applications, processes, and deamons are running, and give some processes highest priority, you can improve the real time response. So perhaps the question is, do you need fast responses? or real time? Any comments? Has anyone done this? -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
chris@mimsy.UUCP (Chris Torek) (08/25/87)
In article <2340@vdsvax.steinmetz.UUCP> barnett@vdsvax.steinmetz.UUCP (Bruce G Barnett) writes: >I have always heard that Unix isn't real time because: > > If a real-time event causes a change in priorities and > scheduling while a system call was executing, the system call > won't be interrupted. This is true for at least the 4BSD kernels: Scheduling is preemptive, but there is no kernel preemption. One easy way to reduce interrupt-to-user-run latency is to sprinkle various invocations of if (runrun) { /* want to run another process */ (void) splclock(); setrq(u.u_procp); u.u_ru.ru_nivcsw++; kern_preempt++; /* statistics */ swtch(); } calls in `safe' places in the kernel, e.g., while no inodes are held. HP has done something like this. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
zjat02@apctrc.UUCP (Jon A. Tankersley) (06/06/88)
Does anyone have any information on any good real-time systems based on 386 and UNIX. We are looking for some process control systems based on the 386 that can handle real-time latency down to .25 to .50 seconds. Please email any replies. thanx -tank-
xklaus@norisc.UUCP (Klaus Neuberger) (07/27/90)
I need a real-time version of UNIX (preferably sysV compatible) to run on an IBM pc ('386). Could you please E-mail me with any information you have on suitable systems along with the name and contact address of the manufacturer/distributer. Thanks, Klaus. -- Name: Klaus Neuberger Phone: +49 911 895 2093 EMail: unido!estevax!norisc!xklaus SMail: Siemens AG, AUT E543, Gleiwitzer Strasse 555, Nuernberg-M, W-Germany
larry@focsys.uucp (Larry Williamson) (07/28/90)
An excellent package is produced by VenturCom in the US. They use Interactive's Unix (2.0.2) as the basis and then add a driver and modify a couple of kernel functions to provide the real time response. They call their system RTX (They may have recently started to call it Venix/386, but I'm not sure). Some additional features they have included are: . millisecond timers . direct physical memory access from user processes . direct io port access from user processes . Very fast interrupt response time . Memory locking . Real time synchronization . Asynchronous I/O . High performance file system We have had no compatiblity problems with any application we've run with this system. It is as pure Interactive Unix System V 3.2 as you can get. They have some excellent documentation on performance metrics for their system. Price is pretty good too. I don't know what it will cost you in Europe. I normally talk with Kara Phelan. VenturCom Cambridge, Mass. (617) 661-1230 -larry
steve@nuchat.UUCP (Steve Nuchia) (07/28/90)
In article <LARRY.90Jul27140311@focsys.uucp> larry@focsys.uucp (Larry Williamson) writes: >An excellent package is produced by VenturCom in the US. They use Excellence is in the eye of the beholder. It does work, but you should really be very careful using it for "hard" realtime. For soft realtime it has everything you should need. The dividing line here seems to be about 500 usec. >Interactive's Unix (2.0.2) as the basis and then add a driver and >modify a couple of kernel functions to provide the real time response. Bzzzzt. They change the scheduler and add a filesystem, they change the way supervisor/user mode is handled, though I'm not sufficiently imtimate with the 386 to guess how. They claim to have diddled the spl mechanism, and a few other things, in addition to their driver and dozen or so new system calls (which actually multiplex through a single trap, but so what?) >They call their system RTX (They may have recently started to call it >Venix/386, but I'm not sure). The product name seems to be venix, the shorthand form seems to be rtx (ie, #include <rtx.h>). Seems to be in transition. >Some additional features they have included are: >. millisecond timers Millisecond resolution in the program interface spefication, actual resolution is 10 ms (HZ=100) and discoverable through one of their calls. >. direct physical memory access from user processes >. direct io port access from user processes They appear to just hand over supervisor mode to the user task, you have to be (effectively) root to turn it on, then you can setuid. >. Very fast interrupt response time Uhm, they may have sped it up some but I wasn't that impressed. >. Memory locking The memory locking call also allows you to pre-allocate both data and stack space which brk and sbrk then play around in as you might hope. Semantics when brking past the preallocated part are reasonable, but semantics with respect to shared memory are unspecified. >. Real time synchronization Not sure what you or they mean by this. They allow you to use a fixed-priority scheduler, which has a specified discipline to yield round-robin fasion to other processes at the same level. They also have a cpu-fraction scheduling feature, implementing approximately standard nice(2) semantics within scheduling groups, and fractional distribution between groups. The proportional scheduler's policies with regard to balancing long-term and short-term usage are not specified, and in fact its semantics are not well defined at all. Normal processes are scheduled in the "default group", which by default has 100% of the cpu (after fixed-priority tasks get done with it). Flexible enough, but I haven't needed it so haven't actually wrung it out. >. Asynchronous I/O Only for driver that have been modified to support it. The required modifications appear to be straightforward, but (at the risk of flaggelating a not-altogether-healty horse) not well documented. >. High performance file system So far this doesn't look like much of a win, especially since it has some really unfortunate semantics. Like you can't use cp(1) to copy files in it ... If you need to get closer to the raw disk throughput than you can get with asynch io to a normal file, you should probably buy a faster disk subsystem. >We have had no compatiblity problems with any application we've run >with this system. It is as pure Interactive Unix System V 3.2 as you >can get. Until you turn on the real-time features you can't tell the difference. >They have some excellent documentation on performance metrics for >their system. I dissagree, violently. As has become customary, they tell you almost everything you might care to know about syntax, and almost nothing about semantics. Their performance puff-piece has some gaping holes. If you really need relaible real-time performance you *must* avoid doing/using certain things, and they don't do a very good job of enumerating them. I won't bore you with the list, because a) it's at a client shop and b) if you need that kind of performance I trust you're smart enough to read between the lines yourself. Their "excellent documentation" appears to consist of the half-crate from Interactive plus a ~100 page pamplet attempting to document their additions/changes, a small stack of "release notes" correcting and updating that pamplet, and the afore-mentioned puff piece. In conclusion: If you have a "real-time" job to do and it doesn't demand real iron and real software, this stuff is pretty good. It adds the few things you are likelty to really need, and it adds them inobtrusively. I would never use it for a safety-critical system in which sub-milisecond deterministic response was required, but it is well-suited to a very large class of tasks for which raw interactive is not. -- Steve Nuchia South Coast Computing Services (713) 964-2462 "To learn which questions are unanswerable, and _not_to_answer_them; this skill is most needful in times of stress and darkness." Ursula LeGuin, _The_Left_Hand_of_Darkness_
john@touch.touch.com (John Weald) (07/31/90)
In article <LARRY.90Jul27140311@focsys.uucp> larry@focsys.uucp (Larry Williamson) writes: > >An excellent package is produced by VenturCom in the US. They use >Interactive's Unix (2.0.2) as the basis and then add a driver and >modify a couple of kernel functions to provide the real time response. >They call their system RTX (They may have recently started to call it >Venix/386, but I'm not sure). I missed the original article but.... For a real time POSIX UNIX on a i386 try LynxOS. We are about to use them in-house for a project. They have a fully preemptible kernel and other good stuff you would expect of a real time OS. They support X, TCP/IP, NFS client. You can reach them at: Lynx Real-Time Systems 16780 Lark Ave. Los Gatos CA 95030 408-354-7770 -- John Weald, Touch Communications, Campbell, CA uunet!touch!jweald jweald@touch.com