Xref: utzoo comp.sys.sun:9716 comp.periphs.scsi:553
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!sun-spots-request
From: zardoz!uninet!neil@uunet.uu.net (Neil Gorsuch)
Newsgroups: comp.sys.sun,comp.periphs.scsi
Subject: Re: SLC add-ons?
Keywords: Hardware
Message-ID: <8337@brazos.Rice.edu>
Date: 30 May 90 00:55:47 GMT
Sender: root@rice.edu
Followup-To: comp.sys.sun
Organization: Sun-Spots
Lines: 41
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v9n185
X-Sun-Spots-Digest: Volume 9, Issue 191, message 4

In article <8232@brazos.Rice.edu> km@mathcs.emory.edu writes:
>Here's a bunch of questions about add ons for the SLC. With the exception
>of the first, experience with the SS1 external SCSI should probably be
>enough for an answer.
>o One company sells a SCSI peripheral with multiple serial ports.
>  Apparently they have a user program that reads and writes /dev/sd?, and
>  distributes the characters using ptys.  On an SS1 you could uses an S-BUS
>  card, but this is the only way to get serial expansion on an SLC. This
>  approach scares me though. I would think that if you were paging hard off
>  a SCSI disk, the single character serial could see lots of delays. The
>  extra context switches in the user program wouldn't help either. Any end
>  user experience with this?

That's us 8-).  The SCSI bandwidth used by the SLAT (our serial/parallel
expansion box) is so small compared to the SCSI total bandwidth, that
there just isn't a problem.  And when you're talking about "paging hard",
there is still a lot of unused time on the SCSI bus, because of
read/writes using buffers that are too small for optimum disk usage in
SunOS, and waiting for disk head movement.  I have never seen the SLAT
polling rate be greatly affected by disk activity, and we do a lot of
stress testing here.  Our box transfers data to/from the SCSI bus at 2.5
Mbytes a second on the Sparcstation, and even if you have 8 ports banging
away at 38.4 K baud each, that's only about 30K characters per second,
hardly a dent in the SCSI even with hard paging going on and accounting
for SCSI command overhead.  There is always time in between disk head
movements to slip in a few SLAT reads/writes.  As far as CPU overhead and
context switching, a SLAT uses less than 1 % of the CPU when idle, and
climbs to maybe 3 % when going full blast.  You can set the SCSI "disk"
polling to be any rate you want, 10 reads per second is comfortable and
provides an undetectable delay for human terminal users, and that only
requires about 40 context switches per second for the SLAT at worst case,
and dynamic polling and other cute stuff about to be released puts it back
down to around the SCSI poll rate.  What we have found, is that the Sparc
CPU and tty drivers can't even begin to swamp the SLAT/SCSI combination
when producing or swalling serial characters.  The usual limitation is the
tty/pty driver.

Neil Gorsuch     INTERNET: neil@uninet.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