km@mathcs.emory.edu (05/29/90)
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 Has anyone identified a 3rd party source for SLC simms yet? In
particular, is there any other popular machine that uses the same simms?
o What is a good choice for 3.5 inch scsi disks that works with the SLC,
I'm talking about the bare drives not the companies that package it in a
box. If you send me the name and model number of a drive you know works,
I'll collect and summarize.
o Does anyone make a scsi floppy drive that works with the SLC?
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?
Ken Mandelberg | km@mathcs.emory.edu PREFERRED
Emory University | {rutgers,gatech}!emory!km UUCP
Dept of Math and CS | km@emory.bitnet NON-DOMAIN BITNET
Atlanta, GA 30322 | Phone: (404) 727-7963neil@uunet.uu.net (Neil Gorsuch) (05/30/90)
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