REILLY@wharton.upenn.edu (04/06/88)
I'm looking for a real time UNIX box to take in serial input from 3 IBM PC's at 1000 bits/s, and input from another device (not serial, to be determined) at 1.2 E 6 bits/s, and then write all this data in real time to a tape (possibly a Digidata drive, which support 1.2Mbytes/s) Any directions would be most appreciated.
dave@riacs.edu (Dave Gehrt) (04/06/88)
In article <12825@brl-adm.ARPA> REILLY@wharton.upenn.edu writes: >I'm looking for a real time UNIX box... There was an outfit in San Diego called Alcyon, sorry but I have no phone number for them, who were the developers of REGULUS, which is a Unix like operating system with some real time extensions. I used this operating system, but not for real real time, and it was OK. The box (*not* an Alcyon box) on which I used REGULUS had problems (not enough memory and a 68000 SBC) which made the system more difficult to use than Unix. Alcyon makes (or did make) a VME system with REGULUS on it. I seem to recall that at one time there was talk of AT&T annointing REGULUS as a real time Unix. REGULUS provides the capability to hook a user process to an interrupt, and a couple of other system calls to support real time operations. Hpe this helps, dave
lm@arizona.edu (Larry McVoy) (04/06/88)
In article <765@hydra.riacs.edu> dave@hydra.riacs.edu.UUCP (Dave Gehrt) writes: >In article <12825@brl-adm.ARPA> REILLY@wharton.upenn.edu writes: >>I'm looking for a real time UNIX box... > >There was an outfit in San Diego called Alcyon, sorry but I have no phone >number for them, who were the developers of REGULUS, which is a Unix like >operating system with some real time extensions. If I'm not mistaken I played with regulus a long time ago. My opinion is that you would be better off with Masscomp boxes. They have a real unix environment (sys V and BSD universes - someone else does this too - and can stream 5 megs / sec to disk - can't remember if it's bits or bytes). -- "These aren't my thoughts, they're my cat walking on the keyboard." Larry McVoy lm@arizona.edu or ...!{uwvax,sun}!arizona.edu!lm
decot@hpisod2.HP.COM (Dave Decot) (04/07/88)
Hewlett-Packard offers a broad range of technical systems which run HP-UX, a version of UNIX conforming to Version 3 of AT&T's System V Verification Suite (SVVS) that verifies conformance to the System V Interface Definition (SVID). HP-UX also includes most of the important 4.2BSD features (such as vi, csh, Berkeley-based kernel and fast file system, job control, rlogin, rcp, ARPA networking (TCP/IP), sockets), many defacto standards (such as NFS, ksh, kermit, etc.), plus many HP enhancements. The HP enhancements for real-time include the following: Non-degrading process priorities Kernel is pre-emptable by high-priority user processes Virtual, real, and user interval timers Reliable signal mechanism based on that of 4.2BSD Multiplexed I/O arbitration based on that in 4.2BSD Locking of processes or parts of processes in physical memory Pre-allocation of disc space for important files For more specific detail and up-to-date pricing information, please write to me, or call 800-752-0900 for the location of the nearest HP sales office. Dave Decot hpda!decot Hewlett-Packard Company Cupertino, CA 94087 -------- Disclaimer: This message is for informative purposes only and does not constitute an official HP product offering. Unix is a registered trademark of AT&T. Copyright (c) 1986, 1987, 1988 HP
dalesys@lamont.Columbia.edu (dale chayes) (04/08/88)
We have been routinely running a realtime acq with about a dozen active serial lines comming from all kinds of odd ball devices (most of which we have no controll over data formats) into a Masscomp 5400 with no complaints. Masscomp's RTU allows more control over real time processes than most other variants of unix while at the same time preserveing a reasonable approximation to BSD and SYSV unicies. Dale Chayes Lamont-Doherty Geological Observatory of Columbia University usmail: Route 9W, Palisades, N.Y. 10964 voice: (914) 359-2900 extension 434 fax: (914) 359-6817 usnet: ...philabs!lamont!dale -- Dale Chayes Lamont-Doherty Geological Observatory of Columbia University usmail: Route 9W, Palisades, N.Y. 10964 voice: (914) 359-2900 extension 434 fax: (914) 359-6817 usnet: ...philabs!lamont!dale
ron@topaz.rutgers.edu (Ron Natalie) (04/10/88)
I have recently completed an application using UNIX on a MULTIBUS II 386 system (note that these boxes tend to be a bit expensive as there aren't a lot out there yet). I read from a dataloggin recorder that drops 32K blocks on me every tenth of a second (and can't reposition so I have to pick them up) and write them to a Storage Tek 6250 tapdrive (I hate Digidata). Multibus II is fun for this type of application. The use of the Ciprico tape controller makes life fun because I can just throw the received 32K blocks at it and let it run the tapedrive. Unlike a normal UNIX device driver the Ciprico has no queue of I/O's in the driver. You just keep chucking the MBII messages at it and it will send you back the answers when it is done. -Ron
lynn@engr.uky.edu (H. Lynn Tilley) (04/12/88)
In article <479@clipper.lamont.Columbia.edu> dalesys@lamont.Columbia.edu (dale chayes) writes: > >Masscomp's RTU allows more control over real time processes than >most other variants of unix while at the same time preserveing >a reasonable approximation to BSD and SYSV unicies. > I would be interested in any comments about Harris Corp. HS/UX which is another real-time UNIX. Harris has a specific bus they use for realtime data acquisition on their UNIX box and I know that General Dynamics is very heavy into Harris equipment on the F-16 production line (probably the old H1000/800 line). I am most interested in the small Harris stations and the MCX line, but any comments on the hcx line would be welcome also. We have one of the first hcx-7s here, they are great machines but we have done absolutely zero realtime stuff with it. Also, how does this compare to HPs stuff (from what I have seen HP does all their realtime control/acquisition using realtime independent controllers). Any thought or comments would be appreciated. -- | Henry L. Tilley UUCP: {cbosgd|uunet}!ukma!ukecc!lynn | University of Kentucky CSNET: lynn@engr.uky.edu V Engineering Computer Center BITNET: lynn%ukecc.uucp@ukma O voice: (606) 257-1752 ARPANET: lynn@a.ecc.engr.uky.edu
preece%fang@xenurus.gould.com (Scott E. Preece) (04/12/88)
From: REILLY@wharton.upenn.edu > I'm looking for a real time UNIX box to take in > serial input from 3 IBM PC's at 1000 bits/s, and > input from another device (not serial, to be > determined) at 1.2 E 6 bits/s, and then write > all this data in real time to a tape (possibly > a Digidata drive, which support 1.2Mbytes/s) ---------- Gould has recently added a number of specifically real-time features to its UTX/32 operating system (which provides both BSD and System V environments). The new features include connected interrupts (user-level routines entered directly in interrupt context or through signals triggered by hardware interrupts), a cyclic scheduler (good for polling things), real-time scheduling priorities (FIFO, fixed priorities higher than the normal Unix priorities), and a direct i/o facility that lets you construct and execute i/o commands for special devices with very little OS involvement). There is also a hardware privilege mode, which allows user programs to execute i/o instructions directly. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!urbsdc!preece arpa: preece@Gould.com
verber@apatosaur.cis.ohio-state.edu (Mark Verber) (04/13/88)
I won't swear to it but... I would bet that the Harris HS/UX is the same as the Realtime UNIX from Masscomp. A while ago Harris send our department a "Harris Workstation" which seems to be a Masscomp with a Harris label. Cheers, ----------------------------------------------------------------------- Computer Science Department Mark A. Verber The Ohio State University verber@tut.cis.ohio-state.edu +1 (614) 292-7344 cbosgd!osu-cis!verber
limes@sun.uucp (Greg Limes) (04/13/88)
In article <10337@tut.cis.ohio-state.edu>, verber@apatosaur.cis.ohio-state.edu (Mark Verber) writes: > I won't swear to it but... I would bet that the Harris HS/UX is the > same as the Realtime UNIX from Masscomp. I will swear to it. In a previous incarnation, I had the task of upgrading a Masscomp machine from RTU3.1b to RTU3.1c; since the task had been sitting around, there were two dusty upgrade disks. Guess what, one was from Masscomp and the other from Harris. Binary compares on the information showed differences only in the *COPYRIGHT* notices, even in the binaries; the word "Masscomp" was simply replaced with " Harris ". > Computer Science Department Mark A. Verber > The Ohio State University verber@tut.cis.ohio-state.edu > +1 (614) 292-7344 cbosgd!osu-cis!verber -- Greg Limes [limes@sun.com]
haral@unisol.UUCP (Haral Tsitsivas) (04/16/88)
In article <49277@sun.uucp> limes@sun.uucp (Greg Limes) writes: >In article <10337@tut.cis.ohio-state.edu>, verber@apatosaur.cis.ohio-state.edu (Mark Verber) writes: >> I won't swear to it but... I would bet that the Harris HS/UX is the >> same as the Realtime UNIX from Masscomp. > >I will swear to it... Yes, It is true that the Harris MCX workstations are (OEM'd) Masscomp workstations. However, the Harris HCX line is engineered by Harris and run a hybrid System V/4.2 BSD port (they retained the nice features out of BSD). I also thought that they also OEM'd some CCI gear but I don't remember their model numbers... --Haral Tsitsivas UniSolutions Associates (213) 641-6739 ...!uunet!scgvaxd!ashtate!unisol!haral
jfh@rpp386.cactus.org (John F. Haugh II) (10/16/89)
In article <21153@adm.BRL.MIL> Kemp@DOCKMASTER.NCSC.MIL writes: >Doug Gwyn writes: > > Need guaranteed real-time response for certain processes. > >Gee Doug, how do you do that one, other than running under Masscomp's >Real-Time Unix or using a slave processor with something like VRTX or >VX/Works? I was under the impression there was a real-time UNIX from AT&T as I saw references to UNIX/RT ages ago. I can't imagine AT&T dumping something useful. [ Then again ... ] Also, I saw references to MERT in the 1978 BSTJ UNIX edition. Isn't this available for hosting real-time UNIX implementations? >Or by "real-time" do you mean "anything under 10,000 usec"? :-) Easy. Buy a TIMEX Sinclair. ;-) -- It is very worth pointing out that Plexus used UNIX kernels on their serial I/O processor cards. I don't know if anyone from Plexus [ is there still a Plexus??? ] is listening and has any info on that implementation. -- John F. Haugh II +-Things you didn't want to know:------ VoiceNet: (512) 832-8832 Data: -8835 | The real meaning of MACH is ... InterNet: jfh@rpp386.cactus.org | ... Messages Are Crufty Hacks. UUCPNet: {texbell|bigtex}!rpp386!jfh +--------------------------------------
ka@cs.washington.edu (Kenneth Almquist) (10/17/89)
> In article <21153@adm.BRL.MIL> Kemp@DOCKMASTER.NCSC.MIL writes: >> Or by "real-time" do you mean "anything under 10,000 usec"? :-) In case anyone is confused by this: "real time response" does not mean "fast response"; it means "response within a certain time bound." The time bounds for the UUCP communication protocol, for example, are measured in seconds. This means that under standard UNIX, which does not do real time scheduling, UUCP will not work under certain types of heavy loads. Real time applications are more likely to have time bounds measured in milliseconds or microseconds, but they don't have to. jfh@rpp386.cactus.org (John F. Haugh II) writes: > I was under the impression there was a real-time UNIX from AT&T > as I saw references to UNIX/RT ages ago. > > Also, I saw references to MERT in the 1978 BSTJ UNIX edition. > Isn't this available for hosting real-time UNIX implementations? MERT stands for "Multi-Environment Real Time". UNIX/RT is just a later name for the same system. MERT was a structured operating system, in contrast to UNIX, where the kernel was one big blob. It was an interesting system, but not exceptionally good for real time work (despite the name). You could write kernel processes, which were similar to UNIX device drivers. You could also write supervisor/user processes, which are similar to UNIX processes. A supervisor/user process had a supervisor address space and a user address space. To run a UNIX program, you placed a UNIX emulator in the supervisor address space of a process and the UNIX program in the user space. Getting real time performance out of a kernel process was very similar to getting it out of a UNIX device driver. To get real time performance out of a supervisor/user process, you had to deal with two issues: First, the scheduler had to select the right process. The priority of most MERT processes changed based upon factors such as CPU usage. However, you could set processes to a fixed high priority. You could not request anything like deadline scheduling. Priority scheduling is adequate for many real time applications, but the programmer has to determine what the priorities should be, and there are situations that deadline scheduling will handle that priority scheduling cannot. Second, once the scheduler selected the right process it had to start the process running. The UNIX emulator avoided concurrent accesses to data structures by inhibiting context switches during system calls (except when the system call explicitly blocked). This meant that if you used the UNIX emulator, you had to add the execution time of the longest system call to the basic context switch time. In addition, if your process was swapped out when the scheduler selected it, the process would have to be swapped in. MERT allowed you avoid this by locking your process in memory. MERT support for the PDP-11 was dropped primarily because if you wanted to run UNIX processes, native UNIX was faster. A variant of MERT called DMERT runs on AT&T's 3B20 Duplex machines. MERT was never ported to any other machines. System V picked up the process locking feature (see plock(2)) but not the fixed process priorities. Kenneth Almquist
news@bbn.COM (News system owner ID) (10/17/89)
jfh@rpp386.cactus.org (John F. Haugh II) writes:
< It is very worth pointing out that Plexus used UNIX kernels on
< their serial I/O processor cards. I don't know if anyone from
< Plexus [ is there still a Plexus??? ] is listening and has any
< info on that implementation.
Oooooo Ick! That must have been a mistake.
Since I'm fairly new (I started by playing with 4.1 BSD), I'll ask a
few of the old(er)-timers out there: has there ever been a UNIX serial
driver that worked right?
What I (personally) want to see is something that will do some version
of the normal cooked vs. not processing (pref. designed to be
configurable, like Sys V's, rather than hacked, like Berkeley's), will
actually _do_ hardware flow control, correct modem control, sync, and
async if the hardware can (without reconfiguring the kernal to do so),
and is eficient enough to handle sustained input at 38.4Kbps (if the
system has a DMA serial board). It should also handle non-blocking
I/O, and deliver SIGIOs, if asked. And the user should be able to
tell it to allocate bigger, smaller, default, etc. amounts of input
buffer storage.
Yes, the 38.4Kbps and flow control, etc. are highly dependant on the
hardware, but in the "newer" UNIXen, on machines with perfectly
capable hardware, getting this all to work for a user-level process is
like pulling teeth (or just plain imposible).
Show me all this, and I will show you a happy serial I/O hack indeed.
The current ones are set up for the special case of talking to an
ordinary terminal. Unfortunately, there are much more things that can
be done with a serial line...
-- Paul Placeway <PPlaceway@bbn.com>der@cbnewsl.ATT.COM (david.e.rorke) (10/21/89)
In article <9509@june.cs.washington.edu>, ka@cs.washington.edu (Kenneth Almquist) writes: > > jfh@rpp386.cactus.org (John F. Haugh II) writes: > > I was under the impression there was a real-time UNIX from AT&T > > as I saw references to UNIX/RT ages ago. > > > > Also, I saw references to MERT in the 1978 BSTJ UNIX edition. > > Isn't this available for hosting real-time UNIX implementations? > > MERT stands for "Multi-Environment Real Time". UNIX/RT is just a > later name for the same system. MERT was a structured operating > system, in contrast to UNIX, where the kernel was one big blob. > . > . > . > MERT support for the PDP-11 was dropped primarily because if you > wanted to run UNIX processes, native UNIX was faster. A variant of > MERT called DMERT runs on AT&T's 3B20 Duplex machines. MERT was never > ported to any other machines. System V picked up the process locking > feature (see plock(2)) but not the fixed process priorities. > Kenneth Almquist Real time scheduling is available (or will be in a couple weeks) in System V Release 4.0. The SVR4.0 process scheduler supports multiple concurrent scheduling policies through a switch mechanism (somewhat like the file system switch). Time sharing and real time policies are provided with SVR4.0 and the interface between generic and policy specific scheduling code is well defined to facilitate development of additional policies (although AT&T is not currently promising to support this kernel interface unchanged in future releases). The real time policy provides priority scheduling where the priority is completely controlled by the user level application. Preemption points have been added into long code paths in the kernel to reduce the delay to a high priority real time process which becomes runnable while a lower priority process is running in the kernel. Dave Rorke AT&T Bell Laboratories Summit, NJ att!attunix!der 201-522-6025
bobmon@iuvax.cs.indiana.edu (RAMontante) (10/22/89)
der@cbnewsl.ATT.COM (david.e.rorke) <2396@cbnewsl.ATT.COM> : - -Real time scheduling is available (or will be in a couple weeks) I LOVE it!
vic@zen.co.uk (Victor Gavin) (10/23/89)
In article <28256@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: >der@cbnewsl.ATT.COM (david.e.rorke) <2396@cbnewsl.ATT.COM> : >- >-Real time scheduling is available (or will be in a couple weeks) > >I LOVE it! Huh?? AT&T have only *just* got around to adding Real Time to their kernel?? How do you poor people cope :-) Most of the big boys haven't waited for AT&T, they've seen the need and done the job. HP have had it on their 800 series since the very beginning (about 2 and a half years ago!) And they wonder why the Open Software Foundation was set up :-) vic
andyc@hpopd.HP.COM (Andrew Cunningham) (10/25/89)
/ hpopd:comp.unix.wizards / bin@primate.wisc.edu (Brain in Neutral) / 5:02 pm Oct 19, 1989 / > level of the individual with respect ot their UNIX knowledge. > ie: NOVICE: > Calls vi vye > etc >I have *never* heard *anyone* call "vi" vee-eye. Including wizards. How you pronounce /usr/ucb/vi (or /usr/bin/vi, if you have HP-UX or some similar system) depends less upon how long you've used UNIX and more on who taught it. I call it lots of things, none of which begin with `v'...... :-) -------------------------------------------------------------------------------- DISCLAIMER: I am not speaking as an employee of Hewlett-Packard. Andrew Cunningham, HP Software Engineering Systems Division, Pinewood E-mail: andyc@hpopd.HP.COM hplabs!hpopd!andyc
brian@ucsd.Edu (Brian Kantor) (10/25/89)
Around here, people who call it 'vye' are the secretaries, undergrads, and VMS administrators. The wizards call it 'vee-eye'. HP-UX is 'hockey-pucks'. Or 'hockey-pukes'. The first tends to degrade into the latter the longer you work on it. - Brian
jerry@altos86.Altos.COM (Jerry Gardner) (10/26/89)
In article <10072@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes: >Around here, people who call it 'vye' are the secretaries, undergrads, >and VMS administrators. The wizards call it 'vee-eye'. I call it 'trash'. -- Jerry Gardner, NJ6A Altos Computer Systems UUCP: {sun|pyramid|sco|amdahl|uunet}!altos86!jerry 2641 Orchard Parkway Internet: jerry@altos.com San Jose, CA 95134 I survived the Big One, October 17, 1989 946-6700
dtynan@altos86.Altos.COM (Dermot Tynan) (10/27/89)
In article <3709@altos86.Altos.COM>, jerry@altos86.Altos.COM (Jerry Gardner) writes: > In article <10072@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes: > > The wizards call it 'vee-eye'. > > I call it 'trash'. > Jerry Gardner, NJ6A Altos Computer Systems This is the same guy who admitted to having a 25Mhz / 24Megabyte Altos-2000 in his office as a "personal" system. You can *afford* to run emacs. You're probably the first person in history to *ever* have all of emacs in core, at the same instant in time!!?! Sorry, Jerry, couldn't resist :) - Der -- dtynan@altos86.Altos.COM (408) 946-6700 x4237 Dermot Tynan, Altos Computer Systems, San Jose, CA 95134 "Far and few, far and few, are the lands where the Jumblies live..."
es@sinix.UUCP (Dr. Sanio) (11/09/89)
In article <2808@convex.UUCP> thurlow@convex.com (Robert Thurlow) writes: >doug@herbert.uucp (Doug Phillipson 5-0134) writes: > [ .. stuff about vi .. ] PLEASE, don't restart editor wars in this group. Usenet oldies may tell how many times it has been led up to now (100 or more?). It always starts the same way: somebody posting "I hate $THATEDITOR, only $MYEDITOR is accep- table" , then reply "O that shit $MYEDITOR .." etc etc . If I had the $$ that costed since the beginning of usenet, I would be a rich man. So, be merciful, just STOP IT . thanx, es
pechter@ocpt.ccur.com (Bill Pechter <pechter>) (11/12/89)
In article <2808@convex.UUCP>, thurlow@convex.com (Robert Thurlow) writes: > doug@herbert.uucp (Doug Phillipson 5-0134) writes: > >People say that vi is expert friendly but it is no harder to learn > >than WordPerfect. Word Perfect is one of the hardest PC editors to learn. It's certainly a bad example if you're trying to prove your point. > > I use 'vi' daily, and while I won't be without it and don't care much > for most Emacsen, I'll never say 'vi' is easy to learn. I've just > watched too many people struggle with it. It's not so bad if you have > a good model of what an editor does, and just need to pick up the ways > THIS editor does things, but it's a fright to a novice. Of course, it > *is* a programmers editor ... > > I'd love an inteface more like WPS on the old PDP-8 - it worked much > better. EDT and LSE were one of the easier things to pick up when I > did a VAX/VMS project awhile ago ... > Agreed. WordStar, EDT and Ked fall short on some things -- but all are easier to learn than vi. I'm going to get Small-EDT up on my Unix boxes as soon as I can get the code moved from MS-DOS. The one good thing about vi is (like edlin on MS-DOS) is it's a standard across the Unix arena and it will let you work immediately on any machine running Unix. Bill -- Bill Pechter -- Home - 103 Governors Road, Lakewood, NJ 08701 (201)370-0709 Work -- Concurrent Computer Corp., 2 Crescent Pl, MS 172, Oceanport,NJ 07757 Phone -- (201)870-4780 Usenet . . . rutgers!pedsga!tsdiag!scr1!pechter ** MS-DOS is CP/M on steroids, bigger, bulkier and not much better **
sean@cadre.dsl.pitt.edu (Sean McLinden) (11/25/89)
In article <17@ocpt.ccur.com> pechter@ocpt.ccur.com (Bill Pechter <pechter>) writes: >The one good thing about vi is (like edlin on MS-DOS) is it's a standard >across the Unix arena and it will let you work immediately on any >machine running Unix. So is Morse Code but you wouldn't want to have to communicate with it!