sda@atexrd.UUCP (Stephen Ayers) (10/06/87)
I would like to add an additional 4 ports to my
SCO XENIX system(a compaq 386). I'm looking for
something with DMA access and as little overhead
as possible at 9600 baud. They would be used for
terminals and uucp to another local system. Could
anyone out there relay their experences with
such boards? I have been refered to a board from
AST called the xn(?). Has anyone got this up and
running? To further complicate things I have an
internal Hayes modem that would need to work with
the new ports. Also if possible use of the standard
com port that comes with the system would be nice.
Thanks!
--
Steve Ayers, Atex, Inc., A Kodak Company
{ll-xn,genrad,munsell}!atexrd!sda
+1 617 276-7384fyl@ssc.UUCP (Phil Hughes) (10/15/87)
In article <94@sda.atexrd.UUCP>, sda@atexrd.UUCP (Stephen Ayers) writes: > I would like to add an additional 4 ports to my > SCO XENIX system(a compaq 386). I'm looking for > something with DMA access and as little overhead > as possible at 9600 baud. Arnet SmartPort is my quick suggestion. We have one and the only problems we have can be traced to the clone disease. They have great support and an 'if it dies we replace it' guarantee. We have had one of their dumb boards for about 2 years with no problems. There are others out there but this is the only one I can give you first hand info on. -- Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155 (206)FOR-UNIX or 527-3385 ...!uw-beaver!tikal!ssc!fyl
cmi@dartvax.UUCP (Theo Pozzy/R. Green) (10/20/87)
In article <787@ssc.UUCP> fyl@ssc.UUCP (Phil Hughes) writes: >In article <94@sda.atexrd.UUCP>, sda@atexrd.UUCP (Stephen Ayers) writes: >> I would like to add an additional 4 ports to my >> SCO XENIX system(a compaq 386). I'm looking for >> something with DMA access and as little overhead >> as possible at 9600 baud. > >Arnet SmartPort is my quick suggestion. Although I'm not sure about 4-port boards, we've had quite a bit of experience with two of the 8-port boards, Digiboard and Hostess. The Smart Hostess 8-port board is by far the best I've seen. It has DMA, on board CPU and RAM, and has the best device driver. We've pounded on it by using our software, MLINK, to do 9600 baud file transfers with one port looped back into another, with two loops running at once! And the degradation seen by the rest of the system is a fraction of what the Digiboard causes. The Digiboard also has a tendency to hang in the device driver, leaving you SOL until you reboot. Not cool. Theo Pozzy, Corporate Microsystems, Inc. ...!decvax!dartvax!cmi (UUCP) cmi@dartmouth (CSNET) cmi@dartmouth.edu (ARPA) Box A-58, Hanover, NH, 03755 (USPS) CompuServe (76267,413) (603) 448-5193 (BellNet) -- Theo Pozzy, Corporate Microsystems, Inc. ...!decvax!dartvax!cmi (UUCP) cmi@dartmouth (CSNET) cmi@dartmouth.edu (ARPA) Box A-58, Hanover, NH, 03755 (USPS) CompuServe (76267,413) (603) 448-5193 (BellNet)
caf@omen.UUCP (10/23/87)
In article <7433@dartvax.UUCP> cmi@dartvax.UUCP (Theo Pozzy/R. Green) writes:
:We've pounded on it by using our software, MLINK, to do 9600 baud
:file transfers with one port looped back into another, with two
:loops running at once!
A loopback test such as this is not necessarily a good prediction of real
world performance because the loopback configuration tends to regulate
the flow of data. The result is an implicit, unexpected flow control.
A project I was involved with some years ago folded because the company
accepted a vendor's loopback test as a valid predictor of the system's
ability to accomodate incoming data, instead of allowing me to test the
system myself before committing to it. Needless to say, the system could
not handle anywhere near the required input throughput when connected to
other computers.davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (10/27/87)
In article <608@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: |In article <7433@dartvax.UUCP> cmi@dartvax.UUCP (Theo Pozzy/R. Green) writes: |:We've pounded on it by using our software, MLINK, to do 9600 baud |:file transfers with one port looped back into another, with two |:loops running at once! | |A loopback test such as this is not necessarily a good prediction of real |world performance because the loopback configuration tends to regulate |the flow of data. The result is an implicit, unexpected flow control. This is true. However, when running the loopback test, if the actual throughput is about right for a 9600 baud connection the system will handle one line at 9600, and unless the port controller buffers output but not input (I guess you could do it that way), it will handle two. A reasonable estimation of throughput is the time the ports with a null modem and connect out on one and login on the other. You can then 'cat' a file and time it by hand. I like to use a file which takes at least 30 sec to transfer at the maximum line rate. I ususally test the throughput with both kermit and zmodem file transfers. Kermit will usually get about 45-55% of max, zmodem about 90-93%. Look for a large number of retries, particularly on kermit. Running a loopback test without timing is not usually meaningful except to test the ability of the system to transfer *something* without aborting with a system fault such as "double panic." -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
caf@omen.UUCP (Chuck Forsberg WA7KGX) (10/29/87)
In article <7702@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: :In article <608@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: :|In article <7433@dartvax.UUCP> cmi@dartvax.UUCP (Theo Pozzy/R. Green) writes: :|:We've pounded on it by using our software, MLINK, to do 9600 baud :|:file transfers with one port looped back into another, with two :|:loops running at once! :| :|A loopback test such as this is not necessarily a good prediction of real :|world performance because the loopback configuration tends to regulate :|the flow of data. The result is an implicit, unexpected flow control. : :This is true. However, when running the loopback test, if the actual :throughput is about right for a 9600 baud connection the system will :handle one line at 9600, and unless the port controller buffers output :but not input (I guess you could do it that way), it will handle two. Close, but no cigar. For openers, many serial IO controllers do buffer or DMA output but not input. When neither input not output are deeply buffered at the hardware level (i.e., 8250, etc.) events (task switch, critical code, etc.) that increase interrupt latency will not cause loss of data in a loopback situation, but will cause loss of data in real world situations. Why? Because the interrupt latency inserts a short pause in transmission that prevents the receiver from dropping characters beyond the one or two that the UART can buffer. A more realistic simulation is possible if high speed buffered modems were inserted into the loops. They would decouple the pauses of data from the interrupt latencies, resulting in conditions representative of actual applications. Chuck Forsberg WA7KGX Author of Pro-YAM communications Tools for PCDOS and Unix ...!tektronix!reed!omen!caf Omen Technology Inc "The High Reliability Software" 17505-V Northwest Sauvie Island Road Portland OR 97231 VOICE:503-621-3406:VOICE TeleGodzilla BBS: 621-3746 19200/2400/1200 CIS:70007,2304 Genie:CAF omen Any ACU 2400 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourly