skraw@thiger.UUCP (Stephan von Krawczynski) (08/20/90)
>In article <1898@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <02048.002057@thiger.UUCP>, skraw@thiger.UUCP (Stephan von Krawczynski) writes: >>2. why is DMA so important for you? it is generally slower than the >>processor-method (lets call it this way). you win nothing because you >>have a whole lot of DMA going on already inside the system and processor's >>running into heavy troubles sometimes, e.g. harddisk-performance is >>very low while using overscan-graphics (just to mention an example). this was a typical "late-night"-statement. of course what i wanted to say was: DMA (other than bitmap) runs into heavy troubles sometimes during overscan-graphics (e.g.) >You are completely wrong in this. Not only is DMA faster,[...] right, but bus-arbitration breaks it completely up. >Do not confuse one particular implementation of a >DMA controller, which did have a significant problem under heavy DMA >conditions, for the entire spectrum of controllers. i have seen no dma-controller yet, that didn't have problems. >>well, how about "transfer rates up to 4MB/SEC synchronous" (gvp). in fact >>i have never understood this one. what do they mean? 4MBytes/sec? > >No. they mean 4 MBytes per second, and that is indeed realistic. Of course you >have to realize that they are not taking about sustained troughput, but about >the actual data transfer rate as seen on the SCSI bus, from a Controller to >Host Adapter. i know this. but tell me: is it really interesting for the customer to hear somthing about the scsi-bus-transferrate. especially if the controller-to- amigamem troughput brings the thing down to some 100 kBytes (a typical bottle-neck). let's talk about the real throughput, not some part of the story. >>i have never seen a controller/hd-combination reaching this. > >Several do it all the time. Note the difference between SCSI bus transfer rates >and disk to destination throughput. i note, but can a (technically uninformed) custumer? >>4MBits/sec = 512kBytes/sec. seems to be more like the truth, but is an >>absolutely ridiculous value (ALF3 makes over 200kBytes/sec more in a >>standard amiga - NO processor-card installed) >>i think it's a reputable company, what do you think? > >Reputable probably. Slow, definitely. ah, there it is. >-larry -- best regards, stephan von krawczynski UUCP : ...!cbmvax!cbmehq!cbmger!danube!thiger!skraw PHONE: +49 9938 1664 FAX : +49 9938 1598
skraw@thiger.UUCP (Stephan von Krawczynski) (08/20/90)
>In article <03283.AA03283@babylon.UUCP> rbabel@babylon.UUCP (Ralph Babel) writes: >In article <02048.002057@thiger.UUCP> skraw@thiger.UUCP >(Stephan von Krawczynski) writes: > >> 1. GVP does not DMA to amiga-memory. > >Not true, GVP does full DMA! which gvp? do you know what brings me down? i did try to get a new gvp-controller. in fact i did only reach a production-date of may 1990. and this controller had HEAVY problems with sony-opticals (in fact we couldn't get them working though we tried hard). >This guy doesn't know what he's talking about - a very bad >habit when you're talking about a competitor's product. See >my earlier articles for details. possibly i didn't get them (would you mail them to me?) >> 2. why is DMA so important for you? it is generally slower >> than the processor-method (lets call it this way). > >Careful ... as long as i don't see any controller being faster than ALF3 ... >"PROCESSOR's running into heavy troubles"? Freudian slip? see other posting. in fact, we both know that the processor cannot run into problems having about half of the DMA-cycles (to chipmem) available in the system. >DMA to real Fast-RAM should not be affected by the DMA-load >on Chip-RAM. And if Zorro-II DMA cannot get to the Chip-RAM, >then the processor probably cannot either. probably - you say it. btw, if you dma to fast-mem, is the processor able to access it at the same time? (i don't know this, please answer) >>> The new hardcard board with space >>> for 1 MEG SIMMS looks like a great idea. >> >> this is the absolut last idea one could have, because if >> you upgrade your amiga with a 020/030/0x0-board (having >> 32-bit mem) you have some slow memory hanging around and >> will never get rid of it. > >I think there are quite a few Amiga users around who are >happy with a 68000-based Amiga, a hard disk, and RAM. quite a few amiga users will be able to buy a 020-card in the future (they're getting cheaper and cheaper). >I won't comment on the other stuff. david r watters and >Michael van Elst did a perfect job on that. Thanks guys! sorry guys, my newsfeed broke down for 3 days, i didn't get them. are you able to mail the articles to me? >Ralph -- best regards, stephan von krawczynski UUCP : ...!cbmvax!cbmehq!cbmger!danube!thiger!skraw PHONE: +49 9938 1664 FAX : +49 9938 1598
skraw@thiger.UUCP (Stephan von Krawczynski) (08/21/90)
>In article <03259.AA03259@babylon.UUCP> rbabel@babylon.UUCP (Ralph Babel) writes: >In article <589@oregon.oacis.org> jmeissen@oregon.oacis.org >(John Meissen - Staff OACIS) writes: > >> Comments on SCSI implementation, > ><devices/scsidisk.h> 2/3 >(multiple LUNs, 2/3 >multiple boards, 3 >HD_-SCSICMD), 2/3 ><devices/hardblocks.h> 2/3 >(Rigid Disk Block standard, 2/3 >booting from FFS partition), 2/3 ><resources/filesysres.h> 2/3 >(automatic use of 2.0 filing system), 2/3 >full disconnect/reconnect, 2/3 >support for automatic DiskChange even with 1.3 FFS 2/3 >block sizes != 512, n/n not implemented yet, we'll see ... password-protection for each partition? >driver automatically executing out of 32-bit memory * >A-Max II (Macintosh emulator) support # 2 = ALF2 supports it (out over one year) 3 = ALF3 supports it (out yet) * the data-transfer code is put to fastest available mem and executed there (both ALF2 and ALF3 support this). the rest from rom, we couldn't find a difference, sorry, we could not. # i currently have no AMaxII. this is why i do not state anything here. if i have one i'll tell you. still no exact speed-statement. >> compatability issues (anybody got a tape drive or CD-ROM >> drive?), ALF2/ALF3 work at least with CALIPER/WANGTEK/TEAC-streamers (all tested myself). sony optical works, too. >Ralph -- best regards, stephan von krawczynski UUCP : ...!cbmvax!cbmehq!cbmger!danube!thiger!skraw PHONE: +49 9938 1664 FAX : +49 9938 1598
skraw@thiger.UUCP (Stephan von Krawczynski) (08/21/90)
>In article <552@DIALix.UUCP> bernie@DIALix.UUCP (Bernd Felsche) writes: >In article <02048.002057@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: >[previous ref deleted] > >DMA is an advantage because the CPU can be doing other (real >processing) things. the problem is: if dma-transfer from controller to fast-ram takes place, is the processor able to access this fast-ram at the same time? (may be implemented via splitting the totally available access-cycles) for if it is not, your processor will do ABSOLUTELY nothing, because it's cut off the bus (with exception of real weird programs that have the luck to be inside the instruction cache when dma starts and need no data from "outside"-world). >>i have never understood this one. what do they mean? 4MBytes/sec? >>i have never seen a controller/hd-combination reaching this. > >4MB/SEC is the peak transfer rate on most SCSI-2 controllers which >are not bound by arbitrary design constraints. Whether or not GVP >can get the data into the Amiga's RAM that quickly is another >matter. in fact, this is THE matter. what does it help if the data bursts in from your harddisk and the controller isn't able to put it to your mem (somehow). >At the Zorro II bus speed of about 3.5 MHz, this would 3.5 MHz? >consume more than 50% of the available bus time... although the time >to transfer will be a lot shorter than via polled (CPU) transfer. you have to take the bus-arbitration into consideration. >>4MBits/sec = 512kBytes/sec. seems to be more like the truth, but is an >>absolutely ridiculous value (ALF3 makes over 200kBytes/sec more in a >>standard amiga - NO processor-card installed) > >I know of controller/hd combinations which have _sustained_ >throughput rates of over 2MB/sec (not Amigas, workstations), with we're talking of amigas and amiga-hd-controllers here. of course there ARE other computers reaching it. >By designing for 4MB/sec, GVP is doing the right thing, do they really do that? they don't reach it, and as long as they do not, how can you say? >because the >bottleneck is the hard disk (at the moment). that's right. >You can also connect >more than one drive without "choking" on the bus, especially during >overlapping seeks and transfers. what do you want to say here, i don't understand this. >Another consideration is the speed of the filesystem. AmigaDOS >isn't exactly renowned for filesystem performance, even with FFS. i know this. >It involves significant CPU cycles to convert the raw SCSI data into >something which DOS presents to the user (FFS is a _lot_ better than >the original FS). sorry, this is wrong. ffs doesn't convert ANY data (<-DATA). in fact, it doesn't handle with the data at all (normally). this is one major reason why ffs is quite a bit faster than ofs (which has to copy the data). >When you measure the average transfer speed, the >filesystem (and trackdisk.device) get in the way and give you a >distorted view of what the hardware _can_ do under ideal >conditions. 1. i do not measure a controllers performance via filesystem. there are tests (i use speedtest, comes with all ALF-controllers) that measure the real device-/controller-performance ((read-)throughput). 2. how do you get to trackdisk.device? has absolutely nothing to do with harddisk. >bernie -- best regards, stephan von krawczynski UUCP : ...!cbmvax!cbmehq!cbmger!danube!thiger!skraw PHONE: +49 9938 1664 FAX : +49 9938 1598
jmeissen@oregon.oacis.org (John Meissen - Staff OACIS) (08/23/90)
In the latest AmigaWorld GVP is offering a trade-in program for their new "Series II" SCSI and RAM controllers. FYI, the offer is basically trade in any SCSI controller and get the new GVP controller for $109 or the SCSI+RAM controller for $148 (an additional $10 off if you trade in one of Commodore's) . It sounds like a good deal, but the terms of the offer (send in your current controller + certified check) make it sound difficult, if not impossible, to go back (not to mention I would be without a system until the new controller arrived). Thus I would like to feel comfortable about it before tearing my system apart again. I currrently have the Commodore A2090, and have been resigned to the inevitable prospect of upgrading in the future anyway. However, before I get into something like this, I would like to have some opinions about GVP and their products. A few specific questions would be: is this a good deal? What would these boards cost normally? True DMA (ala the A2090) is VERY important to me. GVP claims this board is. Anybody have one that can comment? Comments on SCSI implementation, compatability issues (anybody got a tape drive or CD-ROM drive?), customer support.... Comments about why a different controller might be prefered would also be appreciated. John Meissen .............................. Oregon Advanced Computing Institute jmeissen@oacis.org (Internet) | "That's the remarkable thing about life; ..!sequent!oacis!jmeissen (UUCP) | things are never so bad that they can't jmeissen (BIX) | get worse." - Calvin & Hobbes
liberato@dri.com (Jimmy Liberato) (08/24/90)
jmeissen@oregon.oacis.org (John Meissen - Staff OACIS) writes: >In the latest AmigaWorld GVP is offering a trade-in program for their >new "Series II" SCSI and RAM controllers.. >... >A few specific questions would be: > > True DMA (ala the A2090) is VERY important to me. GVP claims > this board is. Anybody have one that can comment? Actually, if you read VERY carefully they do not claim "true DMA." They say something like "DMA to on board ram." The more acceptable and accurate term would be "pseudo-DMA" but because pseudo has bad connotations they prefer to emphasize the buzz word DMA realizing that 90% of us won't know what it means anyway. It still bugs me that such a reputable company with a fine product in its own right would stoop to practices with clear fraudulent intent. As to whether it is a good deal or not: The ROM upgrade for the old GVP boards is around $50. The new hardcard board with space for 1 MEG SIMMS looks like a great idea. I would do it if I could convince them to sell me the board first and then give me credit upon receipt of my tradein. I find it impossible to get past their voice mail system and have yet to have anyone call me back. I would never consider sending the controller first and then have to wait a month for the board. It is unlikely the new board is even shipping yet. (This last comment has no factual basis) -- Jimmy Liberato liberat@dri.com ...uunet!drivax!liberato
skraw@thiger.UUCP (Stephan von Krawczynski) (08/25/90)
>In article <38CP09P@dri.com> liberato@dri.com (Jimmy Liberato) writes: >jmeissen@oregon.oacis.org (John Meissen - Staff OACIS) writes: > > >>In the latest AmigaWorld GVP is offering a trade-in program for their >>new "Series II" SCSI and RAM controllers.. >>... >>A few specific questions would be: >> >> True DMA (ala the A2090) is VERY important to me. GVP claims >> this board is. Anybody have one that can comment? 1. GVP does not DMA to amiga-memory. 2. why is DMA so important for you? it is generally slower than the processor-method (lets call it this way). you win nothing because you have a whole lot of DMA going on already inside the system and processor's running into heavy troubles sometimes, e.g. harddisk-performance is very low while using overscan-graphics (just to mention an example). >Actually, if you read VERY carefully they do not claim "true DMA." >They say something like "DMA to on board ram." The more acceptable >and accurate term would be "pseudo-DMA" but because pseudo has bad >connotations they prefer to emphasize the buzz word DMA realizing >that 90% of us won't know what it means anyway. It still bugs me >that such a reputable company with a fine product in its own right >would stoop to practices with clear fraudulent intent. well, how about "transfer rates up to 4MB/SEC synchronous" (gvp). in fact i have never understood this one. what do they mean? 4MBytes/sec? i have never seen a controller/hd-combination reaching this. 4MBits/sec = 512kBytes/sec. seems to be more like the truth, but is an absolutely ridiculous value (ALF3 makes over 200kBytes/sec more in a standard amiga - NO processor-card installed) i think it's a reputable company, what do you think? >As to whether it is a good deal or not: The ROM upgrade for the >old GVP boards is around $50. remember this, you pay $50 more for your controller effectively. >The new hardcard board with space >for 1 MEG SIMMS looks like a great idea. this is the absolut last idea one could have, because if you upgrade your amiga with a 020/030/0x0-board (having 32-bit mem) you have some slow memory hanging around and will never get rid of it. if you disable it, why did you buy it, then? no good idea for me. on the other hand, if you have a separate memory-board, you are always able to sell it again. of course you won't get the full price you payed, but you will get SOMETHING, whereas otherwise ... >I >would never consider sending the controller first and then have >to wait a month for the board. It is unlikely the new board is >even shipping yet. (This last comment has no factual basis) i have never seen an acceptable trade-in for hardware-products. has anyone? >Jimmy Liberato liberat@dri.com -- best regards, stephan von krawczynski UUCP : ...!cbmvax!cbmehq!cbmger!danube!thiger!skraw PHONE: +49 9938 1664 FAX : +49 9938 1598
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (08/26/90)
In <02048.002057@thiger.UUCP>, skraw@thiger.UUCP (Stephan von Krawczynski) writes: >2. why is DMA so important for you? it is generally slower than the >processor-method (lets call it this way). you win nothing because you >have a whole lot of DMA going on already inside the system and processor's >running into heavy troubles sometimes, e.g. harddisk-performance is >very low while using overscan-graphics (just to mention an example). You are completely wrong in this. Not only is DMA faster, but it frees up the processor for other things. Do not confuse one particular implementation of a DMA controller, which did have a significant problem under heavy DMA conditions, for the entire spectrum of controllers. >well, how about "transfer rates up to 4MB/SEC synchronous" (gvp). in fact >i have never understood this one. what do they mean? 4MBytes/sec? No. they mean 4 MBytes per second, and that is indeed realistic. Of course you have to realize that they are not taking about sustained troughput, but about the actual data transfer rate as seen on the SCSI bus, from a Controller to Host Adapter. >i have never seen a controller/hd-combination reaching this. Several do it all the time. Note the difference between SCSI bus transfer rates and disk to destination throughput. >4MBits/sec = 512kBytes/sec. seems to be more like the truth, but is an >absolutely ridiculous value (ALF3 makes over 200kBytes/sec more in a >standard amiga - NO processor-card installed) >i think it's a reputable company, what do you think? Reputable probably. Slow, definitely. -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (08/26/90)
In article <02048.002057@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: >2. why is DMA so important for you? it is generally slower than the >processor-method (lets call it this way). you win nothing because you >have a whole lot of DMA going on already inside the system and processor's >running into heavy troubles sometimes, e.g. harddisk-performance is >very low while using overscan-graphics (just to mention an example). Now, true DMA can be faster than the processor. The limiting factor is _bandwidth_ and a DMA device can move a word at each cycle whereas the processor needs at least two cycles (fetch and store). The problem is that DMA has to be granted by the processor and if the processor waits during a chip memory access DMA cannot start. But, the same situation arises when fetching data with the processor. You cannot task switch or service an interrupt while waiting for chip memory access. Now why are current DMA-controllers slower ? In fact it's a software question. Does the driver read-aheads, does it limit chip memory accesses during a transfer ? >well, how about "transfer rates up to 4MB/SEC synchronous" (gvp). in fact >i have never understood this one. what do they mean? 4MBytes/sec? >i have never seen a controller/hd-combination reaching this. >4MBits/sec = 512kBytes/sec. seems to be more like the truth, but is an >absolutely ridiculous value (ALF3 makes over 200kBytes/sec more in a >standard amiga - NO processor-card installed) If you know about SCSI (and I think you do) then you can see that 4MB/sec is the data transfer rate on the SCSI bus that can be reached with the controller hardware. Real-world transfers are more limited by the drive. Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
watters@ironwood.cis.ohio-state.edu (david r watters) (08/27/90)
In article <02048.002057@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: >1. GVP does not DMA to amiga-memory. >2. why is DMA so important for you? it is generally slower than the >processor-method (lets call it this way). you win nothing because you >have a whole lot of DMA going on already inside the system and processor's >running into heavy troubles sometimes, e.g. harddisk-performance is >very low while using overscan-graphics (just to mention an example). My roomate and I have two identical machines sitting side by side except he has a processor card and I have the A2091 which is DMA. We both do A LOT of animation rendering and tracing with a home built raytracer so we both have accelerated machines. Although he doesn't have the fastest processor card, his r/w speeds are right along with mine. However, when we start tracing an animation (even in severe overscan) the 2091 has a major advantage due to it's improved DMA handling over the 2090 and since his card is competting with the the tracer as it saves and renders. This is even more pronounced with Turbo-Silver which saves continuously as it renders the images.
rbabel@babylon.UUCP (Ralph Babel) (08/27/90)
In article <589@oregon.oacis.org> jmeissen@oregon.oacis.org (John Meissen - Staff OACIS) writes: > (an additional $10 off if you trade in one of Commodore's) Or one of GVP's controllers. > What would these boards cost normally? Suggested retail: US-$199 (SCSI-only hard card), US-$249 (SCSI hard card w/ 8 MB RAM option). > True DMA (ala the A2090) is VERY important to me. GVP > claims this board is. Anybody have one that can comment? I have one in my A2000 (rev 4.1) I'm typing this article on. It's true 16-bit DMA anywhere in the Zorro-II address space. (Well, my driver doesn't transfer any data, so I must assume it's either DMA or magic :-) > Comments on SCSI implementation, <devices/scsidisk.h> (multiple LUNs, multiple boards, HD_- SCSICMD), <devices/hardblocks.h> (Rigid Disk Block standard, booting from FFS partition), <resources/filesysres.h> (auto- matic use of 2.0 filing system), full disconnect/reconnect, support for automatic DiskChange even with 1.3 FFS (e.g. SyQuest, Bernoulli, those new Ricoh drives), block sizes != 512, driver automatically executing out of 32-bit memory (if present), A-Max II (Macintosh emulator) support. > compatability issues (anybody got a tape drive or CD-ROM > drive?), I'm using a WangTek streamer and a NEC CD-ROM drive, I know of others using Ricoh optical disk drives and Sony WORMs. > customer support.... Can't comment. ;-) In article <38CP09P@dri.com> liberato@dri.com (Jimmy Liberato) writes: > Actually, if you read VERY carefully they do not claim > "true DMA." They say something like "DMA to on board ram." John was talking about the _new_ Series-II ad, and as I already said: It's 100% real true DMA to the entire 16-meg address space. And it's even faster when DMAing to the on-board expansion memory (no Zorro-II bus arbitration required). The _old_ Series-I GVP controllers did DMA to a local on-board RAM buffer (that's what you called "pseudo-DMA"). > As to whether it is a good deal or not: The ROM upgrade > for the old GVP boards is around $50. I'd say it's worth it (don't forget: I'm biased)! But with true DMA, you'll get even better performance on the new controllers, of course. > I would do it if I could convince them to sell me the > board first and then give me credit upon receipt of my > tradein. Call sales, it might be worth a try. > I find it impossible to get past their voice mail system > and have yet to have anyone call me back. Try (215) 337-8770 from 9 AM to 5 PM EST. Fax (215) 337-9922 > I would never consider sending the controller first and > then have to wait a month for the board. From what I've read on the comp.sys.amiga.* groups, most people say that they received their shipments within a few days, but I can't really confirm or deny something like that, so maybe somebody else can comment. > It is unlikely the new board is even shipping yet. Absolutely not true! It was shipping even before the September issue of AmigaWorld was published! > (This last comment has no factual basis) Reminds me of: "This statement is false." :-) Ralph ...!cbmvax!cbmehq!babylon!rbabel
rbabel@babylon.UUCP (Ralph Babel) (08/27/90)
In article <02048.002057@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: > 1. GVP does not DMA to amiga-memory. Not true, GVP does full DMA! This guy doesn't know what he's talking about - a very bad habit when you're talking about a competitor's product. See my earlier articles for details. > 2. why is DMA so important for you? it is generally slower > than the processor-method (lets call it this way). Careful ... > you win nothing because you have a whole lot of DMA going > on already inside the system and processor's running into > heavy troubles sometimes, e.g. harddisk-performance is > very low while using overscan-graphics (just to mention an > example). "PROCESSOR's running into heavy troubles"? Freudian slip? DMA to real Fast-RAM should not be affected by the DMA-load on Chip-RAM. And if Zorro-II DMA cannot get to the Chip-RAM, then the processor probably cannot either. >> The new hardcard board with space >> for 1 MEG SIMMS looks like a great idea. > > this is the absolut last idea one could have, because if > you upgrade your amiga with a 020/030/0x0-board (having > 32-bit mem) you have some slow memory hanging around and > will never get rid of it. I think there are quite a few Amiga users around who are happy with a 68000-based Amiga, a hard disk, and RAM. I won't comment on the other stuff. david r watters and Michael van Elst did a perfect job on that. Thanks guys! Ralph
bernie@DIALix.UUCP (Bernd Felsche) (08/28/90)
In article <02048.002057@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: [previous ref deleted] >1. GVP does not DMA to amiga-memory. >2. why is DMA so important for you? it is generally slower than the >processor-method (lets call it this way). you win nothing because you >have a whole lot of DMA going on already inside the system and processor's >running into heavy troubles sometimes, e.g. harddisk-performance is >very low while using overscan-graphics (just to mention an example). DMA is an advantage because the CPU can be doing other (real processing) things. DMA hardware is designed to do one thing... move data from one bit of RAM to another. Just like other custom hardware, it frees up the CPU for general prupose number crunching, allowing greater throughput and better response in a multi-tasking environment. > [other ref deleted] > >well, how about "transfer rates up to 4MB/SEC synchronous" (gvp). in fact >i have never understood this one. what do they mean? 4MBytes/sec? >i have never seen a controller/hd-combination reaching this. 4MB/SEC is the peak transfer rate on most SCSI-2 controllers which are not bound by arbitrary design constraints. Whether or not GVP can get the data into the Amiga's RAM that quickly is another matter. At the Zorro II bus speed of about 3.5 MHz, this would consume more than 50% of the available bus time... although the time to transfer will be a lot shorter than via polled (CPU) transfer. >4MBits/sec = 512kBytes/sec. seems to be more like the truth, but is an >absolutely ridiculous value (ALF3 makes over 200kBytes/sec more in a >standard amiga - NO processor-card installed) I know of controller/hd combinations which have _sustained_ throughput rates of over 2MB/sec (not Amigas, workstations), with the hard disk able to provide up to 2.8MB/sec in bursts. By designing for 4MB/sec, GVP is doing the right thing, because the bottleneck is the hard disk (at the moment). You can also connect more than one drive without "choking" on the bus, especially during overlapping seeks and transfers. Another consideration is the speed of the filesystem. AmigaDOS isn't exactly renowned for filesystem performance, even with FFS. It involves significant CPU cycles to convert the raw SCSI data into something which DOS presents to the user (FFS is a _lot_ better than the original FS). When you measure the average transfer speed, the filesystem (and trackdisk.device) get in the way and give you a distorted view of what the hardware _can_ do under ideal conditions. I didn't intend this article to become a comp.arch dissertation, so I won't go any deeper into the subject at this stage. bernie (Real computers have flashing lights, front panel switches, 8K RAM and hard-sectored floppies - anybody recognize this?)
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (08/29/90)
In <552@DIALix.UUCP>, bernie@DIALix.UUCP (Bernd Felsche) writes: > >Another consideration is the speed of the filesystem. AmigaDOS >isn't exactly renowned for filesystem performance, even with FFS. >It involves significant CPU cycles to convert the raw SCSI data into >something which DOS presents to the user (FFS is a _lot_ better than >the original FS). When you measure the average transfer speed, the >filesystem (and trackdisk.device) get in the way and give you a >distorted view of what the hardware _can_ do under ideal >conditions. Whoops! You were doing just fine right up to this point. Under FFS, there is no need to massage any data. The FS issues the read, and the 'raw SCSI data' is brought in, left as is, and put into the destination memory. With DMA, it gets there without the processor having to do it, and in any case, the data is the same as when it came over the SCSI bus. Under OFS, the data had to be placed in a buffer in order to strip out the Amigados overhead present in every sector, and then sent to its destination, so your statement is true for OFS. If you count relocation and scatter loading to be 'file system overhead' (which I don't, then your statement is also true for any file system capable of storing programs. -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jesup@cbmvax.commodore.com (Randell Jesup) (08/30/90)
In article <552@DIALix.UUCP> bernie@DIALix.oz.au (Bernd Felsche) writes: >Another consideration is the speed of the filesystem. AmigaDOS >isn't exactly renowned for filesystem performance, even with FFS. >It involves significant CPU cycles to convert the raw SCSI data into >something which DOS presents to the user (FFS is a _lot_ better than >the original FS). When you measure the average transfer speed, the >filesystem (and trackdisk.device) get in the way and give you a >distorted view of what the hardware _can_ do under ideal >conditions. Actually, it does far better at things like that than say, Unix, does. There's been quite a bit of discussion at times in comp.arch about filesystem speeds, and even a 68000 amiga with a DMA controller can keep up there with pretty high-power Unix boxes. One of the reasons is that FFS allows us to do direct transfers to the end destination, instead of having to xfer to a buffer pool and then cpu copy to destination (like most unix implementations). If you want to see what they can do, check out floppies under 2.0 trackdisk and FFS. I've seen >20K/sec reads. Note that the theoretical maximum is ~24K/sec, not including seek and settle times or any other overhead. Trackdisk does 22K/sec via the device interface (including seek/settle) under 2.0. Even on a 68000, sustained transfer speed is limited by disk speed in most cases, not processor handling of the data. A 680{2,3}0 will improve rates, but not immensely. Unix FS's are faster at some things, like reading directories (assuming the directories aren't too large - for large directories, AmigaDos is faster at finding a file). However, FFS is no slouch at this. My directory listings are scroll speed limited. >bernie >(Real computers have flashing lights, front panel switches, 8K RAM and >hard-sectored floppies - anybody recognize this?) Yes, except that's randomly-accessible tape drives, none of those new-fangled disk things. To boot them, you have to toggle in a boot module in octal and run it. Also, they have 12-bit words. ;-) -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
borgen@sfd.uit.no (Boerge Noest) (08/30/90)
In article <14069@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: >trackdisk and FFS. I've seen >20K/sec reads. Note that the theoretical >maximum is ~24K/sec, not including seek and settle times or any other overhead. So where does the available bandwith go? I mean, looking in the HW-ref.man there is three cycles for disk-DMA every scanline (4 for audio), which makes me believe there is 3*28k = 84k/s theoretical transfer speed(after MFM that should be 42k/s), but disks spin 5 tracks/s = ~12k*5 = 60k. Can you get the extra k/s buy using custom loaders and slow-speed saving your data(to get longer tracks)? >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. -- |//// ______________ don't use R/r(eply)! *mail* me ______________ \\\\| |/// borgen@stud.cs.uit.no (Borge Nost) \\\| |// ...and then there was AMIGA... \\| |/ studying at the worlds northernmost university \|
rbabel@babylon.UUCP (Ralph Babel) (08/30/90)
In article <02102.123056@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: >> You are completely wrong in this. Not only is DMA faster,[...] > > right, but bus-arbitration breaks it completely up. Even if this was true (which it isn't): DMA to GVP's onboard expansion memory doesn't require bus-arbitration. > i have seen no dma-controller yet, that didn't have problems. Try GVP's. In article <02109.124951@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: >>> 1. GVP does not DMA to amiga-memory. >> >> Not true, GVP does full DMA! > > which gvp? Aren't we talking about GVP's latest ad? > in fact, we both know that the processor cannot run into > problems having about half of the DMA-cycles (to chipmem) > available in the system. DMAF_BLITHOG? > btw, if you dma to fast-mem, is the processor able to > access it at the same time? As far as I know, DMA - once it has the bus - is able to lock out the processor for as long as it wishes to. In article <02116.135633@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: > password-protection for each partition? Design decision, I don't consider this important. It's a matter of taste - you won't implement other features. >> driver automatically executing out of 32-bit memory > > the rest from rom, we couldn't find a difference, sorry, > we could not. Did you ever run "PerfMon" during "DiskPerf"? > 3 = ALF3 supports it (out yet) You forgot to tell them about the price for this board: 795 German Marks for the bare SCSI controller, no memory expansion option. At the current exchange-rate, that's about twice as much as you would pay for GVP's board. Best regards, Ralph "Any argument carried far enough will end up in semantics."
jmpor@dynam.UUCP (J-M Porchet) (08/31/90)
>In article <02109.124951@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: >>In article <03283.AA03283@babylon.UUCP> rbabel@babylon.UUCP (Ralph Babel) writes: >>In article <02048.002057@thiger.UUCP> skraw@thiger.UUCP >>(Stephan von Krawczynski) writes: >> >>> 1. GVP does not DMA to amiga-memory. >> >>Not true, GVP does full DMA! > >which gvp? do you know what brings me down? i did try to get a >new gvp-controller. in fact i did only reach a production-date of >may 1990. and this controller had HEAVY problems with sony-opticals >(in fact we couldn't get them working though we tried hard). > >>This guy doesn't know what he's talking about - a very bad >>habit when you're talking about a competitor's product. See >>my earlier articles for details. > >possibly i didn't get them (would you mail them to me?) > >>> 2. why is DMA so important for you? it is generally slower >>> than the processor-method (lets call it this way). >> >>Careful ... > >as long as i don't see any controller being faster than ALF3 ... > That's not true, for examples the KRONOS controller with a good HD (siemens megafile 300 MB )can sustain a transfer of over 1 MBYTE/s and it is even more faster with a 020 or 030. personally, I use the kronos with two seagate 157N and with a 50 MHZ 030 from GVP and the controller sustain a rate of 800 KB/S (not very much but the 157N is very very slow). >>"PROCESSOR's running into heavy troubles"? Freudian slip? > >see other posting. in fact, we both know that the processor >cannot run into problems having about half of the DMA-cycles >(to chipmem) available in the system. > >>DMA to real Fast-RAM should not be affected by the DMA-load >>on Chip-RAM. And if Zorro-II DMA cannot get to the Chip-RAM, >>then the processor probably cannot either. > >probably - you say it. >btw, if you dma to fast-mem, is the processor able to access >it at the same time? (i don't know this, please answer) > >>>> The new hardcard board with space >>>> for 1 MEG SIMMS looks like a great idea. >>> >>> this is the absolut last idea one could have, because if >>> you upgrade your amiga with a 020/030/0x0-board (having >>> 32-bit mem) you have some slow memory hanging around and >>> will never get rid of it. >> >>I think there are quite a few Amiga users around who are >>happy with a 68000-based Amiga, a hard disk, and RAM. > >quite a few amiga users will be able to buy a 020-card in >the future (they're getting cheaper and cheaper). > >>I won't comment on the other stuff. david r watters and >>Michael van Elst did a perfect job on that. Thanks guys! > >sorry guys, my newsfeed broke down for 3 days, i didn't >get them. are you able to mail the articles to me? > >>Ralph > >-- >best regards, >stephan von krawczynski > >UUCP : ...!cbmvax!cbmehq!cbmger!danube!thiger!skraw >PHONE: +49 9938 1664 >FAX : +49 9938 1598 -- best regards, ------------------------------------------------------------------------------ Jean-Marc PORCHET 301, Mandement street Organisation : DYNAMIC COMPUTER (ECC 005) CH-1281 Russin SWITZERLAND UUCP: cbmswi!dynam!jmpor ------------------------------------------------------------------------------
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (09/01/90)
In article <02102.123056@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: >>You are completely wrong in this. Not only is DMA faster,[...] >right, but bus-arbitration breaks it completely up. Only if you try to arbitrate for each cycle. When you're using larger transfers then the arbitration isn't important. >i know this. but tell me: is it really interesting for the customer to hear >somthing about the scsi-bus-transferrate. especially if the controller-to- >amigamem troughput brings the thing down to some 100 kBytes (a typical >bottle-neck). let's talk about the real throughput, not some >part of the story. Well, how interesting it is in a discussion where someone experienced states that SCSI can't run with 4MB/sec. The controller<->amigamem bottleneck is about 3.5 MB/sec, not far away from the limits of this SCSI controller (SCSI arbitration and command overhead might degrade usable bandwidth to less than amiga bus speed). Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
jmeissen@ogicse.ogi.edu (John Meissen) (09/01/90)
In article <02123.132132@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: >>DMA is an advantage because the CPU can be doing other (real >>processing) things. > >the problem is: if dma-transfer from controller to fast-ram takes place, >is the processor able to access this fast-ram at the same time? >(may be implemented via splitting the totally available access-cycles) >for if it is not, your processor will do ABSOLUTELY nothing, because >it's cut off the bus (with exception of real weird programs that have >the luck to be inside the instruction cache when dma starts and >need no data from "outside"-world). The other side of the coin is that when doing DMA, it doesn't matter if the processor is cut off from the bus and incapable of doing anything else. The simple fact of the matter is, if you DIDN'T have the DMA, then the processor would be tied up doing the transfer and STILL wouldn't be able to do anything else. And in a comparison of DMA vs CPU transfer of data, the DMA is much faster; thus the CPU will be prevented from doing usefule work for a much shorter period of time. Either way you win with DMA. >>You can also connect >>more than one drive without "choking" on the bus, especially during >>overlapping seeks and transfers. > >what do you want to say here, i don't understand this. If you have data transfer operations going on multiple drives simultaneously, a properly designed DMA controller will be able to interleave the operations, effectively allowing them to run at the same time. A processor-based scheme can only handle one operation at a time. -- John Meissen .............................. Oregon Advanced Computing Institute jmeissen@oacis.org (Internet) | "That's the remarkable thing about life; ..!sequent!oacis!jmeissen (UUCP) | things are never so bad that they can't jmeissen (BIX) | get worse." - Calvin & Hobbes
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (09/01/90)
In article <1990Aug30.121102.11096@hod.uit.no> borgen@stud.cs.uit.no writes: >So where does the available bandwith go? I mean, looking in the HW-ref.man >there is three cycles for disk-DMA every scanline (4 for audio), which >makes me believe there is 3*28k = 84k/s theoretical transfer speed(after >MFM that should be 42k/s), but disks spin 5 tracks/s = ~12k*5 = 60k. Well, 5 revolutions per second, 5.5k per track --> 27.5k/second. To handle arbitrary start points, you'll need to read an additional sector per revolution, this reduces the (user-)data rate to about 25.2k/second. Scanline frequency is about 15.7KHz. If there are three free slots per scanline, you can transfer 3*15.7K words per second -> 94.2Kb/sec. MFM data comes with 500Kbit/sec == 62.5KB/sec. Therefore the disk-DMA does not use every slot but if only two slots were available you would need extra buffers and a slow genlock signal might induce disk-DMA failures. Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
rbabel@babylon.UUCP (Ralph Babel) (09/01/90)
To DMA or not to DMA ... In article <02123.132132@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: > the problem is: if dma-transfer from controller to > fast-ram takes place, is the processor able to access this > fast-ram at the same time? As I said before: During DMA to the on-board RAM, the GVP controller does not block the Zorro-II bus. > for if it is not, your processor will do ABSOLUTELY > nothing, because it's cut off the bus (with exception of > real weird programs that have the luck to be inside the > instruction cache when dma starts and need no data from > "outside"-world). Zorro-II bus arbitration is faster than task-switching. > what does it help if the data bursts in from your harddisk > and the controller isn't able to put it to your mem > (somehow). Let's do some math: If a controller doing programmed I/O can access the data port on consecutive addresses, then the fastest way to transfer data is: READ: MOVE.L (Ax),(Ay)+ ;20 cycles WRITE: MOVEM.L (Ay)+,REGLIST ;12+8n cycles MOVEM.L REGLIST,(Ax) ; 8+8n cycles Usually you cannot use MOVEM for reads because the MC680x0 does a one-word prefetch (memory to register) which would kill a data word (you _could_ fix that in hardware). You can use at most 14 registers for the MOVEM, since you need a source register and you probably want to keep your stack pointer. On a 7-MHz 68000 (e.g. Standard-Amiga), this results in maximum transfer rates of ... 1.4 MB per second for READ ( 20 cycles for 4 bytes) 1.6 MB per second for WRITE (244 cycles for 56 bytes) ... NOT COUNTING _ANY_ OVERHEAD! BTW: The german ALF3-ad claims "up to 2 MB per second". >> At the Zorro II bus speed of about 3.5 MHz, this would > > 3.5 MHz? Let's call it the "byte frequency" (at 4 cycles per word). > you have to take the bus-arbitration into consideration. A clever DMA controller doesn't arbitrate for and release the bus on each and every 16-bit word. >> You can also connect more than one drive without "choking" >> on the bus, especially during overlapping seeks and >> transfers. > > what do you want to say here, i don't understand this. Fast and short bursts keep the SCSI bus available for other devices (DISCONNECT). > i do not measure a controllers performance via filesystem. > there are tests (i use speedtest, comes with all > ALF-controllers) that measure the real > device-/controller-performance ((read-)throughput). Wasn't it you who insisted on "real-world" performance measurements. "DiskPerf" (DOS-level) is much closer to that! Ralph cbmvax.commodore.com!cbmehq!babylon!rbabel "If you keep your mind sufficiently open, people will throw a lot of rubbish into it."
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/01/90)
In <jmpor.3196@dynam.UUCP>, jmpor@dynam.UUCP (J-M Porchet) writes: >That's not true, for examples the KRONOS controller with a good HD >(siemens megafile 300 MB )can sustain a transfer of over 1 MBYTE/s >and it is even more faster with a 020 or 030. > >personally, I use the kronos with two seagate 157N and with a >50 MHZ 030 from GVP and the controller sustain a rate of 800 KB/S >(not very much but the 157N is very very slow). Giving a transfer rate is meaningless unless you specify (a) What you are measuring. (b) What you are measuring it with. I get particularly suspicious when people quote speeds of the Kronos controller without stating the program used for measurement. This is due to the former head of C Ltd., being such a rabid purveyor of misinformation and hype, that he felt it necessary to commission a program that measures the raw speed of the drive, ie. raw reads using the device driver directly, in an attempt to match the figures of the more common measurement programs. While the Kronos is remarkable for a non-DMA controller, it still falls short in the area of best usage of the CPU and system resources, and does not measure up well when using a program that truly measures efficiency, such as DiskSpeed. -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (09/01/90)
In article <02109.124951@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: >which gvp? do you know what brings me down? i did try to get a >new gvp-controller. in fact i did only reach a production-date of >may 1990. and this controller had HEAVY problems with sony-opticals >(in fact we couldn't get them working though we tried hard). That might be a software problem (all this MODE_SELECT nuisance). The Sony-MODs are working very like standard harddrives and didn't show any problems (not with an Amiga but with our DECstations and SUNs). >as long as i don't see any controller being faster than ALF3 ... The speed of the controller hardware does not show up in data transfer figures used in advertisments, at least if you compare those of single drive operations on an otherwise unloaded system. The major performance hits in the "several 100KB/s" range comes from wrong trackskews or annoying read-ahead schemes and that's a question of the drives firmware (although a clever driver can compensate for this). >see other posting. in fact, we both know that the processor >cannot run into problems having about half of the DMA-cycles >(to chipmem) available in the system. Hu ? Chip memory DMA is a lot different to Zorro-II DMA. With a controller board in a Zorro slot you have to use the same bus cycles as the 68000. >btw, if you dma to fast-mem, is the processor able to access >it at the same time? (i don't know this, please answer) Well, of course the bus can be used only for a single operation at the same time. On the other side you don't need the full bandwidth for a regular program esp. when using a CPU with a cache. This leaves many cycles free that can be used for disk DMA. This isn't enough for maximum load of the SCSI bus but regular disk transfers won't actually stop the cpu. And DMA takes at least half the bandwidth used by a processor routine. Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (09/01/90)
In article <02123.132132@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: >the problem is: if dma-transfer from controller to fast-ram takes place, >is the processor able to access this fast-ram at the same time? >(may be implemented via splitting the totally available access-cycles) >for if it is not, your processor will do ABSOLUTELY nothing, because >it's cut off the bus (with exception of real weird programs that have >the luck to be inside the instruction cache when dma starts and >need no data from "outside"-world). That's not completely correct. Neither CPU nor DMA use the full bandwidth of the system bus. They can share the available bandwidth so that a data transfer of 700k/s will degrade CPU peformance by only 20%. >>At the Zorro II bus speed of about 3.5 MHz, this would >3.5 MHz? 3.5 MB/sec ! >you have to take the bus-arbitration into consideration. If you're doing short bursts (say 16 words at once), you won't notice bus arbitration. >>You can also connect >>more than one drive without "choking" on the bus, especially during >>overlapping seeks and transfers. >what do you want to say here, i don't understand this. If the SCSI bandwidth would be about 800Kb/sec you could manage the data transfer of one disk with 800Kb/sec. If you have two disks of those you can get 400Kb/sec from either. Now, since the bus is faster you can multiplex the bus between the drives and get 800Kb/sec from both thus moving 1.6MB/sec. >1. i do not measure a controllers performance via filesystem. there >are tests (i use speedtest, comes with all ALF-controllers) that >measure the real device-/controller-performance ((read-)throughput). Well, you might miss the real-world experiences then. My (OMTI-) controller gets about 330K/sec from an RLL drive when using speedtest. But then file system operations are using relatively small block sizes so that I don't get anything near that except for loading single chunk executables. You have to do something intelligent to get reasonable speeds for regular operations besides improving the raw data transfer rate. Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (09/01/90)
In article <11853@ogicse.ogi.edu> jmeissen@ogicse.ogi.edu (John Meissen) writes: >If you have data transfer operations going on multiple drives >simultaneously, a properly designed DMA controller will be able to >interleave the operations, effectively allowing them to run at the >same time. A processor-based scheme can only handle one operation >at a time. I don't think that. You can multiplex the bus either with DMA or with a processor transfer routine although DMA would be faster. Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
mrush@csuchico.edu (Matt "C P." Rush) (09/04/90)
In article <14069@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: >In article <552@DIALix.UUCP> bernie@DIALix.oz.au (Bernd Felsche) writes: > >>(Real computers have flashing lights, front panel switches, 8K RAM and >>hard-sectored floppies - anybody recognize this?) > > Yes, except that's randomly-accessible tape drives, none of those >new-fangled disk things. To boot them, you have to toggle in a boot >module in octal and run it. Also, they have 12-bit words. ;-) Gee, you have randomly-accessible tape? How did you get the machine to automatically rewind the paper tape? :-) -- Matt *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* % % mrush@csuchico.edu % % Long live the UNIVAC 1230mtc! % mrush@cscihp.UUCP % % % % Now: mrush@cscihp.ecst.csuchico.edu % *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* This is a SCHOOL! Do you think they even CARE about MY opinions?!
daveh@cbmvax.commodore.com (Dave Haynie) (09/05/90)
In article <02048.002057@thiger.UUCP> skraw@thiger.UUCP (Stephan von Krawczynski) writes: >>> True DMA (ala the A2090) is VERY important to me. GVP claims >>> this board is. Anybody have one that can comment? >1. GVP does not DMA to amiga-memory. That's ture, at least with the original GVP board. I don't know the details of the new one. >2. why is DMA so important for you? it is generally slower than the >processor-method (lets call it this way). That's ABSOLUTELY INCORRECT. But sometimes a misconception amoung the uninformed. You have to understand the problem you're trying to solve to get a true picture of what's happening. And that problem is, how can you efficiently transfer data from the SCSI chip into system memory. The simplest approach would, of course, be to have the CPU wait on the SCSI chip and copy over every single byte as it's available. This is basically what the pre-IIfx Macintoshes all do; they pretend the SCSI chip is slow, 8-bit wide memory, and wait for each byte to become available in a tight CPU copy loop. This is a loosing proposition from the start, however. The most common form of SCSI transfer, asynchronous SCSI, runs at up to 1.5 MB/s (Megabytes per second). Your A2000 bus runs at about 3.5 MB/s. If you run it at only 8 bits/transfer, that's cut down to 1.75 MB/s. However, using the CPU to do the copying, at best, you need two byte reads and one word write to get a word from SCSI chip into memory. That's a maximum speed of 1.17 MB/s for the transfer (neglecting any overhead from the transfer loop, which will be non-zero), and during that transfer, the CPU gets to do NOTHING but copy the data from the SCSI chip. This can't even keep up with SCSI, so we throw it out for anything but the cheapest controllers (the original TrumpCard and the original C Ltd controllers worked this way). The next approach would be to funnel two SCSI bytes into one word and do the same wait-copy approach. This would yield a maximum transfer rate of 1.75 MB/s, which will keep up with asynchronous SCSI at its fastest. However, this wait-copy approach has severe drawbacks. It gets the data into memory extremely fast, since nothing but the copy can happen until the data is in memory. But you may actually be WAITING for the data from the SCSI drive, for seeks or other times at which you're not getting it in at full speed. This kind of scheme may APPEAR to be the fastest transfer, since in using polled I/O instead of interrupts, there's never any lag at the end of the transfer, but you sacrifice your SYSTEM speed for hard disk speed. Overall, things will be slower, since you actually end up wasting time in wait states, waiting on the hard disk. Single tasking systems like the Macintosh or PC might take this OK, since they have nothing else to do anyway, but it's no good for an Amiga. C Ltd's Kronos and Supra's WordSync both funnel SCSI into the 16 bit data path, though I don't know if they hog the bus as described or not. The third approach is to add a buffer to your CPU copy approach. In this system, you have the SCSI chip itself conduct a DMA-like transfer into some private controller memory (many SCSI chips provide a counter output to make the hardware for this easy). Once the transfer is complete, the controller interrupts the CPU, which does a fast memory-to-memory copy of the acquired data block, all at once. The transfer speed here is still the same 1.75 MB/s as in the previous method, however, it always occurs at full speed. The preceived disk speed may be a bit slower, since the actual transfer doesn't start until the block is fully read, but the overall SYSTEM goes faster, since no time is wasted in wait states. The GVP controller does this. The final method is true DMA. While DMA controllers can use a full block buffering method, most use some kind of FIFO, which tends to be more efficient with DMA. The DMA controller can transfer data at the full 3.5 MB/s, although asynchronous SCSI can only manage 1.5 MB/s. The CPU will set up the DMA controller with a destination for any number of SCSI blocks, and then the DMA controller takes over. When the FIFO is near full, it requests the bus, transfers data at full speed, and then gives the bus back when the FIFO empties until the FIFO is near full again. The actual data gets into memory not much differently than the buffered CPU copy approach (eg, no wait states), but for the same amount of data transferred, the DMA device uses 1/2 the bus time. The other 1/2 is available to the CPU, so CPU work actually gets done during the transfer, even if waiting is required. A2090[a], A2091, A3000, and Microbotics Hardframe work this way (the A3000 DMA controller, by the way, runs at around 20 MB/s on a 25MHz A3000). >you win nothing because you have a whole lot of DMA going on already inside >the system The other DMA in the system is a completely different kind of DMA. Hard disk controllers run on the Fast/Expansion bus just like the CPU, while "Amiga" DMA is this special slot-allocated bus sharing that only takes place on the Chip bus. The two are unrelated; in fact, as far as the Fast or Chip bus is concerned, there's no difference between CPU access or access by a DMA driven expansion device such as a hard disk controller. >and processor's running into heavy troubles sometimes, e.g. >harddisk-performance is very low while using overscan-graphics (just to >mention an example). The only case in which overscan-graphics cause a problem is in the case of the 2090[a] controllers. And this has nothing to do with DMA. The effect of overscan with many bitplanes on is to tie up the chip bus for long periods of time. If the CPU is trying to access Chip memory at this time, it gets wait stated and can do nothing until a retrace comes along. DMA or non-DMA, you have the same problem here -- getting the CPU away from waiting on Chip RAM, either by interrupt in the non-DMA case or by bus request in the DMA case. While the hard disk controller is waiting for CPU/bus access, there is still SCSI activity coming in. Unless your controller fully buffering, as in my third case, it must tell SCSI to stop sending data. The problem with the A2090[a] is that it didn't know how to do this. At least part of that problem was due to it's support of ST-506. At the time, ST-506 was the primary interface, SCSI was simply added because it was easy. ST-506 is slower than SCSI, and being a dumb interface, can't be stopped. So for whatever reasons, the A2090[a] controllers didn't know how to tell SCSI to stop sending when they couldn't get the bus fast enough, so they don't work well with heavy chip bus activity. This IS NOT a general problem with DMA! The A2091, A3000, Hardframe, and most likely any other DMA driven controller will work as well with overscan, if not better, than any non-DMA device. The manufacturers of non-DMA devices often try to mislead you by claiming "DMA problems" and implying they pertain to all DMA driven controllers, not just the A2090[a] (which, by the way, haven't been made for awhile). >well, how about "transfer rates up to 4MB/SEC synchronous" (gvp). in fact >i have never understood this one. what do they mean? 4MBytes/sec? As I mentioned previously, asynchronous-mode SCSI transfers run at about 1.5 MB/s, tops. All SCSI devices out there run in asynchronous mode, and many don't handle synchronous mode. That's one of the reasons that the non-DMA controllers have managed, so far, to appear as fast or, parasitically, faster, than the DMA controllers -- as long as the SCSI transfers aren't faster than your transfer mechanism can handle, the speed of SCSI is the limiting factor. In synchronous mode, the SCSI bus uses a clock to coordinate the transfer, yielding potential transfers of 2 MB/s to 5 MB/s, depending on the clock. There's also a fast synchronous mode as part of the SCSI-2 spec which has a top speed of 10 MB/s. Synchronous won't make much difference in most single drive situations, anyway, since the raw speed of data coming off the disk is still around 1.25-1.5 MB/s, at best. But if you have multiple devices on the SCSI bus, and when faster devices are available, controllers that don't saturate the Amiga at 1.5 MB/s (eg, DMA controllers) will go noticably faster than non-DMA controllers. >i have never seen a controller/hd-combination reaching this. Like I said above, you probably won't. Just yet. And the raw SCSI transfer speed is only part of the equation -- your interrupt lag, device driver efficiency, system load, etc. all add to effective disk speed. >4MBits/sec = 512kBytes/sec. seems to be more like the truth, but is an >absolutely ridiculous value No, it's 4 MegaBYTES per Second. That's trivial compared to the speed of the A3000's main bus or Zorro III bus, though not bad for the kind of peripheral bus SCSI is supposed to be. As I mentioned, the drives themselves are still catching up to this, and most A2000-class SCSI controllers are caught up short. The A3000 can hit around 1.2 MB/s through the filesystem with an asynchronous SCSI device, since it's fast DMA and fast bus arbitration are practically invisible when compared to the speed of SCSI. And keep in mind, while that DMA is happening, you're only using about 7.5% of the 3000's main bus bandwidth (a full speed synchronous SCSI could take 25% if it could be sustained). >>Jimmy Liberato liberat@dri.com >stephan von krawczynski -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Get that coffee outta my face, put a Margarita in its place!
billsey@agora.uucp (Bill Seymour) (09/05/90)
In article <1151@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: >Scanline frequency is about 15.7KHz. If there are three free slots per >scanline, you can transfer 3*15.7K words per second -> 94.2Kb/sec. >MFM data comes with 500Kbit/sec == 62.5KB/sec. Therefore the disk-DMA >does not use every slot but if only two slots were available you would >need extra buffers and a slow genlock signal might induce disk-DMA failures. Actually, with the current Paula chips, data transfer from the floppies is done at 250Kbit/sec. Not the 500Kbit.sec that the HD type drives do. That's why it's so much trouble to get the 1.76M floppies working on the Amiga. >Regards, >-- >Michael van Elst >UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve >Internet: p554mve@mpirbn.mpifr-bonn.mpg.de > "A potential Snark may lurk in every tree." -- -Bill Seymour ...tektronix!reed!percival!agora!billsey ============================================================================= Bejed, Inc. NES, Inc. Northwest Amiga Group At Home Sometimes (503) 281-8153 (503) 246-9311 (503) 656-7393 BBS (503) 640-0842
d6b@psuecl.bitnet (09/05/90)
In article <1990Sep4.213845.2043@agora.uucp>, billsey@agora.uucp (Bill Seymour) writes: > > Actually, with the current Paula chips, data transfer from the floppies > is done at 250Kbit/sec. Not the 500Kbit.sec that the HD type drives > do. That's why it's so much trouble to get the 1.76M floppies working > on the Amiga. Yes and no. The transfer rate is indeed 500Kbps, but the data is raw undecoded MFM. It would be extremely easy for Commodore to add support for the HD drives to Paula simply by adding an MFM encode/decode circuit (which should be easy, since MFM is such a simple encoding scheme). Of course, you could also try to add this capability externally, but it might end up being rather clumsy; it might be easier to design a completely seperate controller with its own buffer memory, etc. Note: Applied Eng.'s "high density" drive is not "real" high density as I mean in this posting (as explained in an earlier posting...:-)) -- Dan Babcock
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (09/06/90)
In article <1990Sep4.213845.2043@agora.uucp> billsey@agora.uucp (Bill Seymour) writes: >In article <1151@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: >>MFM data comes with 500Kbit/sec == 62.5KB/sec. Therefore the disk-DMA > > Actually, with the current Paula chips, data transfer from the floppies > is done at 250Kbit/sec. Not the 500Kbit.sec that the HD type drives > do. That's why it's so much trouble to get the 1.76M floppies working > on the Amiga. That's the user data rate. MFM cells are 2 microseconds short giving 500Kbit/sec. Since a user bit is encoded into two MFM cells (clock & data) you'll get 250Kbit/sec for user data. Nevertheless, the disk DMA has to work with the raw data rate of 500Kbit/sec. Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."