Equinox question

[Karl Denninger]

In article <1991Feb20.202915.21242 at eci386.uucp> woods at eci386.UUCP (Greg A. Woods) writes:
>In article <1991Feb15.165755.3231 at pcserver2.naitc.com> kdenning at pcserver2.naitc.com (Karl Denninger) writes:
>> In article <1991Feb13.170319.13308 at virtech.uucp> cpcahil at virtech.UUCP (Conor P. Cahill) writes:
>> >We have a T2500 running full blast on our Equinox 24 port card with
>> >no problems.  We get about 1500 bytes/sec on output and 900-1100 bytes/sec
>> >on input.
>> 
>> However, if you turn on XON/XOFF in a Telebit modem and use spoofing
>> (S111-30), it is smart enough to disable it when a uucp call comes in or
>> out.  Thus, it works for both interactive users AND UUCP calls.
>> 
>> This is not obvious, but it does work.  I do it that way myself on one
>> modem, the other I wired strange for full modem control (CTS/RTS + modem
>> control) since it has V.32 capability and you need it there.
>
>I don't feel entirely qualified to say much directly about Equinox
>ports boards, or Telebit's, but I do have a great deal of async
>experience on a wide variety of hardware.

As do I....

>From what I understand the particular combination of an Equinox card
>and a Telebit will work fine when sending files, since the Telebit
>properly paces everything such that its buffer's don't over-flow.

Actually, the entire connection has pacing in at least three locations -- on
your end, the remote end, and the link between the modems itself.  All done
with the "must ack within 3 packets" UUCP windowing.

>However, in certain circumstances when receiving a file via UUCP with
>this setup, I can see that the uucico may lose packets if there is no
>hardware flow control.  Maybe the uucico is swapped out.  Maybe the
>system has a load average of 15.  Remember, UNIX isn't a real time
>O/S.  Any lost packets will mean timeouts in the uucico.  That's
>probably why Conor is seeing only an average of 1000 cps input.  I'd
>be real disappointed if that's all I was seeing on my system.

Not true.  The Equinox boards can buffer more than the 64 x 3 characters
which can exist "outstanding" in a uucp window of standard size.  The
Telebits can buffer something like 10x that number without losing any
internally.  And they WILL do the appropriate things (like stop sending
"acks" temporarially) when the buffers get to be nearly full.

There is a REASON why UUCP has a window of 3 normally.  That reason is that
you want the characters in the window to fit within a clist, so that if the
process is swapped out you don't drop anything on the floor!  (You'd be
surprised how many people don't know this and patch "windows" to 7 blindly!)

>Now, for any other devices, i.e. non-spoofing modems, hardware flow
>control will be required when sending *or* receiving files with UUCP.

Actually that is not true either.  Again, the window size of 3 works here,
since you MUST ack packet #1 before #4 gets sent.  Since the characters all
fit within the clist structure, your CPU can be slow as molasses and again
you won't lose anything.  This is, of course, providing you can service the
interrupts coming from the serial port if any.  If you can't, you're doomed
since the hardware flow control "trip" requires a interrupt to be processed
too!

If you patch the window size to >3, then you are going to get in trouble if
you can't keep the buffers from filling up.

>In fact I wish our Anchor 2400 modem had working hfc sometimes, since
>when our system gets busy, packets get dropped, and because the alarm
>timeouts are lengthy, it can do a real number on the over-all
>throughput.  On a busy day, our receive throughput may drop from 190
>cps to 90 cps at 2400 bps.  All you folks running single user 33 Mhz
>386's and 16 Mb RAM won't have to worry, but the rest of us do.

Sure.  If you're getting alarms then something else is wrong (ie: you're
not servicing incoming com port interrupts fast enough).

>Finally, I don't care how fast that little Equinox card can receive
>characters, if I can't get them safely onto my disk, all the speed in
>the world won't help.  I.e. can I cat from each port into separate
>files, and receive every byte without any flow control?  That's
>potentially over 90 Kbytes per second coming into the system.  It just
>won't happen on my 386, no matter what O/S I'm running.

Well, >my< 386 can receive 90kb/sec to the disk without any problem at all.
That's less than 1/6th of the throughput of my disk subsystem on a BAD day.
On a good day I can do something like 10-15x that number of bytes to or from
the disk.

90kB/sec is not a big number.  Nor is it a problem for a reasonable system
with good disk I/O performance.

--
Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285
kdenning at nis.naitc.com

"The most dangerous command on any computer is the carriage return."
Disclaimer:  The opinions here are solely mine and may or may not reflect
  	     those of the company.