dick@lhs.woodside.ca.us (dick benster) (04/24/91)
We would like to hook up many modems to a NeXT '040 cube, and wondered if anybody sells a MUX that supports at least 8 serial lines (and has the appropriate NeXT system software so it's usable!). An ethernet-based MUX solution is also a possibility. Does anybody know about this, or even have some experience with an existing product? Thanks! Dick Benster
news@NeXT.COM (news) (04/26/91)
In article <9104240831.AA01164@lhs.woodside.ca.us> dick@lhs.woodside.ca.us (dick benster) writes: > We would like to hook up many modems to a NeXT '040 cube, and > wondered if anybody sells a MUX that supports at least 8 serial lines > (and has the appropriate NeXT system software so it's usable!). An > ethernet-based MUX solution is also a possibility. Does anybody know > about this, or even have some experience with an existing product? > > Thanks! > > Dick Benster I have seen products from UNINET that do this. They have several configurations of 4/8 serial and parallel ports. They have done some clever things things using pty's and the SCSI port to do this. The particulars are: UNINET 1209 E. Warner Avenue Santa Ana, CA 92705 (714) 546-1100 (714) 546-3726 FAX Hope this helps! Brent Loschen
bennett@mp.cs.niu.edu (Scott Bennett) (04/26/91)
In article <573@rosie.NeXT.COM> bloschen@next.com writes: >In article <9104240831.AA01164@lhs.woodside.ca.us> dick@lhs.woodside.ca.us >(dick benster) writes: >> We would like to hook up many modems to a NeXT '040 cube, and >> [text deleted --SJB] > >I have seen products from UNINET that do this. They have several >configurations of 4/8 serial and parallel ports. They have done some clever >things things using pty's and the SCSI port to do this. The particulars are: Clever, perhaps, but not very smart. I would like a serial port controller, too, but one that comes with a *real* driver, not one that mucks things up by involving tty/pty code and its overhead, extra daemons, effective loss of available pty's, etc. I also can't see paying twice as much for it as for serial port controllers for pee cees. > > [remainder deleted --SJB] Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Spent a little time on the mountain, Spent a little time on the * * Hill, The things that went down you don't understand, But I * * think in time you will." Oakland, 19 Feb. 1991, first time * * since 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************
tempest@ecst.csuchico.edu (Kenneth K.F. Lui) (04/26/91)
Have you guys checked out the Spring 1991 Software and Peripherals catalog? I don't know how much the serial port extender from UNINET is going for, but there are two other companies that have similar products--I guess, "real soon now" (tm)--for, what I think, _outrageous_ prices. Oh well, so much for that idea... Dazzl (309) 674-9317 "Dazzl Multi-Serial and Parallel Board A board that allows the NeXTcube to control multiple UNIX(r) terminals, serial devices, or a parallel device. $2,695." Morning Star Technologies, Inc. 1 (800) 558-7827, (614) 451-1883 "Versalink(tm) A communications adapter that can be used as an asynchronous serial port expansion device or a high-speed synchronous communications link. $2,495 with Morning Star X.25. Available second quarter 1991." Ken ______________________________________________________________________________ tempest@ecst.csuchico.edu, tempest@walleye.ecst.csuchico.edu,|Kenneth K.F. Lui| tempest@sutro.sfsu.edu, tempest@wet.UUCP |________________|
rich@VAXKILLER.AGI.ORG (Richard E. Showalter) (05/01/91)
>In article <573@rosie.NeXT.COM> bloschen@next.com writes: >>In article <9104240831.AA01164@lhs.woodside.ca.us> dick@lhs.woodside.ca.us >>(dick benster) writes: >>> We would like to hook up many modems to a NeXT '040 cube, and >>> [text deleted --SJB] >> >>I have seen products from UNINET that do this. They have several >>configurations of 4/8 serial and parallel ports. They have done some clever >>things things using pty's and the SCSI port to do this. The particulars are: (Scott Bennett) writes: > Clever, perhaps, but not very smart. I would like a serial port >controller, too, but one that comes with a *real* driver, not one that >mucks things up by involving tty/pty code and its overhead, extra daemons, >effective loss of available pty's, etc. I also can't see paying twice >as much for it as for serial port controllers for pee cees. >> >> [remainder deleted --SJB] I am sorry Scott but I don't agree. As the *first* person to use a UNINET slat on a NeXT I can speak from experience. I have the 8-port model and have all 7 ports running VT100 emulation type terminals or PC's, one port running a modem and both serial ports on the NeXT used for a MacII and another modem. Price performance wise compared to a Ethernet serial port server this is a better system with faster throughput on the SCSI port compared to that of the Ethernet system. I work in a research lab where we run a lot of DNA sequence analysis programs. I have terminals all over this building running 19.2K and I have not seen any of the so called overhead problems that you talk about. I agree that ADVERTISEMENT should not be broadcast to the usenet. (sorry Neil) These responses to user needs such as Dick Benster's should be sent to the person who posted the request and if that individual finds a reasonable solution to his/her problem a summary to the group would be helpful to all and not considered ADVERTISEMENT. As I see it from here Scott Bennett does not seem to be a UNINET employee so his advice is perfectly appropriate to this list. You flamed Neil awhile back for his indiscretion and I think justifiably so, but if other individuals want to reference useful solutions to a problem don't be so quick to condemn them. Disclaimer: I do not work for UNINET I just use their products. I don't work for NeXT either but I use their products too. Rich Showalter SYS ADMIN Agouron Institute La Jolla, CA rich@vaxkiller.agi.org
neil@uninet.cpd.com (Neil Gorsuch) (05/03/91)
In article <1991Apr26.023505.32391@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >In article <573@rosie.NeXT.COM> bloschen@next.com writes: >>In article <9104240831.AA01164@lhs.woodside.ca.us> dick@lhs.woodside.ca.us >>(dick benster) writes: >>> We would like to hook up many modems to a NeXT '040 cube, and >>I have seen products from UNINET that do this. They have several >>configurations of 4/8 serial and parallel ports. They have done some clever >>things things using pty's and the SCSI port to do this. The particulars are: > Clever, perhaps, but not very smart. I would like a serial port >controller, too, but one that comes with a *real* driver, not one that >mucks things up by involving tty/pty code and its overhead, extra daemons, >effective loss of available pty's, etc. I would respectfully say that you don't know what you're talking about as far as the complete pros/cons of this method as applied to our product and market. Here's the full scoop (in my biased opinion 8-): First of all, the practicle aspects of being a supplier of peripheral addon products to workstations: To take an example, in the Sun arena, we have a lot of competitors that supply S-bus cards for serial port expansion. They all use drivers. Every customer that has compared ours and their method says ours is vastly superior. Almost all of our customers say that they are very happy not to have to rebuild the kernel when installing our stuff or when they upgrade their operating system. Every time that Sun changes operating system versions, our competitors scramble to change their driver to account for the changes, and their customers wait for a new version so that they can use the ports again. Now carry it further. Our stuff works on all the following systems, without any drivers or kernel rebuilding, and has one common source program (and Makefile) for them all: NeXT, DECstation, Sun 3, Sun 4 (sparc), Solbourne (ours is one of the few programs that are not binary compatible between Sun sparc and Solbourne), IBM 6000, MIPS, Data General Aviion. There are other systems that it works on, but they aren't unix, and the code isn't the same, and one of them even uses a (horrors 8-) driver. It would be a nightmare to supply drivers for all those systems and keep them updated with their respective operating systems. Now on to some technical aspects. pty/tty and other overhead. Read my lips, "there is far, far more resource usage (overhead) in generating/processing characters than is used in sending them through a pty/tty driver". On a sparcstation, well over 100,000 characters a second (can you say 1,000,000 baud equivalent ? ) can be pushed through the tty/pty drivers. A lot of drivers (like the drivers on the serial ports of a sparcstation) have to go through an entire interupt for every single character going in or out. The way that our stuff works, we only incur interupts on each block of characters, and the vast majority of characters traveling on a serial port come as blocks of output characters from application programs. Now for a real example of the efficiency of our methods. We have a customer that has 3 very large workstations that are normally sold as servers being used as data base front ends. Each one has 32 serial ports with terminals attached to them, using our slats. They tell us that this method is much better, performance wise, and has lower overhead, than they would get by using either ethernet serial boxes or serial cards in their machines. Mucking things up with pty/tty code. There is no cleaner way to do things than by letting the operating system handle the stuff it normally handles anyway (remember, this is unix, use things that are already there whenever possible), at least in the systems that don't use streams to differentiate between the hardware interface driver stuff and the "stty raw/echo/onlcr etc" stuff. The pty/tty drivers are the perfect thing to use to add hardware serial ports, since they handle all other interface aspects except for the final source/sink of characters. Plus, it lets us do things like provide full dial-in/dial-out access on every port, even on systems that don't normally support it, by using split ptys if required. Extra daemons. There is only 1 daemon per computer system that handles all of the slats and slat serial ports. Read my lips, "the overhead caused by slatd (our daemon) is negligable when it's idle, and a very small amount compared to the programs generating/processing characters when characters are moving through it". Loss of ptys. Are you running out of ptys? NeXT, like most systems, will probably add more ptys. We haven't had a customer complain yet about the slat losing them pty's that another application/program needed. Not having a *real* driver. Why do you need one, if our method allows for more robust code, does all the things that the customers want to do with serial ports, doesn't require a kernel rebuild on installation or operating system upgrade, and has less overhead associated with it that with a lot of serial drivers that we have seen? >I also can't see paying twice >as much for it as for serial port controllers for pee cees. You are paying HALF as much as comparable units. PC cards are cards only, the SLAT is in an external case, involves cabling, power supply, etc, all of which adds considerably to the cost. If you want to compare apples to apples (is that a fond word for members of this group 8-) ? ), compare our price to an ethernet serial box. The last time I looked, most of them were in the $2,000 to $3,000 range. PC cards are also much higher volume, and have lower manufacturing costs associated with the higher volumes. We don't compete with cards that go in a card cage. If you have a card cage, and can add a serial card, I would be the first to urge you to use that instead of our slat, the cards will probably be cheaper. If you don't have a card cage, our method is probably cheaper, and certainly has some important technical advantages (in my biased opinion 8-), over ethernet serial boxes. -- Neil Gorsuch INTERNET: neil@cpd.com UUCP: uunet!zardoz!neil MAIL: 1209 E. Warner, Santa Ana, CA, USA, 92705 PHONE: +1 714 546 1100 Uninet, a division of Custom Product Design, Inc. FAX: +1 714 546 3726 AKA: root, security-request, uuasc-request, postmaster, usenet, news
neil@uninet.cpd.com (Neil Gorsuch) (05/03/91)
In article <1991Apr26.060343.17397@ecst.csuchico.edu> tempest@ecst.csuchico.edu (Kenneth K.F. Lui) writes: >Peripherals catalog? I don't know how much the serial port >extender from UNINET is going for, but there are two other >companies that have similar products--I guess, "real soon now" >(tm)--for, what I think, _outrageous_ prices. Oh well, so much >for that idea... >"Dazzl Multi-Serial and Parallel Board > parallel device. $2,695." >"Versalink(tm) > link. $2,495 with Morning Star X.25. If those are ethernet solutions, the prices are not untypical, although the ethernet prices are starting to drop. Our (UNINET) prices, including SCSI cable and host software, range from $780 to $1780, depending on how many serial ports you get. Our stuff is available now on the NeXT. -- Neil Gorsuch INTERNET: neil@cpd.com UUCP: uunet!zardoz!neil MAIL: 1209 E. Warner, Santa Ana, CA, USA, 92705 PHONE: +1 714 546 1100 Uninet, a division of Custom Product Design, Inc. FAX: +1 714 546 3726 AKA: root, security-request, uuasc-request, postmaster, usenet, news
waltrip@capd.jhuapl.edu (05/04/91)
In article <1991May2.214100.13070@zardoz.cpd.com>, neil@uninet.cpd.com (Neil Gorsuch) writes: [...material deleted...] > The way that our stuff works, we only incur interupts on each > block of characters, and the vast majority of characters traveling on > a serial port come as blocks of output characters from application > programs. I'd be interested in more details on how this works. This sounds a bit like you can't do raw (character at a time) I/O...but I doubt that's true. Comment? [...material deleted...] > ...compare our price to an ethernet serial box. The last > time I looked, most of them were in the $2,000 to $3,000 range. I believe they may be available in the $1,500 range these days. BTW, I believe the overhead issue is of some significance with regard to Ethernet terminal servers...both in terms of Ethernet traffic and use of ptys. TCP/IP based terminal servers tend to introduce a somewhat disproportionate Ethernet load...and don't they generally just make a telnet connection to the host, using a pty (and a socket?) in the process? c.f.waltrip Internet: <waltrip@capsrv.jhuapl.edu> Opinions expressed are my own.