davec@mhuxu.UUCP (02/25/87)
>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
jww@sdcsvax.UUCP (02/27/87)
Would someone care to explain why the standard SCSI manager performance is so terrible for writing? Somone said something about not writing blind. Even the standard Dataframe 20 rewrote this, but apparently if you take the ROM version as is, you get slow disk writes (my vendor, Peak Systems, claims.)