🚀 go-pugleaf

>From ephraim Thu Feb 19 08:43:49 1987
Path: wang!ephraim
From: ephraim@wang.UUCP (pri=8 Ephraim Vishniac x76659 ms 014 590)
Newsgroups: comp.periphs,comp.sys.mac
Subject: Re: Mac SCSI performance (was Mac-Sun SCSI connection)
Summary: Hardware, not software, is the problem
Message-ID: <418@wang.UUCP>
Date: 19 Feb 87 13:43:49 GMT
References: <2594@phri.UUCP> <1784@hoptoad.uucp> <540211194.20192@minster.UUCP> <1821@hoptoad.uucp>
Organization: Wang Labs, Lowell MA
Lines: 75

In article <1821@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes:
> I am well aware of this; as I pointed out, the Mac does *not* implement SCSI
> very well.  The SuperMac people replaced the SCSI Manager with their own
> software and tripled performance (combined with a lower disk interleave, of
> course) for the Dataframe XP drives.
> 
> >	The review of the Mac+ in November '86 Byte states that the
> >throughput of the SCSI interface is 320K bytes per second; does anyone
> >know if it is really this slow? SCSI is rated at 10M Bits (= 1.25 M Bytes)
> >per second, where is the factor of (almost) four going?
> 
> It is true; the reason they got away with it was that it was so much faster
> than the HD20 and other pre-Mac Plus Mac hard disks, except the ones that
> required major surgery.  The reason is bad software.  But SuperMac isn't
> talking about what they fixed, and neither is anyone else who knows.
> -- 
> Tim Maroney, Electronic Village Idiot

The reason Mac SCSI is slow is lack of hardware support, not bad software.
(The software is bad, but that's another story.)  From an engineering
standpoint, SuperMac's souped-up SCSI manager is *worse* than the original:
it has more timing dependencies and works correctly with fewer SCSI devices.

When transferring SCSI data on the Mac Plus, you have two choices about
how to time transfers.  [Warning!  Hardware talk ahead!]  The safe
choice is to poll DREQ, waiting until it's active before you move the next
data byte.  This means a minimum of three instructions per byte, plus loop
overhead:
	label:	test DREQ
		beq  label
		xfer a byte
		...
(With "pseudo-DMA," xfer a byte is one instruction.  If you unroll the
data xfer loop to a depth of eight or sixteen, the loop overhead is very
small.)

If you want to go faster, and you know something about the timing of
your SCSI device, you can simply do the transfer when you *expect*
DREQ to be active.  This way, you can go a lot faster:
		xfer a byte
		(optional timing fudge; maybe a nop or two)
		xfer another byte
		...
You only slow down for synchronization where you expect a large delay,
such as at sector boundaries.  These are so-called "blind" transfers.  If you
move too fast, you suffer over-run while writing or under-run while
reading, and the Mac dies a confusing death.  SuperMac's big speed-up
comes from tweaking their data transfers so that they're precisely tuned
to their disks.  It's risky as hell, but they don't tell their customers
that.  Apple's blind transfers are deliberately slower so that they'll work
with a larger variety of devices.  

Some SCSI disks deliver or accept data with metronome-like
regularity.  Others have delays here and there due to buffer limits,
internal interrupts, or general cussedness.  The former are effectively
faster on the Mac because you can safely do blind transfers.  (Well,
it's pretty safe, anyway.)  A member of the latter group may be "higher
performance," but slower on the Mac because synchronization is required.

All this discussion would be moot if the Mac either:
	(1) Used real DMA for SCSI transfers; or
	(2) Held off pseudo-DMA operations in hardware until DREQ
	    came active.
That Apple didn't implement (2) is almost criminal.  The hardware
requirements are trivial, the performance implications are staggering,
and no-one would be risking life, limb, and data on those *&$! blind
transfers just to save a few microseconds.

How about it, hardware hackers?  Anyone care to design a Mac Plus 
modification that delays pseudo-DMA access while DREQ is off?


Ephraim Vishniac
decvax!wanginst!wang!ephraim

------------------------------------------------------------------------
Forwarded by:
-- 
    --->Dave Caswell
	{allegra|ihnp4|...}!mhuxu!davec
		-or-
  	davec@borax.lcs.mit.edu