kean@mist.cs.orst.edu (Kean Stump) (04/22/88)
I need recommendations for a multi-user multi-tasking os that will run
on the following equipment:
I have a Compaq 386/20 with 5 meg ram
136 Mb hard drive
Compaq VGA card w/NEC Multisync II
20 Mhz 80387
20 Mhz Unitek coprocessor (Weitek originally, I think)
I've read SCO's literature on their brand of Sys V, Microport's literature
and a small amount on IBM's Sys V. I'm also considering Concurrent-Dos and
PC-MOS/386 as runners-up. One of the major requirements is that
real-time sampling on the order of 10K samples/sec (~40 bytes/sample) needs
to be possible (the Compaq will spend some time on a chunk of ice in the
Arctic next spring collecting data from a variety of instruments dropped
through a hole in the ice) and a good C and FORTRAN (8-<) compiler are needed.
The os should also be capable of painlessly driving a >= 60 meg tape unit;
the Everex Stream 60 we have for the pc's in the group is down more than
it is up, and Everex hands out rma's only when a small cannon is held to
their head (1/2 8-}!).
The Arnet Smartport and the Microway AT16 are the serial port expanders
currently being considered. What opinions do you have on these? I've seen
multiple good references on the Smartport, but no mention of the Microway
AT16 16 port expander in the newsgroups I (try 8->) to keep up with.
Please mail to me and I'll summarize if there's enough info to do so.
Thanks Much....kean
-------------------------------------------------------------------------------
Campus Crusade for Cthulhu...It found me. Kean Stump
Oregon State University UUCP: hplabs!hp-pcd!orstcs!kean
College of Oceanography DOMAIN: kean@cs.orst.edu
-------------------------------------------------------------------------------wes@obie.UUCP (Barnacle Wes) (05/06/88)
In article <4144@orstcs.CS.ORST.EDU>, kean@mist.cs.orst.edu (Kean Stump) writes: > > I need recommendations for a multi-user multi-tasking os that will run > on the following equipment: > > I have a Compaq 386/20 with 5 meg ram [ all sorts of goodies deleted ] > > I'm also considering Concurrent-Dos and PC-MOS/386 as runners-up. > One of the major requirements is that real-time sampling on the order > of 10K samples/sec (~40 bytes/sample) needs to be possible (the Compaq > will spend some time on a chunk of ice in the Arctic next spring > collecting data from a variety of instruments dropped through a hole in > the ice) and a good C and FORTRAN (8-<) compiler are needed. Hmmm... Have you carefully though this out? A Unix (or unix-like) system is probably not your best bet for doing data acquisition on. Unix was designed from the beginning to be a time-share system, not a real-time system. If you really need to acquire data at this rate, you will be better off sticking with good ol' boneheaded MS-DOS, where you won't have to worry about another user, or something in the crontab, blowing your data acquisition away. There are several good compilers available. High-C 386 is a screamer, and supports the 387. MicroWay sells C and Fortran compilers that generate 386 code, and support either the 387 or the Weitek. Have you thought about where you are going to store 400K/sec of data? Most hard disks will not run at that rate consistently, and definitely not if any head seeking is going on. I don't know if cartridge tape drives are fast enough, either. You may end up looking for a FAST 9-track system just to be able to store the data! That is what I've settled on at work, but some of our daq requirements are even tighter than yours. -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!uplherc! / \/ \/\/ \ - Contend in Vain." - sp7040!obie! / U i n T e c h \ - Schiller - wes
romwa@gpu.utcs.toronto.edu (Mark Dornfeld) (05/09/88)
In article <224@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >In article <4144@orstcs.CS.ORST.EDU>, kean@mist.cs.orst.edu (Kean Stump) writes: >> >> I need recommendations for a multi-user multi-tasking os that will run >> on the following equipment: >> >> I have a Compaq 386/20 with 5 meg ram > [ all sorts of goodies deleted ] >> >> I'm also considering Concurrent-Dos and PC-MOS/386 as runners-up. >> One of the major requirements is that real-time sampling on the order >> of 10K samples/sec (~40 bytes/sample) needs to be possible (the Compaq >> will spend some time on a chunk of ice in the Arctic next spring >> collecting data from a variety of instruments dropped through a hole in >> the ice) and a good C and FORTRAN (8-<) compiler are needed. > >Hmmm... Have you carefully though this out? A Unix (or unix-like) >system is probably not your best bet for doing data acquisition on. >Unix was designed from the beginning to be a time-share system, not a >real-time system. QNX is is billed as a real-time OS. It is Unix-like, multiuser but can handle the kind of thing you require. I do not have the reference handy, but mail to me and I'll look it up. Or have a look in some recent issues of Byte or PC Tech Journal; they usually advertise in there. I believe that Venix, a System V port sold by VenturCom is supposed to have some real-time capabilities. VenturCom, 215 First Street Cambridge, MA 02142 (617) 661-1230 Both of these systems will run on an 8088/6 PC. Mark T. Dornfeld Royal Ontario Museum 100 Queens Park Toronto, Ontario, CANADA M5S 2C6 mark@utgpu!rom - or - romwa@utgpu
henry@utzoo.uucp (Henry Spencer) (05/11/88)
>... A Unix (or unix-like) >system is probably not your best bet for doing data acquisition on. >Unix was designed from the beginning to be a time-share system, not a >real-time system. There is nothing about Unix that makes it inherently unsuited to be a real-time system. Real-time variants of it exist, and many labs have done quite extensive real-time work under it. All that having been said, Unix as it usually comes out of the box isn't well adapted to real-time work. Unless you have a version that has been adapted, or are capable of doing it yourself, you're probably better off with a program loader (e.g. MSDOS) that gives your program absolute control of the hardware, rather than a real operating system (e.g. Unix) that may insist on playing some part in things at inopportune times. -- NASA is to spaceflight as | Henry Spencer @ U of Toronto Zoology the Post Office is to mail. | {ihnp4,decvax,uunet!mnetor}!utzoo!henry
wes@obie.UUCP (Barnacle Wes) (05/14/88)
In some article, I embarass myself by saying: > ... A Unix (or unix-like) > system is probably not your best bet for doing data acquisition on. > Unix was designed from the beginning to be a time-share system, not a > real-time system. In article <1988May10.181259.1971@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) replied: | There is nothing about Unix that makes it inherently unsuited to be a | real-time system. Real-time variants of it exist, and many labs have done | quite extensive real-time work under it. All that having been said, Unix | as it usually comes out of the box isn't well adapted to real-time work. | Unless you have a version that has been adapted, or are capable of doing | it yourself, you're probably better off with a program loader (e.g. MSDOS) | that gives your program absolute control of the hardware, rather than a | real operating system (e.g. Unix) that may insist on playing some part | in things at inopportune times. Exactly, and well put. Most "real-time" systems have some way of specifying a minimum repsonse time expected to any event you are waiting on. On vanilla Unix, the best you can do is crank the priority for the daq process way up. MS-DOS allows you to load your program and write files on the disk in a fairly reasonable manner, and won't get in the way of your response time (hopefully). Coming up with a task scheduler in such a situation, however, is your own problem. Good Luck. :-)
vandys@hpindda.HP.COM (Andy Valencia) (05/17/88)
I've been writing a MIDI driver for the PC/AT running Microport. This requires a ceratin amount of real-time responsiveness (although the MPU-401 handles the most nitty-gritty of the real-timeness). I've found that the interrupt level is fairly responsive; it's trying to get the user process running that can take an indefinite amount of time. Depending on your application, you might be able to off-load the responsiveness into the first-level interrupt handler. Andy Valencia vandys%hpindda.UUCP@hplabs.hp.com
m5@lynx.UUCP (Mike McNally) (05/18/88)
In article <230@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: > . . . MS-DOS allows you to load your >program and write files on the disk in a fairly reasonable manner, and >won't get in the way of your response time (hopefully). . . . ``Reasonable'' is in the eyes of the reasoner. Because (at least in the 386 thing we have here) the AT hard disk controller does not use the DMA controller, the CPU must poll when transferring. The MS-DOS driver keeps interrupts off while doing this, bringing the interrupt response time down by quite a bit. -- Mike McNally of Lynx Real-Time Systems uucp: lynx!m5 (maybe pyramid!voder!lynx!m5 if lynx is unknown)
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/19/88)
In article <3771@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes: | In article <230@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: | > . . . MS-DOS allows you to load your | >program and write files on the disk in a fairly reasonable manner, and | >won't get in the way of your response time (hopefully). . . . | | ``Reasonable'' is in the eyes of the reasoner. Because (at least in | the 386 thing we have here) the AT hard disk controller does not use | the DMA controller, the CPU must poll when transferring. The MS-DOS ^^^^^^^^^^^^^^^^^ | driver keeps interrupts off while doing this, bringing the interrupt | response time down by quite a bit. As I'm sure a lot of people will tell you, that's the way the beast is implemented, not the way it *must* be done. Xenix and OS/2 seem to be able to run just fine using DMA mode and interrupts. The problem is that MS-DOS is more or less a knock off of CP/M, and since it's not multi tasking it has nothing better to do with the CPU than wait. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
kevinr@june.cs.washington.edu (Kevin Ross) (05/20/88)
In article <10889@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <3771@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes: >| ``Reasonable'' is in the eyes of the reasoner. Because (at least in >| the 386 thing we have here) the AT hard disk controller does not use >| the DMA controller, the CPU must poll when transferring. The MS-DOS > ^^^^^^^^^^^^^^^^^ > As I'm sure a lot of people will tell you, that's the way the beast is >implemented, not the way it *must* be done. Xenix and OS/2 seem to be >able to run just fine using DMA mode and interrupts. The problem is that >MS-DOS is more or less a knock off of CP/M, and since it's not multi >tasking it has nothing better to do with the CPU than wait. Actually, DOS could have implemented a DMA transfer from the controller. I think they really should have / or still should implement this. Sure, the CPU might not have anything better to do than to wait for the CPU, but it also should use DMA as the transfer mechanism when the IO is completed. This would definitely speed things up. Another route they should have taken was to add a no busy wait option to the call. Then, at least, the CPU could be used for more productive jobs than sitting in a tight loop. When a program gets to a point where the data is crucial, it can call a wait routine. Of course, many programs would not be able to deal with this, but how sweet it would be to have the option. You could be working with a database routine that prefetchs the next records while working on the current records. Ah, but then, hindsight makes for easy complaining. Kevin Ross kevinr@june.cs.washington.edu ..uw-beaver!june!kevinr Home: ..uw-beaver!tikal!camco!carmine!kevin