Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!mit-eddie!uw-beaver!fluke!jeff
From: jeff@tc.fluke.COM (Jeff Stearns)
Newsgroups: comp.dcom.modems
Subject: Re: more Disappointing throughput
Keywords: UUCP SunOS 4.0, Sun 2/170, Telebit T1000
Message-ID: <1990Mar5.224531.8718@tc.fluke.COM>
Date: 5 Mar 90 22:45:31 GMT
References: <5126@quack.UUCP>
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 50

In article <5126@quack.UUCP> mrapple@quack.UUCP (Nick Sayer) writes:
: Since my last post about hooking the TB up to the MTI-800/1600,
: I've made the discovery that that multiplexer can't keep up 
: with 9600 baud without crashing the system constantly, so
: I've decided to leave the TB on ttyb for now. Since doing so,
: I've noticed that the throughput for uucp receive is lousy.

Nick, we've been running similar hardware for several years.  It's been very
reliable.  Here's the setup:
    - Sun-2/120 running SunOS 3.5.2, 4Mb of RAM.
    - Systech MTI-1600A with two Trailblazer Plus's (at ROM revs which
      have varied from 3.00 to 5.00).
    - The modems are locked to 19200 baud, using CTS for flow control.

This system has moved all of our netnews and email for years.  We move
several megabytes per day.  We *NEVER* have MTI overruns or system crashes.

This system can't process incoming data faster than about 800 CPS because
the kernel chews up all of the CPU processing receive interrupts from the
Systech board.  (It can easily drive two modems at full speed when sending.)

We run Berkeley's uucico because I have the source and prefer to make a few
modifications.  There is one that may interest you.  It's merely an efficiency
hack, and actually places more stress upon the input buffering mechanism.
My uucico takes variable-length naps between character reads, to avoid
placing a read() system call until it can predict that the required number
of characters have arrived.  (Recall that uucico runs raw, and if you aren't
careful, you'll do billions of itty bitty reads.  Those system calls will
really chew up the CPU.)  Berkeley's code does something similar, but mine
performed better in practice.  I still don't suffer overruns.

Unless something is stealing the bus from you, the Systech ought to be able
to squirrel away an entire window's worth of g-protocol packets.  This may
consume so much of the CPU that uucico can't process them very quickly,
but you'll reach a steady state since the sender won't send more until you
start acking them.  (This is true whether spoofing is on or off; the modem
follows the rules.)

If I were you, I'd triple-check everything to make sure that flow control
and modems and cables are really set up the way you expect.  And I wouldn't
put up with hardware that crashes.  Something is misconfigured or broken.

Just last weekend I upgraded to a Sun-3/180 running SunOS 4.0.3, also with an
MTI-1600A and TrailBlazers.  I tested uucp between the old and new machines
for several weeks before the cutover, and I never had a crash nor an overrun.
(The new machine has more horsepower for processing incoming data; it can
process incoming data at the full 1400 CPS and still do other work as well.)
-- 
    Jeff Stearns        John Fluke Mfg. Co, Inc.               (206) 356-5064
    jeff@tc.fluke.COM   {uw-beaver,microsoft,sun}!fluke!jeff