Here's a summay of a question I posed regarding async boards for
SPARCstations. The original question and edited answers are
included below. Sorry this is so big.
Most people "voted" for Central Data's SCSI terminal server, followed
closely by GNP's DEI. Both products are fairly expandable.
Performance appears OK. I personally have no need for serial port
expansion beyond 16 lines though. I remember seeing GNP's product a
not long after the SPARCstation 1(+?) was introduced. I think Central
Data has been out there for some time, as well as (I think) Aurora's
and/or Artecon's product.
One person (thanks Kurt!) did a side-by-side comparison of the Magma
product with Central Data and found that the Magma board consistently
outperformed Central Data's. I'm sensitive to contention for SCSI
bandwidth that the Central Data product might incur. Another person in
the process of evaluating the Magma board, didn't respond by the time
this was submitted.
The GNP DEI uses a Motorola 68000 to control the board. I took
that to mean a vanilla 68000 and not one of the special versions having
integrated I/O lines, RAM, ROM, etc. I imagine the design is
"traditional" in that the CPU has to poll devices or service
interrupts; there is a limit to how much of this can be done (number of
ports and max speed) with this kind of arrangement. More importantly,
no mention is made of the ACIA in use, indicating the kind of buffering
available (double?), presence of integrated flow control, etc. The
DEI has a parallel port for each group of 8 serial ports.
Newer products, on the other hand, might use something like the Cirrus
Logic CD-1400 asynchronous communications chip, a "RISC" processor that
contains it's own integrated FIFO and hardware flow control at each
port. It apparently only needs some line drivers/latches/buffers,
SBUS chip set and perhaps some configuration in between.
There are other issues not addressed here, such as: does that device
have PROMs or (boot-time) downloadable driver code, product support in
terms of H/W and S/W configuration, warranty and replacement service, etc.
I received a couple phone calls from vendors suggesting that I do an
evaluation of their products. Unfortunately, I'm not in the position
to do this kind of evaluation right now. We are replacing a tired
Sun-3 with a SPARCstation 10/30, involving trade-in upgrades with
deadlines, conversion of a database management system, a change in
operating system (probably to Solaris 2.x--can you say culture shock?),
and all the assorted administrivia involved. Guess who'll do it all?
Dialog with some vendors would usually go like:
"I want to have performance better than 38.4k."
"We have a new product that will support 128k throughput
on all 16 lines with full bidirectional hardware flow
and modem control."
"Is it available?"
"No, but it should be out by the end of next month."
"Do you have drivers for Solaris 2.1?"
"No, but we will have a beta version by the end of next week."
I guess my timing is too early to take advantage of the extraordinary
amount of reengineering going on out there. :-\ Next month probably
means next quarter or next year; next week probably means next month.
:-( One vendor that responded to my question then posted a question to
sun-managers about a week later on how to use the parallel port under
Solaris 2.x; is this the person developing drivers?
There also seems to be a good bit of animosity between some vendors:
"We designed and manufacture their async board."
"No. We broke off that bad relationship a long time ago.
We did our new board ourselves."
I've ruled out Ethernet terminal servers for both price and added
network bandwith (I've heard horror stories of students on campus
swamping the net with telnet sessions). I don't need the flexibility
of multi-host capability. In addition, my experiences with setting
up modems, printers, etc. on an Ethernet terminal server has been less
than satisfying--a kludge of daemons and funny wiring schemes.
Taking into account the above, perceived load balance and a little
gestalt, I chose a product that was the second least expensive (the
least expensive if you don't deduct "university discounts"). Once the
machine shows up I'll see if I can live with that choice. If any
sun-managers want to know what I bought, e-mail me personally.
Thanks to managers:
David Trueman <david@cs.dal.ca>
John DiMarco <jdd@db.toronto.edu>
Mister Damage <julian@syd.dwt.CSIRO.AU> aka Julian Dryden
Perry_Hutchison.Portland@xerox.com
Steve Linebarger <srl@metronet.com>
bill@jts.com (Bill McSephney )
ekurgpol@develop-law.usc.edu (Elmar Kurgpold)
lidl@uunet.uu.net (Kurt J. Lidl)
megatek!randy@uunet.UU.NET (Randy Davis)
msd@sharpwa.com (Mark Deason)
stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
trdlnk!mike@uunet.UU.NET (Michael Sullivan)
ups!kevin@fourx.Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
and to vendors:
eclipse!chungj@uu2.psi.com (Jae Chung)
ed@magma.COM (Ed Romascan)
valencia@auratek.com (Stephen T. Valencia)
Tom Poage
Clinical Engineering
University of California, Davis, Medical Center
tfpoage@ucdavis.edu
======================================================================
Original message:
>Hi, managers:
>
>Can anybody offer their experience, horror stories, or evaluations for
>async (RS-232) boards for a SPARC? Heck, I'd be happy to go get it
>myself. :-)
>
>The target is a SPARCStation 10/30 in which I hope to obtain a balance
>between I/O and CPU. Our primary applications are database-oriented
>and typically disk-intensive. About as many logins come in as telnet
>sessions as do over serial lines. There is a small amount of NFS.
>
>I need 16 ports on a limited budget. My first guess is to use an S-Bus
>serial board in order to distribute I/O load over S-Bus, Ethernet and
>SCSI.
>
>I've looked some Ethernet terminal servers, some S-Bus boards and a
>SCSI bus terminal board, all 16 port. I'd like to have better hardware
>flow control for modems than has existed on Suns in the past (e.g.,
>tty[ab]). I'd also like to crank up the I/O speed for fast modems and
>minimize CPU overhead.
>
>So far I'm considering the following:
>
> Artecon (1600-SB)
> Aurora (1600S)
> Central Data SCSI (ST-1016)
> Magma (16 Sp)
>
>I've browsed comp.sys.sun.* with no luck so far.
>
>Thanks! I'll summarize.
>--
>Tom Poage
>Clinical Engineering
>University of California, Davis, Medical Center
>tfpoage@ucdavis.edu (916) 734-5221
======================================================================
From: stern@sunne.East.Sun.COM (Hal Stern - NE Area Systems Engineer)
check out the GNP DEI-16, and the novadyne novaport (?)
novadyne is really aimed at *lots* of terminals, i think,
but the GNP box is pretty cool.
not at all sure on cost; i've just played with both a little
bit and found them OK
--hal
======================================================================
From: David Trueman <david@cs.dal.ca>
We have been using the Central Data SCSI Terminal Server (2000 series)
for a few months. We haven't pushed it very hard, but it has been
quite well behaved.
======================================================================
From: Mister Damage <julian@syd.dwt.CSIRO.AU>
I have used Artecon stuff. At the moment we have a 1 Parallel 8 serial.
It is very good. Driver is a loadable kernel module.
As for just how much better you want flow control .....
I am not too demanding with ours. We have a few 2400bd modems and a
parallel printer attached.
Julian Dryden
CSIRO DWT
Sydney Australia
======================================================================
From: bill@jts.com (Bill McSephney )
Hi Tom
We have just installed the "Central Data SCSI (ST-1016)" unit. On it
we have 7 modems (1x57600baud, 2x19200baud, 3x2400baud, and
1x1200baud), 4 printers (1x38400baud, 2x19200baud, and 1x9600baud), a
SMDR port at 4800baud witch receives data all day, the printer and
modems are all used moderate to heavy. We have seen very little load
added to our SS2 which has mail/news coming in and out over these
modems.
All in all I am impressed with the Central Data product.
Bill Mc.
____ ___ |William G. McSephney Tech Support Analyst/System Admin
/ / / ` |JTS Computer Systems LTD Home of OpenImage
/ / `--. |4211 Yonge St., Suite 620, Willowdale, Ontario. M2P 2A9
|__/ / ,___/ |E-mail: bill@jts.com Ph:(416)512-8910 Fax:(416)512-6519
======================================================================
From: valencia@auratek.com (Stephen T. Valencia)
I wanted to touch base with you on your latest email about 16 port SBus boards.
I understand that you had some problems with the Sun serial ports. I can assureyou that you are not alone there. We have heard that a number of people were
not satisfied with the Sun serial ports. One reason is that they don't have
true harware flow control. The softeware driver decides when RTS and CTS shouldbe high.
As you may or may not know, Aurora Technologies pioneered the SBus market place
and currently is the largest third party supllier of SBus cards in the world.
Aurora was the first company to provide Parallel ports, SBus expansion
chassis, and even the 16 port card. Since the introduction of these products,
Aurora has made a constant effort to streamline the driver and enhance the
products to be on the cutting edge of technology.
You had mentioned possibly running at some high speeds. I wanted to let
you know about our high speed Asynchronous cards. Aurora has a 4 and 8 port
SBus cards that support speeds up to 128k baud. As with our other cards,
the 400SX and 800SX use the 10 MIPS RISC processors and I/O bufffering that
allow increased system performance.
The Aurora product line is guaranteed with a 30 day money back satisfaction
policy. All of our products come standard with a one year swap warranty.
This means that if the product should fail while under waranty, we Fed-X a
new board over night. Our products are also backed with lifetime phone support.
I didn't mean to make this letter so long. If you have any questions, please
contact me.
thanks
steve valencia
account manager
*******************************************************************************
Steve Valencia Valencia@auratek.com
Aurora Technologies, Inc. uunet!auratek!steve
176 Second Ave
Waltham, MA 02154
(617)290-4800 tel Intelligent Products for SPARC Workstations
(617)290-4844 fax
<copious amounts of product data deleted>
======================================================================
From: ekurgpol@develop-law.usc.edu (Elmar Kurgpold)
While I have not actually used any of these yet, I am evaluating the
information regarding the products you mentioned. In your case, with a limited
budget and lots of intensive SCSI action, I'd lean toward one of the SBus
deals. They may put a bit of an extra load on the CPU, but they are cheaper.
Consider the load on the ports-- are you running postscript printers off of
them, for example. And the speed of your CPU-- I'd kill to have that kind of
MIPS.
--------------------------------
| Elmar Kurgpold |
| Network Administrator |
| USC Law Center |
| ekurgpol@develop-law.usc.edu |
| (213)740-5709 |
| (213)740-5502 FAX |
--------------------------------
======================================================================
From: eclipse!chungj@uu2.psi.com (Jae Chung)
Hi Tom,
Hmmm, I'm wondering why you do not have our name in your list...
For long stroy make it short, GNP DEI serial expander fits in
your requirement. Here are some specs for you...
1. With Maximum load of IO thru all serial ports, it only uses
less than 1 % of CPU load.
2. Under SunOS 4.1.X, it supports up to 96 ports..(32 ports per each S-Bus)
Under SunOS 5.x (aka. Solaris 2.X), it supports up to no limit. it is
only limited by the number of Sbus slots you have.
3. Each chassis, it starts from 8 ports configuration to 32 ports.
4. Unlike other boards, every single serial ports supports modem line.
5. There is a bonus paraller port per 8 serial ports.
6. Since we manufactured this over last 3 years, it is robust as it can
be.
If you are interested in, I can refer you to one of our sales rep for you..
/******************************************************************************/
/* Jae Y. Chung E-Mail : chungj@gnp.com */
/* Manager, Systems Engineering Phone : 818 577 4262 */
/* GNP Computers Fax : 818 577 4263 */
/* 1254 E. Colorado Blvd. Pasadena. Ca. 91106 */
/******************************************************************************/
======================================================================
From: Perry_Hutchison.Portland@xerox.com
No direct experience here with async boards, but we have an Aurora
parallel-port board in an SS2 and it has worked flawlessly with SunOS
4.1.2 . (It came with a loadable driver, so no kernel build was needed.)
We chose Aurora (even though it was more expensive than CoSystems or
Antares -- Artecon was out due to not having a parallel-only board
available) due to its 8Kb on-board FIFO which should reduce system
overhead when printing large files.
One thing to consider with any third-party board is whether its drivers
will port to new OS releases -- for example, I presume that the jump
from SunOS 4.1.x to Solaris 2.x will require driver modifications
although this is not (yet) an issue here -- and if not will the vendor
be around to provide a revised driver.
If you are buying a lot of these, you might want to inquire about
availability of driver source code, at least via an escrow arrangement
whereby you can get the source if the supplier goes out of business or
fails to support new OS releases in a timely manner.
======================================================================
From: ups!kevin@fourx.Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
I've always been happy with the DEI boards from GNP. Aurora boards
have been fine too.
l & h,
kev
======================================================================
From: John DiMarco <jdd@db.toronto.edu>
In list.sun-managers you write:
>Can anybody offer their experience, horror stories, or evaluations for
>async (RS-232) boards for a SPARC? Heck, I'd be happy to go get it
>myself. :-)
I asked for information on the Central Data product on comp.sys.sun.admin
a month ago; I'm enclosing the summary I made.
Regards,
John
-- John DiMarco jdd@cdf.toronto.edu Computing Disciplines Facility Systems Manager jdd@cdf.utoronto.ca University of Toronto EA201B,(416)978-1928--- cut here ---- Subject: scsiTerminal server summary, as promised.
As promised, here is a summary of the responses I received to my request for information and experiences with the Central Data scsiTerminal server (STS).
I only received a few responses, but they were generally quite positive. People seemed quite pleased with its throughput, and the fact that it provides full hardware flow control in both directions.
Those that mentioned it seemed happy with Central Data's support.
One persion mentioned that Central Data's drivers did not support Solbourne or Sun 4/490 (VME) SCSI interfaces.
Surprisingly, nobody provided any data about how the STS coexists with disks and other SCSI devices on the SCSI bus. This isn't an issue with us (we happen to have an unused SCSI interface on the machine we're planning to add it to), but might be an issue for others.
We're probably going to go ahead and order one.
Many thanks to:
tbr@tfic.bc.ca (Tom Rushworth ) MARKD@nova.cd.com Pete Hartman <pwh@bradley.bradley.edu> cro@socrates.ed.asu.edu (C. R. Oldham) mandrews@hq.videocart.com (Mike Andrews)
Regards,
John -- John DiMarco jdd@cdf.toronto.edu Computing Disciplines Facility Systems Manager jdd@cdf.utoronto.ca University of Toronto EA201B,(416)978-1928
------------- ORIGINAL post:
>Does anyone have any experiences with or opinions about Central Data's >"scsiTerminal Server", esp. connected to a sun? If so, I'd be interested in >hearing them. For instance, how does it behave under load? What is its >impact on the host? The scsi bus? > >Please respond via e-mail; I'll post a summary to this newsgroup. > >For the unfamiliar, the "scsiTerminal Server" is a device which allows >one to add serial (and sometimes parallel) ports to a machine via the scsi >interface. > >Thanks, > >John
<Central Data product information deleted>
---------------------
From: tbr@tfic.bc.ca (Tom Rushworth )
We just got one. We've had it installed for about 3 days, so there isn't a lot of history, but I can at least compare it to the Sun Sbus (SPC) card. (Central Data's server is called the STS.)
Configuration: SS2 clone running SunOS 4.1.2 scsiTerminal Server 1008+, drivers linked into kernel, not dynamic with: - 2 Telebit modems at 19.2k - 1 ZyXEL modem at 19.2K - 1 postscript printer at 19.2K - 1 high-speed pen plotter at 19.2K - 1 Xerox laser printer on the parallel port - terminals at 9600 on remaining ports
Performance: Interrupts/Sec for 1 uucp transfer (from perfmeter, very rough) 300-400 (vs 3,000! for the SPC) Bytes/Sec for uucp transfer (from log files) (tty[yz]* is Sun's SPC, tty[cC]* is Central Data's) `[ttyz01]->' bytes=2543403 secs=2650.372000 `[ttyy01]->' bytes=57393 secs=68.518000 `[ttyz00]->' bytes=596640 secs=396.485000 `[ttyy00]->' bytes=203100 secs=132.881000 3400536 / 3247 = 1047 bps outgoing ------ `[ttyz00]<-' bytes=6032773 secs=5115.424000 `[ttyy00]<-' bytes=7383749 secs=6491.499000 `[ttyy01]<-' bytes=60873 secs=81.625000 13477395 / 11688 = 1153 bps incoming --------- `[ttyc1]->' bytes=22608 secs=13.265000 `[ttyC1]->' bytes=289800 secs=184.847000 312408 / 198 = 1578 bps outgoing --------- `[ttyC1]<-' bytes=655700 secs=541.846000 `[ttyc1]<-' bytes=4532524 secs=3561.649000 5188224 / 4104 = 1264 bps incoming I haven't had it running long enough to get data on running 2 modems at once, the one time I saw it happening all I noticed was that I/s for 2 was less than twice I/s for 1. The load the STS presents for 1 uucp transfer seems to be (very roughly) 1/10th the load the Sun SPC board presents.
The installation guide that came with it has a small table of approximate performance numbers (they are careful to say your milage may vary :)) -
8 lines, 9600 baud, full duplex 1904 c/s/l 8 lines, 19.2K, primarily unidirectional 1905 c/s/l (either direction) 8 lines, 38.4K, output only 3264 c/s/l 8 lines, 38.4K, input only 3763 c/s/l 4 in, 4 out, 38.4K 3763 (in) 1536 (out)
An unexpected bonus we got is that it handles a paper-out condition on the parallel port in a graceful way (it just pauses (with NO message) until you fill the printer). The Sun SPC card gets a ppc_acktimeout, so lpd aborts and reprints the job (which makes it fun trying to print a job bigger than the printers paper supply).
One final plus - the RTS/CTS flow control really works, *both* ways, which makes using the modems ever so much more pleasant...
---------------- From: Pete Hartman <pwh@bradley.bradley.edu>
Well, I have a mixed tale.
I have had a good response from their support people when I've had problems and the time to figure them out. I spent a long time not realizing I had misconfigured ours (we have two connected to a SS-2, which are used for incoming lines from an AT&T serial network called ISN), and trying to get them to help me when I didn't even understand what I was doing quite right. They tried hard. But it took me understanding what I should be doing (the lines had to be configured as if they were modems, so that they would pay attention to Carrier Detect) before I solved some basic problems.
Since then (only a few months) I find that they intermittently stop working. Getty's run on these ports, there don't appear to be processes hung on the ports, but they don't answer. I don't understand the problem and haven't taken the time to chase it down (we have alternate means of connecting to that machine, and I'm responsible for 30-odd more suns, some with users who are a lot more strident about what needs to be done for them). I assume that when I do, I can get good help, but until then, they still don't work quite right.
----------------- From: cro@socrates.ed.asu.edu (C. R. Oldham)
I was going to buy one--as it was quite cost-competitive with Sun's ALM-2 board, but Central Data informed me that the scsiTerminal server would not function with my SPARCserver 4/470. Something about incompatibilities in Sun's SCSI interface for this machine.
----------------- From: mcb@mach.eng.hou.compaq.com (Mike Busby)
We have been evaluating using the Central Data Terminal server for SLIP/PPP use internally on Sun/Solbourne. The limited tests I ran indicated that it could handle the load at 56 kbaud using Telebit Worldblazer modems. It also handled hardware flow-control correctly. We tried both modems and hard-wired connections. The model we tested was the ST-1016.
One minus was that they will not support Solbourne until they conform to SCD 1.1 and SCSD (Sun common SCSI definition) compliance. I don't believe that this will happen until Solbourne goes to Solaris 2.X.
----------------- From: mandrews@hq.videocart.com (Mike Andrews)
We have the SP-1003 parallel version. Does it work? We just got a second one!
The only problem we've had is with it not initializing at boot time. Watch carefully to see that it is creating the ports in /dev when the device is initialized. (We actually only had that problem once, but since we have it on our main server, it was pain to have to reboot it.)
I have called Central Data for support and had no complaints.
We drive several network printers via parallel extenders. The high speed port works at about 215000 bps, not as fast as a Ethernet printer server but still great and much less costly.
The device dirver is easy to install and very intelligent. It will find all of the Central Data Servers on *any* SCSI bus at boot time and configue /dev devices in sequence to use the ports.
----------------- ======================================================================
From: ed@magma.COM (Ed Romascan)
Tom,
Mesa Ridge Technologies manufactures both the Aurora 1600S and the MAGMA 16 Sp. Aurora sells the 1600S and we (Mesa Ridge) sell the MAGMA 16 Sp. We are also very familiar with the Artecon board as it uses the same Cirrus Logic chips as the MAGMA 16 Sp.
The boards are very different:
The MAGMA board has full modem control on all 16 ports. The signals supported are RX, TX, CD, DTR, DSR, RTS, and CTS. All of these signals are needed to operate high speed modems. RTS and CTS are used for hardware flow control.
The Aurora board has RX, TX, RTS, CTS, CD, and DTR on 8 channels and only RX, TX, RTS, and CTS on the remaining 8. Only 8 modems can be attached to this board.
The Artecon board has RX, TX, DTR, CD and RI on 8 ports and RX, TX, DTR and CD on the other 8 ports. It does not support RTS/CTS hardware flow control and cannot operate high speed modems such as Telebit T3000s at 38400bps reliably. (RI, Ring Indicator is never used in real life)
The MAGMA RTS/CTS hardware flow control is controlled by the Cirrus Logic chip. If your modem supports RTS/CTS flow control, you CANNOT loose characters with the MAGMA board.
The Aurora board implements SunOS hardware flow control from the SPARC CPU. It is possible to loose characters at high speed.
The MAGMA board supports speeds up to 115,200bps when using flow control. Both the Artecon and Aurora board only handle speeds to 38,400bps. I don't know much about the Central Data SCSI attached ports, but, as you are a disk intensive site, putting async ports on the same SCSI bus as your disk drives will slow the drive access down significantly. It might work if you had a separate SCSI bus for the async ports.
All of these solutions will use lots of CPU when all 16 ports are operating simultaneously. We are bringing out a new board designed for high speed modems that will use minimal CPU resources. It will be a DMA board called the MAGMA 16 DMA Sp. It should be available in the April timeframe. We will have the MAGMA 4 DMA, a 4 port DMA board, available in February.
Regards,
Ed Romascan
======================================================================
From: lidl@uunet.uu.net (Kurt J. Lidl)
The Magma are the ones we have choosen. They are superior to Central Data boxes in terms of throughput. The boards that Sun sells are not too good.
I don't know about the Artecon and Aurora boards.
-Kurt
From: lidl@uunet.uu.net (Kurt J. Lidl)
>From: tfpoage@ucdavis.edu (Tom Poage) >Date: Thu, 14 Jan 93 08:33:51 PST >To: lidl@uunet.UU.NET >Subject: Re: 16 Port Async Boards for SPARC > >How did you determine that Magma outperforms Central Data?
Well, we log file length sent, and time. From this, we get CPS for each serial line. On the same SS2 server, running with approximately the same load, we get consistantly higher average CPS ratings for the Magma board. (We use the 16 port version.)
>(I know that Magma's max is 115k bps while Central Data's is 38.4k bps; >pretty obvious unless there's something else like system loading.)
As we cut over from our T2500's (max DTE of 19200) to WorldBlazers (max DTE of 115000), I'm sure that the performance will go up even more.
-Kurt
======================================================================
From: trdlnk!mike@uunet.UU.NET (Michael Sullivan)
I recently installed a MAGMA 4sp in a SPARCstation 1, and it is working fine. So far I am only using 2 of the ports (at 19200 bps each), but it puts noticeably less load on the system, particularly in terms of interrupts, than the built-in ports.
The shell script to install the driver failed because it used a idiotic way to try to automatically determine which version of SunOS the machine was running ("egrep SunOS /vmunix|tail -1") and got confused by the presence of some kernel patches, but it was trivial to do the installation manually.
======================================================================
From: Steve Linebarger <srl@metronet.com>
We've been using the Central data scsi attached serial ports for 2 months now with wonderful results. We're using the St-1000. However, our good experience is not directly relatable to your potential experience because we've been using them on an HP700.
Good luck.
-- Steve Linebarger Texas Metronet, Internet for the Individual. srl@feenix.metronet.com, 73157.1323@compuserve.com, GEnie:S.LINEBARG data:9600+:214 705 2901, 2400:214 705 2917; login as info/info or signup/signup fax: 214 401 2802 ( 8am-5pm CST weekdays ) Need Internet access ( or better Internet access ) ? Try us! Reasonable monthly rates, no hourly charges.
======================================================================
From: megatek!randy@uunet.UU.NET (Randy Davis)
In article <1993Jan12.142323.24257@megatek.com> you write: |Can anybody offer their experience, horror stories, or evaluations for |async (RS-232) boards for a SPARC? Heck, I'd be happy to go get it |myself. :-)
You DEFINITELY need to check with "CoSystems" about their "CoALM".
We have one of their VME boards on a Sun3, and it can and does handle 38400 baud - our InterNet SLIP connection is run through it. We have four uucp modems hanging off it running 9600 baud (full blast on all ports simultaneously pretty often) - I don't remember the full specs on their boards at the moment, but what I do remember was that:
1) it is cheaper than the Sun ALM board, by quite a bit. 2) it is rated for at least twice the power of the Sun ALM (baud rates and occupancy rates). 3) it installed without a hitch of any type. 4) it has been running without any type of problem on our gateway system for over a year now.
The info I have on-line for CoSystems says:
CoSystems, Inc. 2250 Scott Blvd, Bldg. 61-01 Santa Clara, CA 95054 Tel: (408)748-2190 Fax: (408)988-0785
I beleive I spoke to a gentleman by the name of Steve Martinez, there, who was VP of sales and marketing (small company, I guess).
Randy Davis Email: randy@megatek.com Corporate Network and System Administrator megatek!randy@uunet.uu.net Megatek Corporation, San Diego, California ucsd!megatek.uucp!randy
======================================================================
From: msd@sharpwa.com (Mark Deason)
We use the Datability Terminal server (VCP-1000). When we purchased it about 18 months ago, it had the best modem control features of any of the terminal servers, including some of the ones you mentioned. Modem control is best when using the DB25 interface. Our search was limited to servers which support both LAT and Telnet protocols.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:26 CDT