earleh@eleazar.dartmouth.edu (Earle R. Horton) (01/03/89)
The following is an excerpt from David Phillip Oster's Asynch IO test, posted to info-mac: > I want to get Macintosh programmers up in arms about the shameful state >of 3rd party Macintosh hard disk driver software. The Mac operating system >supports a wonderful feature that could let our programs run much faster, >but the developers of disk driver software have cheated us out of it. > > I am referring to asynchronous disk i/o. According to Inside Mac, >if you do a PBRead(&ioBlock, TRUE), or, a PBWrite(&ioBlock, TRUE), the >call should schedule the i/o, and return almost immediately, and when >the i/o is actually done, the system will set some fields in the >ioBlock, and call the completion routine associated with the ioBlock. The posting comes with a small test program to show whether your disk driver manufacturer supports asynchronous IO. I tried it on a Mac II with an Apple HD SC 80 running the driver from Apple HD SC Setup version 2.0 and System 6.0.1. The hard disk driver failed the test. The read call did not return until the IO was complete. I stepped through the program using a debugger, just to make sure. A trace command over the asynchronous read call in the example program did not complete until the disk IO was finished, and this was more than a second! The Apple hard drive and driver do not support asynchronous reads. For shame! The Nova 30 from MicroTech does not support asynchronous reads, either. I find this less remarkable than what I found about the Apple drive. Mr. Oster also says: >Let us create a hall of shame. Does your hard disk support asynchronous i/o? >if not, please post their name here, so we can complain. So we can get some >action, so we can get disk based programs that run at all-RAM speeds! I don't think this will do much good if Apple drives do not support asynchronous IO. Does anyone know of drives that do? What's the story here? It looks like Apple belongs in first place in the Hall of Shame unless somebody comes up with a good excuse for the behavior of the Apple driver. By the way, it is not necessary to have an ioCompletion routine in order to make use of asynchronous IO. Polling the ioResult field of your Parameter Block will do nicely. IoBlock.ioResult will be positive until the request has been satisfied, and will turn negative on failure, zero on success. Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755 (603) 643-4109 Graduate student.
grg@berlin.acss.umn.edu (George Gonzalez) (01/04/89)
Asynchronous I/O is a wonderful idea if you have a true pre-emptive multi- tasking system. The system can start an I/O request, and run another task while waiting for the I/O to complete. This means tasks get more CPU time; less time is spent waiting for I/O. If its done right, the tasks need not know or worry about the I/O being done asyncronously. Just wonderful. But the current Mac O/S can't make good, general use of async I/O right now. In general, there isn't another task that can be run while waiting for the I/O. Even under Multi-Finder, the system can't preeemtively switch tasks when doing I/O. So async disk I/O is mostly pointless right now. One exception: if you are a clever programmer, you *can* write a program that starts an async disk operation and then goes and does something useful while waiting for the I/O. But this is a special case that speeds up just your special program. It doesnt help the rest of us sods waiting for the Finder to copy a file. It doesnt help the 1000+ other applications out there either. The current Mac O/S puts the async I/O burden on the programmer. This is a bit less than perfect, as async I/O code is somewhat tricky. I'd hate to see 1000 different applications implementing async I/O, all in slightly different, and possibly buggy ways. Ideally, they would have built async I/O into the system so we wouldnt have to discuss it now. Maybe a future version of the system will do just that. I suspect A/UX does it right now. So, let's not worry to much about some disks drives/drivers not supporting async I/O right now. Its not too useful for most of us at this time.
oster@dewey.soe.berkeley.edu (David Phillip Oster) (01/04/89)
1.) Since I wrote the original posting and the test program I learned that
the SCSI hardware on a MacPlus, anyway, does not support any kind of
interrupt mechanism. This, at first glance, would seem to make it
impossible, but it doesn't really (after all, the floppies do it.):
Disk drive access consists of two phases: latency, and transfer. During
disk drive latency, the computer is waiting for the disk head to move to
the correct track, and to wait for the correct sector to come under the
disk head. During transfer, the actual data is transfered. You can't do
much processing during the transfer phase, because you need the memory bus
to move the data, and, on a mac without DMA, you need the CPU to move the
data for you.
The latency phase is another matter. Here are many milliseconds where the
disk drive is silent, busy playing with itself, and mac programs are
wasting their time waiting for it. A driver could easily use the time
manager to poll the drive once a millisecond to see if a "seek" command
has finished, giving all that seek time back to the application program,
then do the actual transfer as it is done now.
2.) Some people still think a Mac is a bad unix system. It is completely
inappropriate to leave asynchronous i/o to the operating system. When I
am working with a program, I want _that program_ to run absolutely as fast
as possible. In a multi-user operating system, it si common
practise not to bother with this, but give the i/o time to other users.
On a single user machine, there are no other users. 10 years ago, when I
was in graduate school, there was research on implementing programming
langauges that used the asynchronus i/o time to fetch head, so that
programs written in these langauges never had to wait for the disk for
their data: they asked for it before they needed it and kept on going. By
the time they needed the data, it wa there. To do this, you _need_
asynchronous i/o.
It may be that only clever programmers will use this to write superior
application programs. I'm not afraid of that. I'm clever enough to
compete, and I want those superior applications to use.
--- David Phillip Oster --"When we replace the mouse with a pen,
Arpa: oster@dewey.soe.berkeley.edu --3 button mouse fans will need saxophone
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu --lessons." - Gaseeearleh@eleazar.dartmouth.edu (Earle R. Horton) (01/04/89)
In article <271@berlin.acss.umn.edu> grg@berlin.acss.umn.edu (George Gonzalez) writes: > >Asynchronous I/O is a wonderful idea if you have a true pre-emptive multi- >tasking system. The system can start an I/O request, and run another task >while waiting for the I/O to complete. This means tasks get more CPU time; >less time is spent waiting for I/O. If its done right, the tasks need not know >or worry about the I/O being done asyncronously. Just wonderful. I believe you are missing the point here. There are many cases where a user is interested in ONE task coming to completion as fast as possible, and where that task involves both significant I/O and significant computation. An example might be a multi-dimensional disk-based FFT. If things run only the way you describe, the FFT program gets swapped out every time it accesses the disk, and other, less important, tasks get use of the machine. The important task might even lose several time-slices if the I/O takes a while. It could have used these for significant computation if only the programmer had considered use of asynch I/O and the system had supported it. This is why VMS, a multi-tasking system, allows a programmer to specifically request asynchronous I/O instead of the other kind. This applies whether or not the operating system supports pre-emptive or any other kind of multi-tasking. If you, the programmer, are limited to synchronous I/O then you simply are not capable of providing the performance you could, were you allowed to use asynch I/O. This can be the case, even in a pre-emptive multi-tasking system, if a task has to give up control while it waits for I/O. The Mac OS supports asynchronous I/O for all drivers installed in the system. Inside Macintosh gives quite precise instructions for an application developer to use it. There can only be one of two reasons why this feature is not implemented for SCSI hard disks, even the Apple HD SC 80: a) Disk driver writers were too lazy to put it in, and figured most people wouldn't miss it. b) The present SCSI interface is not capable of it. I don't know how this could be true, but I am extremely unwilling to believe that the Apple drive cannot do asynch I/O because of the first reason. Anybody have any idea which of the above is true? I've started to wonder, since the Apple HD SC 80 failed Oster's Asynch test program last night. Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755 (603) 643-4109 Graduate student.
brecher@well.UUCP (Steve Brecher) (01/04/89)
In article <11605@dartvax.Dartmouth.EDU>, earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > The following is an excerpt from David Phillip Oster's Asynch IO test, > posted to info-mac: >> I want to get Macintosh programmers up in arms about the shameful state >> of 3rd party Macintosh hard disk driver software. The Mac operating system >> supports a wonderful feature that could let our programs run much faster, >> but the developers of disk driver software have cheated us out of it. >> >> I am referring to asynchronous disk i/o... > The Apple hard drive and driver do not support asynchronous reads. For > shame! ... Does anyone know of drives that do? It is not the driver software that is to be "blamed," it is the Macintosh. Asynchronous I/O is possible only if interrupts and/or DMA are supported by the hardware, and the Macintosh supports neither for SCSI I/O. It might be theoretically possible for a SCSI disk driver to perform seeks asynchronous to program execution, but it would have to poll for seek completion by using a VBL task or Time Manager task; that would probably add enough overhead to make it infeasible. As for SCSI data transfer, it all goes through the CPU and hence cannot be performed asynchronously. -- brecher@well.UUCP (Steve Brecher)
amanda@lts.UUCP (Amanda Walker) (01/04/89)
grg@berlin.acss.umn.edu (George Gonzalez) writes:
Ideally, they would have built async I/O into the system so we
wouldnt have to discuss it now. Maybe a future version of the
system will do just that. I suspect A/UX does it right now.
Umm... that was the point. Apple *did* build Async I/O into the
system, it's just that their SCSI disk driver is incapable of
supporting it. A/UX, last I knew, didn't support it at all, just like
most UNIX systems (well, they might have put in support for async I/O
for sockets using SIGIO, but that's a special case).
--
Amanda Walker ...!uunet!lts!amanda / lts!amanda@uunet.uu.net
InterCon, 11732 Bowman Green Drive, Reston, VA 22090
--
Calm down; it's only ones and zeros...earleh@eleazar.dartmouth.edu (Earle R. Horton) (01/04/89)
In article <27318@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >1.) Since I wrote the original posting and the test program I learned that >the SCSI hardware on a MacPlus, anyway, does not support any kind of >interrupt mechanism. This, at first glance, would seem to make it >impossible, but it doesn't really (after all, the floppies do it.): > OK, that explains why the Apple HD SC driver does not appear to do asynchronous I/O, sort of. I believe Apple might be dropping the ball on this one, however, in not insisting on at least some form of asynchronous I/O in all device drivers to run under the Mac OS. The ability for a programmer to specify asynchronous I/O in such an easy fashion as is allowed on the Mac is something which sets it apart from other comparably priced systems. You don't even have to establish a "mailbox" before doing so! (It is REALLY a pain to do asynch I/O on some systems.) It appears to me that asynch I/O is only widely used for "slow" devices like the serial ports and the Sony disk driver. It is just as valuable a feature for "fast" devices, too. >It may be that only clever programmers will use this to write superior >application programs. I'm not afraid of that. I'm clever enough to >compete, and I want those superior applications to use. > So people won't get the impression that asynch I/O is an esoteric programming practice only suited for heavy-duty number crunchers, allow me to give a few examples where it could come in handy for any Macintosh program. Let's say you open and start to read/write file which you have accessed from Standard File. Assume the disk driver software gives you a few thousand cycles to play with while it is seeking for disk blocks in the file. This is probably enough time to run through your main event loop a couple times, and maybe even service the update event generated by the appearance of the Standard File dialog. If your main event loop is smart enough not to interfere with the pending I/O, then there are lots of things it could do. This might not seem like a lot, but if it allows you to keep your program's windows clean for a fraction of a second longer than the other guy, it might just make you look like a performance programming expert. You can do this right now with the floppy driver, so try it! How about a file conversion utility, like BinHex, or StuffIt, or anything that reads in a file, does some conversion on it, then writes out another file. These are real handy, but when I am running one I can't wait for it to get done. If the disk driver gives back any fraction of unused time to the application, which is then smart enough to interleave the conversion process with I/O, then the user may be spared a few seconds of boredom. This is important, especially if the conversion operation is a real important one like backups. Apple had a real good idea when they allowed the Device Manager calls to specify asynchronous or synchronous I/O, in a fashion which is easy to program. They should have followed through with this idea, making it clear to third party hardware developers that asynch I/O is expected, and that any unused time belongs to the calling application. Future devices will be capable of supporting this feature, but only if programmers today make it clear that it is a necessary one. Of course, the Print Manager supports asynchronous I/O, and Apple printer drivers make it REAL easy to take advantage of it. All you have to do is pass the Printing Code a pointer to your idle routine, and the Print Manager will call it whenever it is waiting for the serial port. How many Macintosh applications actually do something useful with their idle procedure, or even supply one? Lots of them don't even update their front window after the Job Dialog is closed, and many use the idle time to do nothing but check for command '.'. The screen display while most applications print is a lot less appealing than it could be, given that the Print Manager gives you time back when it is printing, and did so long before MultiFinder. This makes such applications look unfinished to me. Maybe this is why we don't have more aggressive support of asynch I/O on the part of Apple, that they sense that most programmers simply couldn't be bothered with the "trouble" it takes to use it. Asynchronous I/O is very little trouble to use, considering all the benefits, and I for one would be disappointed if it fell into disuse because of lack of programmer interest. Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755 (603) 643-4109 Graduate student.
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (01/04/89)
In article <11614@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes:
.The Mac OS supports asynchronous I/O for all drivers installed in the
.system. Inside Macintosh gives quite precise instructions for an
.application developer to use it. There can only be one of two reasons
.why this feature is not implemented for SCSI hard disks, even the
.Apple HD SC 80:
. a) Disk driver writers were too lazy to put it in, and
. figured most people wouldn't miss it.
. b) The present SCSI interface is not capable of it. I don't
. know how this could be true, but I am extremely unwilling
. to believe that the Apple drive cannot do asynch I/O because
. of the first reason.
.Anybody have any idea which of the above is true? I've started to
.wonder, since the Apple HD SC 80 failed Oster's Asynch test program
.last night.
The problem with SCSI is that, if you give the CPU back to a user (the same
or another user .. it doesn't matter), the user may try to start another SCSI
operation .. perhaps on a different device. Now SCSI supports such things, via
the Disconnect-Reselect messages, but the MacOS does not (BTW: A/UX does
support disconnect-reselect). The reselect comes from the peripheral, so the
OS has to do some work to determine which driver is the correct one to restart.
There are words in the SCSI sections of Inside Mac that hint that SOMEDAY (real
soon?) the MacOS will support disconnect-reselect, but until that time comes,
the OS cannot take the chance that two operations will be active on the bus
at the same time.
Marc Kaufman (kaufman@polya.stanford.edu)beard@ux1.lbl.gov (Patrick C Beard) (01/04/89)
You are wrong! I have used Asynchronous calls with Appletalk and what do I do while I poll the ioResult field? I call WaitNextEvent under MultiFinder! This gives other applications time, and lets the user switch out of the current application and do something else. This same feature could be used for disk i/o. Patrick Beard Berkeley Systems Design Lawrence Berkeley Laboratory
oster@dewey.soe.berkeley.edu (David Phillip Oster) (01/04/89)
In article <10205@well.UUCP> brecher@well.UUCP (Steve Brecher) writes: }by the hardware, and the Macintosh supports neither for SCSI I/O. It might }be theoretically possible for a SCSI disk driver to perform seeks }asynchronous to program execution, but it would have to poll for seek }completion by using a VBL task or Time Manager task; that would probably add }enough overhead to make it infeasible. Not so, we are talking about 10s of instructions per millisecond. All the rest of the cpu time goes to the application to get useful work done. The i/o driver authors are just lazy.
ephraim@think.COM (Ephraim Vishniac) (01/04/89)
In article <11614@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: >The Mac OS supports asynchronous I/O for all drivers installed in the >system. Inside Macintosh gives quite precise instructions for an >application developer to use it. There can only be one of two >reasons why this feature is not implemented for SCSI hard disks, even >the Apple HD SC 80: > a) Disk driver writers were too lazy to put it in, and > figured most people wouldn't miss it. > b) The present SCSI interface is not capable of it. I don't > know how this could be true, but I am extremely unwilling > to believe that the Apple drive cannot do asynch I/O because > of the first reason. >Anybody have any idea which of the above is true? I won't stick my neck out by essaying a definitive answer, but I believe that (b) is so very nearly true that (a) can be taken for granted. That is, it's so difficult and of so little benefit in most cases that you'd have to be real masochist to go for it. The main problem is that the Mac provides no interrupts from the SCSI interface. (They do for the floppy, so async floppy I/O is much easier.) So, you have no choice but to poll the SCSI interface. You can either sit in a loop and do this, as everybody does, or you can try to figure out some scheme with VBL's to get coarse polling with lower performance. BTW, Developer Technical Support (and, I think, one of the Tech Notes) strongly advise against SCSI operations from a VBL. Ephraim Vishniac ephraim@think.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 "He shook his head to clear a momentary system error."
paul@taniwha.UUCP (Paul Campbell) (01/06/89)
In article <872@lts.UUCP> amanda@lts.UUCP (Amanda Walker) writes: >Umm... that was the point. Apple *did* build Async I/O into the >system, it's just that their SCSI disk driver is incapable of >supporting it. A/UX, last I knew, didn't support it at all, just like >most UNIX systems (well, they might have put in support for async I/O >for sockets using SIGIO, but that's a special case). Like most unixes A/UX doesn't allow processes to make mac-style async IO requests, but it does do async SCSI IO in the kernel (ie while process A is waiting for a read, process B can do other processing). It doesn't just stall the whole system in a loop waiting for a SCSI device to do a seek and transfer. Also like most other unixes it does block read ahead on file accesses (ie when you read block #4 in a file it will read ahead block #5 while you are processing block #4), this also happens asynchronously so you do get the general effect. On writes IO is buffered in the block cache giving a similar effect. Also if you have multiple disks that support disconnect/reconnect it can start a transfer on one disk, then the other then reconnect to them when the interrupt back to say that the seeks/transfers have completed (of course the transfer across the SCSI from the controller's buffer still has to be done by the processor). For other than disk IO you can do the equivalent to async IO in many systems that have BSD select() (including A/UX), between this and kernel buffering on input and output you get the equivalent functionality (when you do your own async IO in a Mac (or Dec or ...) style system you end up spending all your time playing with buffers anyway). You do end up structuring your code VERY differently (the AppleTalk package CAP from Columbia is a very good example). I suspect that the reason that the Apple MacOS SCSI driver isn't asynchronous is that it was originally written on a system where it couldn't be (MacPlus) and that it would probably need a complete rewrite to work both on systems where one set of hardware supports interrupts and one doesn't (I guess you would end up with different drivers .... but then the driver is on the disk so you couldn't move the disks around ....). By the way the IWM doesn't generate interrupts either, I guess it probably uses VBLs while the hardware is seeking. Paul -- Paul Campbell ..!{unisoft|mtxinu}!taniwha!paul (415)420-8179 Taniwha Systems Design, Oakland CA "Read my lips .... no GNU taxes"
brecher@well.UUCP (Steve Brecher) (01/06/89)
In article <27336@ucbvax.BERKELEY.EDU>, oster@dewey.soe.berkeley.edu (David Phillip Oster), argues for the feasibility of timer interrupt driven polling of SCSI disk head positioning: > ... we are talking about 10s of instructions per millisecond. All the > rest of the cpu time goes to the application to get useful work done. The > i/o driver authors are just lazy. Right except for the last sentence (the "lazy" accusation). Macintosh Technical Note #96, p. 5: "The SCSI Manager (all machines) does not currently support interrupt-driven (asynchronous) operations. The Macintosh Plus can never support it since there is no interrupt capability, although a polled scheme may be implemented by the SCSI Manager. The Macintosh SE [and II have] a maskable interrupt for IRQ. Apple is working on an implementation of the SCSI Manager that will support asynchronous operations on the Macintosh II and probably on the SE as well. Because the interrupt hardware will interact adversely with any asynchronous schemes that are polled, it is strongly recommended that third parties do not attempt asynchronous operations until the new SCSI Manager is released. Apple will not attempt to be compatible with with any products that bypass some or all of the SCSI Manager. In order to implement software-based (polled) asynchronous operations it is necessary to bypass the SCSI Manager." I am not sure that the tech note is correct in stating that the SE/II have a maskable interrupt for IRQ. (IRQ is the SCSI host adaptor signal for an interrupt request.) As far as I can tell from Macintosh Hardware Reference, APDA Draft March 2, 1987, while IRQ is tied to a VIA it is not an available source of VIA interrupts, i.e., there is no bit for the IRQ interrupt in the VIA interrupt and flag registers, and no unused bits. In sum, lack of asynchronous capability in disk drivers is not due to laziness on the part of their authors. -- brecher@well.UUCP (Steve Brecher)
ephraim@think.COM (Ephraim Vishniac) (01/06/89)
In article <315@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes: >By the way the IWM doesn't generate interrupts either, I guess it >probably uses VBLs while the hardware is seeking. You're half right, and I was half right. (I had earlier asserted that the floppy driver was interrupt driven, and that the IWM did generate interrupts.) Looking at IM II-197, I see that the Disk Driver (i.e., .Sony since this is IM II we're reading) is blessed with exclusive use of VIA timer 2. No interrupt slot is shown for the IWM. So, things look like this: . The floppy driver uses interrupts, but . There are no IWM interrupts, but . There is a VIA timer reserved for the floppy driver, so . The floppy driver doesn't use a VBL task. Ephraim Vishniac ephraim@think.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 "He shook his head to clear a momentary system error."
ts@cup.portal.com (Tim W Smith) (01/07/89)
This is in response to the suggestion that Mac disk drives could let the application do something useful while the disk seeks by polling the drive with a Time Manager task. I am assuming that we are talking about SCSI disk drives here. A read from a disk will follow this sequence: SCSIGet SCSISelect SCSICmd SCSIRBlind SCSIComplete Perhaps the driver could return after the SCSICmd, and then periodically do a SCSIStat to see if the bus is in the DATA IN phase, and if so, issue the SCSIRBlind command. However, before I would consider doing this sort of thing in my driver, I would need some reassurances from Apple that the SCSI Manager is not going to get screwed up. For example, what happens if someone else tries to do a SCSIGet? Hopefully, they will simply get an error, and everything will be fine. But I wouldn't want to bet my data on it unless Apple says it's ok. Another thing to watch out for is SCSI devices that poll. Apple says not to poll. But consider something like an Ethernet box that attaches via the SCSI port, such as Dove's FastNet SCSI, or the similar box from Kinetics ( I don't remember what they call theirs ). These things have to poll, since there are no interrupts from SCSI. Before doing a scheme like the above with my disk driver, I would want to check with Kinetics and make sure I won't conflict with the way they use the SCSI port. ( I wouldn't have to check with Dove, because I wrote their alternate appletalk software, and I was very careful to avoid anything that could conflict with other SCSI users ). In summary, I think it might be workable, but it's risky. Tim Smith ps: MACDTS has said that the SCSI Manager will be re-written. Perhaps when this happens, it will be safer to do the various things described above.
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (01/08/89)
In article <13271@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >Another thing to watch out for is SCSI devices that poll. Apple says not >to poll. But consider something like an Ethernet box that attaches via >the SCSI port, such as Dove's FastNet SCSI, or the similar box from >Kinetics ( I don't remember what they call theirs ). These things have >to poll, since there are no interrupts from SCSI. I don't understand what Apple means by that. I conjectured that they just meant that the OS can't support Disconnect-Reselect protocol, wherein the target device initiates a reselection. 'Polling' from the CPU side is safe, since each SCSI transaction goes to completion before you give up the CPU. Marc Kaufman (kaufman@polya.stanford.edu)
ts@cup.portal.com (Tim W Smith) (01/08/89)
I've done some measurements, and the results are interesting. I had a program that did reads of random blocks from a SCSI disk. The logic for doing the reads went like this: SCSIGet SCSISelect SCSICmd wait for bus to be in DATA IN phase SCSIRBlind SCSIComplete The program would read a few hundred random blocks in the first 32 meg of the disk. The function that performed the above operations kept track of how long it took for the scsi bus to enter the DATA IN phase after the command ( by counting the number of times it had to read the bus status before findind the correct phase ). Here are the results for two drives I have on my Mac II: SyQuest SQ555 Average access time according to manufacturer 25 msec Average measured time for read command via SCSI manager 40 msec Average measured time command until DATA IN phase 1 msec Quantum ProDrive 80 Average access time according to manufacturer 18 msec Average measured time for read command via SCSI manager 32 msec Average measured time from command until DATA IN phase 25 msec Thus, it appears that a driver that returned after the command was issued and polled via the Time Manager every millisecond would be able to give the application about 25 msec of extra run time if the drive being used is a Quantum ProDrive 80, but only 1 millisecond on the SyQuest SQ555. Thus, an asynchronous driver looks possible for the ProDrive 80. The SQ555 is more doubtful, because the average delay is so close to the resolution of the Time Manager. Of course, real usage does not follow the random access pattern of my test program. Another test program I had did sequential access, and the delay after the command while waiting for DATA IN was much shorter. To determine if an asynchronous driver makes sense, someone needs to determine the average delay under real world access patterns. These numbers are interesting because the Quantum is the faster drive. I would conjecture that the SyQuest is putting the bus in DATA IN phase before it actually has the data, while the Quantum is waiting until it is ready to transfer the data. The other interesting this is the measured times vs. the manufacturers claimed times. Sure, I expect my times to be slower, because of SCSI manager overhead and stuff like that, but 1.8 times as slow? Also, note that the time from SCSICmd() returning to the time the drive places the bus in DATA IN phase has nothing to do with the Macintosh. This is purely determined by the drive. For the ProDrive 80, this time was longer than the claimed average access time. I don't understand how a drive with an average access time of 18 msec can take an average of 25 msec to switch to DATA IN phase. On the other hand, the ratio of measured read times to claimed average access time was pretty close to the same for both drives. Perhaps "average access time" means the time it takes the drive to seek and rotate to the data, rather than the time it takes the drive to actually process the command and get the data out on the SCSI bus? Is this what drive manufacturers mean when they quote average access time figures? Tim Smith
ts@cup.portal.com (Tim W Smith) (01/10/89)
Apple means not to poll from interrupt level ( such as vertical retrace tasks ). These can interrupt while another SCSI operation is in progress. Network devices that hook up via SCSI have to poll from interrupt level, however, because accRun events do not get generated when you are stuck in a synchronous file operation over a file server. Also, removable media devices have to poll at interrupt time if they are waiting for a disk to be inserted. This is because you don't get accRun events when the system is displaying the "Please Insert Disk So-and-so" dialog. At least these don't really have to worry about wiping out someone else's use of SCSI, since the system is hung waiting for the disk anyway. The hard part is that there are people out there that assume that they are the only ones going against Apple recommendations. If all the people that had to poll at interrupt time got together, we could agree on some convention to avoid wiping each other out. Tim Smith ps: note that it is not sufficient for network devices that connect via SCSI to only be careful when they poll via vertical retrace tasks. They must also be careful when called to send a packet, because many users of AppleTalk send packets during interrupt time. Removable media drivers at least don't have to worry about this one.
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (01/11/89)
In article <13369@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >Apple means not to poll from interrupt level ( such as vertical retrace >tasks ). These can interrupt while another SCSI operation is in >progress. >The hard part is that there are people out there that assume that >they are the only ones going against Apple recommendations. If all >the people that had to poll at interrupt time got together, we could >agree on some convention to avoid wiping each other out. I first thought that it would be sufficient to check for BUSY status before doing a SCSIget, but I see that an interrupt could occur between the check and the Get. I haven't tried to trace SCSIget, but I think that an indivisible check-and-get (i.e. with interrupts off), that returned busy status if the bus was already in use, would work. Is this worth a system patch? or does SCSIget already check for busy? Marc Kaufman (kaufman@polya.stanford.edu)
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (01/11/89)
In article <6006@polya.Stanford.EDU> kaufman@polya.Stanford.EDU (Marc T. Kaufman) writes: >I first thought that it would be sufficient to check for BUSY status before >doing a SCSIget, but I see that an interrupt could occur between the check and >the Get. I haven't tried to trace SCSIget, but I think that an indivisible >check-and-get (i.e. with interrupts off), that returned busy status if the >bus was already in use, would work. Is this worth a system patch? or does >SCSIget already check for busy? Silly me. I neglected to check the back of IM-V, where a new return from SCSIget, 'scArbNBErr' is defined. Given this, why can't we at least START SCSI operations from interrupt routines (you wouldn't want to hold interrupts off for the entire operation, though). Marc Kaufman (kaufman@polya.stanford.edu)
ephraim@think.COM (Ephraim Vishniac) (01/11/89)
In article <13369@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >Also, removable media devices have to poll at interrupt time if they >are waiting for a disk to be inserted. This is because you don't get >accRun events when the system is displaying the "Please Insert Disk >So-and-so" dialog. At least these don't really have to worry about >wiping out someone else's use of SCSI, since the system is hung >waiting for the disk anyway. This is semi-true. You don't get accRun events, but you don't have to use a VBL task. In the driver for the Jasmine MegaDrive, I used a patch to _GetNextEvent (maybe _GetNextOSEvent?) because that's the only trap repeatedly called by the disk swap routine. In my patch, I peek at the TickCount to see whether a couple of seconds have passed since my last poll. If not, I've only cost the user about a dozen instructions of execution time. If so, I simulate an accRun call to my driver. Mactech did suggest using a VBL task, but it looked like bad advice to me. BTW, looking at the clock is much better than counting calls to GetNextEvent because the frequency of GNE calls in the disk swap dialog varies enormously between different Mac models. Ephraim Vishniac ephraim@think.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214 "Arlo Guthrie, it seems, has found what he was looking for: God, and the Macintosh." (Boston Globe)
ts@cup.portal.com (Tim W Smith) (01/13/89)
< use a VBL task. In the driver for the Jasmine MegaDrive, I used a < patch to _GetNextEvent (maybe _GetNextOSEvent?) because that's the < only trap repeatedly called by the disk swap routine. In my patch, I ... < Mactech did suggest using a VBL task, but it looked like bad advice to < me. BTW, looking at the clock is much better than counting calls to ... < Ephraim Vishniac ephraim@think.com You're right - I forgot about that method. Someone suggested it to me as an alternative to a VBL task, but I went with the VBL task because I have had to use them before, so it seemed that it would be quicker to get that working. Tim Smith