oster@dewey.soe.berkeley.edu (David Phillip Oster) (02/14/88)
In article <3600018@iuvax> viking@iuvax.cs.indiana.edu writes: >With the lack of DMA disk storage and graphics support, can A/UX on a Mac II >operate well when multiple tasks are running and disk swaps are taking place? >Doesn't everything grind to a halt until the disk access is completed, since >the CPU is the disk controller? This is kind of the wrong way to look at things. Consider: a DMA unit is a second processor that basically has one instruction: BlockMove(). You would think that the DMA unit could move data around while the CPU is computing, giving you a theoretical factor of 2 speed up. But it just isn't so. In order to move data around, you have to move it over the data bus. The data bus gets just as loaded whether you are using a DMA controller to move the data or using the main CPU. (Because the 68020 has an instruction cache, the loop that moves the data stays in the cache, so all use of the bus is useful data movement.) When the DMA unit is pushing data around, the 68020 is locked out, unable to get any operands from memory, unable to get the next instruction to do. (sure, it could finish a multiply, already in progress, but there aren't many of them in a typical instruction mix.) Conclusion: a DMA unit doesn't help much as long as you only have one data bus in the computer. There is a big problem though: A/UX and the Mac operating system support a type of read operation called asynchronous read: the disk gets a command to transfer data, and the computer goes off and does something else until the disk generates a hardware interrupt to signify that the data is here. (Most programs just do a read(), and wait until the data is there, but under A/UX, there is always something else to run while we are waiting for the read to complete: the A/UX operating system takes care of it.) The problem: most mac programs don't use asynch reads. Most Mac disk benchmarks don't check that the disk driver author actually supports Asynch reads. Since noone asked for it, most of the existing disk drivers just make asynchronous reads wait, just the same as if they were ordinary synchronous reads. (I asked one driver manufacturer why his drives don't run any faster asynchronously, and he said that noone asked for it and he had other things to write, so he took the easy way out and just branched to his synchronous code if the program does try to do asynchronous i/o.) Under the Macintosh Operating system The situation is further confused because Apple removed Asynchronous file Open()s. The Asynchronous bit, in the Open call only, is used to tell a MFS (64k ROM flat file system) from an HFS (128K and more recent ROM: hierarchical file system.) Summary: Don't expect the presence or absence of DMA to be important. What is important is: 1.) the bus bandwidth (Mac II nuBus, versus Sun VME bus) 2.) whether the disk driver authors correctly support asynchronous reads and writes. --- David Phillip Oster --A Sun 3/60 makes a poor Macintosh II. Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60. Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu
donahn@ucbvax.BERKELEY.EDU (Don Ahn) (02/14/88)
In article <22971@ucbvax.BERKELEY.EDU>, oster@dewey.soe.berkeley.edu (David Phillip Oster) writes: > In article <3600018@iuvax> viking@iuvax.cs.indiana.edu writes: > >With the lack of DMA disk storage and graphics support, can A/UX on a Mac II > >operate well when multiple tasks are running and disk swaps are taking place? > >Doesn't everything grind to a halt until the disk access is completed, since > >the CPU is the disk controller? > > This is kind of the wrong way to look at things. Consider: a DMA unit is a > second processor that basically has one instruction: BlockMove(). You > would think that the DMA unit could move data around while the CPU is > computing, giving you a theoretical factor of 2 speed up. But it just > isn't so. In order to move data around, you have to move it over the data > bus. The data bus gets just as loaded whether you are using a DMA > controller to move the data or using the main CPU. (Because the 68020 has > an instruction cache, the loop that moves the data stays in the cache, so > all use of the bus is useful data movement.) When the DMA unit is pushing > data around, the 68020 is locked out, unable to get any operands from > memory, unable to get the next instruction to do. (sure, it could finish a > multiply, already in progress, but there aren't many of them in a typical > instruction mix.) > > Conclusion: a DMA unit doesn't help much as long as you only have one data > bus in the computer. I beg to differ with you here. The amount that DMA will help your system throughput depend on how much of the bus bandwidth you are currently utilizing. If say, your bus bandwidth is 2megbytes/sec, and your CPU utilization is 1m/s, and your disk system transfers at 1m/s, a well engineered DMA controller should be able to "steal cycles" from the CPU and allow it to run close to full speed while it transfers data. Naturally, there will be some contention if CPU bandwidth + DMA bandwith > bus bandwith, but you will be getting almost full utilization of the bus, thus getting improved system performance. Also, in general, DMA controllers are more efficient at moving data around than CPU's so even if the DMA "locks out" the CPU from the bus, it is still a win.}i Supposedly, one of the benefits of using a VAX instead of the 68020 is that the VAX (at equivalent clock frequencies) utilizes less of the bus than the 68020, thereby giving DMA controllers more usable bandwidth. (I don't remember the numbers exacty, something like VAX at 30%, and 68020 at 60%). By the way, the 68030 has a new "burst mode" that uses even more of the bus bandwidth so DMA for the 68030 will probably be a smaller win than that for the 68020. > There is a big problem though: A/UX and the Mac operating system support a > type of read operation called asynchronous read: the disk gets a command > to transfer data, and the computer goes off and does something else until > the disk generates a hardware interrupt to signify that the data is here. > (Most programs just do a read(), and wait until the data is there, but > under A/UX, there is always something else to run while we are waiting for > the read to complete: the A/UX operating system takes care of it.) ..... > Summary: Don't expect the presence or absence of DMA to be important. What > is important is: > 1.) the bus bandwidth (Mac II nuBus, versus Sun VME bus) > 2.) whether the disk driver authors correctly support asynchronous reads > and writes. As for asynchronus writes, a DMA controller also helps because it allows you to tranfer aritrarily sized blocks of data directly into memory. If you want to transfer a 1 meg file into memory asynchronusly, for example, you can tell the DMA controller to load it in and you get an interrupt when it's done. If the CPU is doing transfers, however, you get an interrupt every time the disk controller's buffer fills up. If the buffer is say, 8K, that's 128 interrupts (i.e. context switches) for that one file. DMA can be a big win here. Summary: DMA is a win all around. Big or small depends on your system configuration -- Don Ahn UC/Berkeley Dept. of Zoology 1576 LSB USENET: ...!ucbvax!donahn (415) 643-6299 ARPA: donahn@ucbvax.berkeley.edu
viking@iuvax.cs.indiana.edu (02/14/88)
Thanks David...I appreicate the time you took to explain things. The
question of how A/UX performs in demanding situations is still open,
however. It is slow? Should I think of A/UX as a great 'single-user'
Unix system that solves connectivity issues?
Hey all you beta-testers...what's your experience with the system? My
own initial reaction to an early beta system was positive, and I was
impressed with all the *real* Berekley enhancements (e.g. job control)
to the software. I was also impressed with the ability to access the
Mac Toolbox from A/UX, but I didn't have any chance to benchmark the
system in terms of how fast it ran with multiple-processes and other
disk intensive operations.
Thanks again! Information anyone?
Jon Backstrom "Yah sure...we gonna have fun, you bet!"
Computer Science Department
Indiana University ARPA: viking@iuvax.cs.indiana.edu
Bloomington, IN 47405 UUCP: {pyramid,ihnp4,pur-ee,rutgers}!iuvax!viking