Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!rutgers!mit-eddie!attctc!chasm From: chasm@attctc.Dallas.TX.US (Charles Marslett) Newsgroups: comp.os.minix Subject: Re: minix on the macintosh Summary: 10 MHz is VERY RARE as a bus speed! Message-ID: <9418@attctc.Dallas.TX.US> Date: 20 Sep 89 04:45:17 GMT References: <397@crash.cts.com> Organization: The Unix(R) Connection, Dallas, Texas Lines: 133 In article <397@crash.cts.com>, jca@pnet01.cts.com (John C. Archambeau) writes: > dpi@loft386.UUCP (Doug Ingraham) writes: > >Because of a botched design it would be terrible to use the motherboard based > >DMA on the AT. Here are the reasons. I beg to differ, when the PC was designed, the only reasonably available chip was the 8037 -- so IBM built a computer that had real components in it. If you want an example of one that was built of unreal parts, look at the vintage Atari computers (the video chip the computer was designed around was not really manufacturable until the computer was almost obsolete! So they built most of them with a crippled subset chip... not so very different from planning to use the cripple in the first place ;^). > >1) Transfer rate is poor. According to the AT Technical Reference Manual > > Page 1-7 (this is the original 6mhz manual) under system performance. > > The DMA controller operates at 3 MHz, which results in a clock cycle > > time of 333 nanoseconds. All DMA data-transfer bus cycles are five > > clock cycles or 1.66 microseconds. Cycles spent in the transfer of bus > > control are not included. If we assume a 512 byte or 256 word transfer > > the fastest it can go is 425 microseconds. The CPU will be running at > > about half speed during this time because of the DMA. > > For a 6 MHz AT, you are right, but how many of us out there have a 6 MHz AT? And for an 8 MHz bus, the CPU gets a fastest possible transfer of 2 clocks (0.250 uS) and the DMA still gets a fastest possible transfer of 5 clocks (or 0.625 uS). For a 10 MHz bus, designed to work with at least a few commercially available adapter cards, the numbers can get a bit closer, if you accept the fact that the only floppy controllers you can use are the high dollar OMTI ones, then the CPU transfers are either 2 or 3 clocks (.20 or .30 uS) and the DMA transfers are still 5 (.50 uS). And the one 12 MHz box I have ever seen did not do DMA at all (the floppy controllers would only work if the buffer was in the motherboard RAM, and even then OVERRUNS(?) were quite common. > I don't. I have a 16 MHz 286 box. Also, the higher speed '286 chips have to > have to have a higher speed support chip set. Another point, AT bus specs > vary greatly from manufacturer to manufacturer. IBM didn't set the AT bus > technical specifications in stone, the manual you referred to applies ONLY to > a vintage 6 MHz guinine IBM AT. A classic offender of varying greatly from > the AT bus spec was Kaypro with their first 10 MHz '286. The bus ran at 10 > MHz along side the CPU...as a result the higher speed cards were born. The Not very many were -- you cannot design a card to run with the Kaypro bus and have it work with anyone else's. The IBM AT bus spec is not cast in stone, but the timings it used are -- that is why almost none of the busses in the newer 286 and 386 boxes run any faster than 10 MHz (can I say none, absolutely?). If you do, then the 8 and 16 bit slots are useless since no one makes a card that will run in them (or will run in them very well, like the V7 VRAM card that is a fast 16-bit card at 8 MHz, but on a fast 10 MHz bus, it turns into a slow 8-bit card). Unlike the MCA bus, the ISA and EISA system busses are more- or-less synchronous. It is not very easy to change the timing without getting a bad performance penalty. > majority of the '286 motherboards out there are designed to work in an 8 to 10 > MHz bus speed (8 being more standard obviously). Most of my AT cards have a > 10 MHz crystal on them. My motherboard is set up in such a way where I can > run the bus at either full or half CPU clock speed. It's not set in stone > that such a performance loss would be incurred with a high speed '286 > motherboard. Especially one's with all Harris or AMD chip sets. Intel is > pretty P'ed at AMD and Harris for cleaning up their mess and making a better > '286. Won't be too long before the 25 MHz '286's hit the market if they're > not out already. Such performance losses I'm sure were corrected with the > newer high speed support chip sets. We have perhap 15 different vendor's AT boxes running from 8 MHz to 25 MHz, and only two of the whole set run the bus at 10 MHz (and those two default to 8 MHz). Most add in cards (including every EMS card on the market and all but one of the video cards that I have been able to get my hands on) will not run as 16-bit memory at 10 MHz, some will not even run as 8-bit cards at that speed (with 2 extra wait states forced by the motherboard logic to make it "easy"). That, however, is not really a crucial point -- if the DMA processor runs at half the CPU speed, the ratio of CPU transfer rate to DMA transfer rate is 5:1, if it runs on the same clock as the CPU the ratio is still 2.5:1 (or a little worse, if you add in bus arbitration time -- say about 3:1). So programmed I/O still runs three times as fast unless you run the DMA chip off a faster clock than the CPU (and thus, cannot use any of the motherboard chipsets). The only way to win is to go to a better DMA architecture (like the 186 or 188 chips have) -- but then you cannot run any more than a limited set of programs -- No MINIX, no XENIX, no Fastback, etc. > >2) Transfer for 16 bit operations must go to word boundaries. See the > > description under 3 why this is bad. > > > >3) Transfer must not cross over a 64k memory boundary for 8 bit transfers > > or 128k boundaries for 16 bit transfers. Because of limitation 2 and > > 3 the DMA almost always takes place to a buffer on an even byte boundary > > and guaranteed not to cross a 64k boundary. This requires the CPU to > > perform a block move of the data after the DMA operation is complete > > to put the data in the proper place. A 256 word move takes an additional > > 172 microseconds at 6 mhz. > > I never said that the 80x86 chips weren't brain damaged. However, in most > cases a pointer will end up being a word or even a paragraph boundary anyway, > so it's not that big of an issue in my opinion. A smart compiler can adopt > the convention that all pointers are on a word boundary. The file system > part of the kernel can handle the 64K or 128K DMA problem. It's just a matter > of dealing with those idiosyncratic annoyances out there that exist in all > machines. This reduces itself to a memory-to-memory move though, and that is much worse that block I/O (since you have to copy the data twice, now the ratio between DMA and programmed I/O is an atrocious 4:1). That is, if you do not allocate memory in blocks wholly within a 64K block, and I leave it an exercise for the student (:^) to see how that affects fragmentation and performance of the memory manager. > I do agree that I wouldn't implement DMA on a 6 MHz 286 (if you can find them > anymore). However, if the later machines can handle it better as I suspect, > then why not use it? Also, what about DMA on machine equipped with an EISA > bus or MCA? Would it work better than the classic 6 MHz AT bus? Most likely, > but then again, how many of us can afford the bus specs for MCA from IBM? Again, the DMA to CPU ratio is relatively unchanged -- faster machines just mean that you may not need to worry as much about getting full performance out of your box, but DMA is still a lot slower (so you wouldn't use it if speed is critical -- you might if interrupt latency is). Except, that is, for the MCA bus (perhaps). I suspect that it is still enough like the AT to impose most of the same performance penalties, especially since IBM would like to sell the idea of bus mastering for peripherals, and that becomes a whole lot easier if you make DMA a dog. =========================================================================== Charles Marslett STB Systems, Inc. <== Apply all standard disclaimers Wordmark Systems <== No disclaimers required -- that's just me chasm@attctc.dallas.tx.us