lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/02/90)
In <1990Sep1.231510.10650@agate.berkeley.edu>, c60c-1gd@e260-1c.berkeley.edu (Joon Song) writes: >I'm sorry if this has been discussed before. I've read several articles >claiming that hard disk transfer rates through a SCSI port is as high as >3.5 meg/sec. Is this the actual throughput of the hard disk system? >Does this involve data being cached? 3.5 meg/sec is considerably faster >than what I had thought possible for hard disk r/w. There are hard drives, and there are hard drives. Some are faster than others. The fastest hard drives are fairly expensive, though not exceedingly so. >Suppose a hard disk had 34 sectors/track. A hard disk spins 60 rev/sec. >So the fastest disk transfer rate should be: > 34 sectors/track * 512 bytes/sector * 60 rev/sec = approx. 1 meg/sec. Suppose it had cylinder caching. Suppose it had even more sectors per track. Suppose it had a parallel head scheme. Suppose it is an SMD drive run through a SCSI<->SMD adapter. >Can someone explain how 3.5 meg/sec transfer rate can be possible? Many things are possible, once the drive and controller are integrated, and the manufacturer no longer has to have a controller<->drive interface that is compatible with any published standards. The fastest SCSI hard drives available today can run pretty fast. Here are some excerpts from a posting on another newsgroup: -------------------------------------------------------------------------- Synchronous SCSI is a data transfer method that, during the data phase only, allows burst data transfers at a higher rate over a longer distance than asynchronous transfer allows. Depending on the particular machines, the data rates theoretically reach 5 Mbytes. Typical implementations allow 2.5 to 4.5 Mbytes. The host adapter and the peripheral device must both agree, through a special negotiation procedure, what speed they will use. Note that most SCSI disk drives are ultimately limited in their data rate by the rate at which data can be read from the disk, typically 1.2 to 1.8 Mbytes. SCSI disk drives are just beginning to get their seek times down near SMD seek times (14 to 20 milliseconds). The result is that, for the near term, the net performance of a typical SCSI drive will be somewhat less than the performance of an SMD disk drive. As the disk data rate and seek times improve over the next five years, the SCSI drives will gradually move into the performance range presently occupied by the SMD drives. Many of the SCSI disks also have special caching and buffering features that not only speed up the data transfer, but provide faster access to the data. ----------------------------------------------------------------------- The Imprimis Wren-7 is a 1.2GB drive with a sub-20ms average access time and up to 4MB/sec synchronous SCSI transfer rate. Hewlett-Packard also makes a 1.2GB SCSI drive with 16ms average access time, 4MByte/sec transfer rate synchronous, 1.5MByte/sec asynchronous. The Imprimis drive (without power supply or cabinet) is available from Arrow Electronics for ~$4000. The HP drive is available from Hybrid Systems (+1 617 357 1838) for $4150. It comes with a 5-year warrantee from HP. Besides the benefit of a 40% price reduction, these are 5-1/4'' drives, taking trivial space and power and not requiring rack mounting. (Hybrid can also sell you the Imprimis drive, and packaging and cables and such.) My HP drive is "in the mail" and I can let you know how it works in a few weeks. I've had nothing but pleasure from my two Imprimis Wren-5's so I expect that a Wren-7 would do fine too. It was the 5-year warrantee from HP that swayed me in their direction. I don't know of any SCSI drives that have hit the 6MB/sec transfer rate of the $11500 IPI drives, but for that money you could buy TWO 1.2gig SCSI disks and TWO host adapters, for a similar aggregate data rate but twice the access arms, twice the capacity, and the ability to transfer data on one drive while the other is seeking. --------------------------------------------------------------------------- -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 | +-----------------------------------------------------------------------+
c60c-1gd@e260-1c.berkeley.edu (Joon Song) (09/02/90)
I'm sorry if this has been discussed before. I've read several articles
claiming that hard disk transfer rates through a SCSI port is as high as
3.5 meg/sec. Is this the actual throughput of the hard disk system?
Does this involve data being cached? 3.5 meg/sec is considerably faster
than what I had thought possible for hard disk r/w.
Suppose a hard disk had 34 sectors/track. A hard disk spins 60 rev/sec.
So the fastest disk transfer rate should be:
34 sectors/track * 512 bytes/sector * 60 rev/sec = approx. 1 meg/sec.
Can someone explain how 3.5 meg/sec transfer rate can be possible?
---------
Joon Song
c60c-1gd@web.berkeley.edup554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (09/03/90)
In article <1990Sep1.231510.10650@agate.berkeley.edu> c60c-1gd@e260-1c (Joon Song) writes: >I'm sorry if this has been discussed before. I've read several articles >claiming that hard disk transfer rates through a SCSI port is as high as >3.5 meg/sec. Is this the actual throughput of the hard disk system? >Does this involve data being cached? 3.5 meg/sec is considerably faster >than what I had thought possible for hard disk r/w. I think there are some disks around that work with a data rate that high but they don't use the SCSI bus. The fastest SCSI disks I've seen are the 700Meg devices from Maxtor and HP (and possibly more companies). With 56 sectors/track you can get about 1.6MB/sec sustained data rate. But if you use several disks at a time you could add up their data rates up to the limit given by the SCSI bus and the host adapter. With the Amiga this is 3.5MB/sec therefore you could read from two such drives at once and don't impact on the drives performance. -- 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."
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/07/90)
In <126198@pyramid.pyramid.com>, telam@pyrps5.pyramid.com (Thomas Elam) writes: > >I was confused too, until I remembered seeing disk I/O throughput >measurements on our Pyramid mainframe computers. They were around 400 >Kilobyte per second or higher, measured by user-level software, so this >*is* the throughput of the hard disk system. This works out to be 3.2 >Megabits per second (400,000 x 8 = 3,200,000) or higher. I believe >some people thought SCSI systems have throughputs of 4 Mega-*bytes* >per second. I'm not on the SCSI committee, but I'll bet an Amiga that >the throughputs are really about 4 Mega-*bits* per second. > >>Does this involve data being cached? 3.5 meg/sec is considerably faster >>than what I had thought possible for hard disk r/w. >> >>Suppose a hard disk had 34 sectors/track. A hard disk spins 60 rev/sec. >>So the fastest disk transfer rate should be: >> 34 sectors/track * 512 bytes/sector * 60 rev/sec = approx. 1 meg/sec. >> >>Can someone explain how 3.5 meg/sec transfer rate can be possible? > >I can't address myself to your other questions, but I have seen >calculations made by UNIX-guru-grade I/O software engineers that work >like your calculation. And I think the numbers are right, too. The discussion was confused, to say the least. Here are some of the salient points. The A3000 SCSI controller is capable of handling 3.5 MegaBYTES/second to/from memory. The SCSI bus itself is capable of handling about 5 MegaBYTES/second. Currently, the ultimate limitation (ie. sustained throughput) is limited by the rate at which data comes off the disk. Not all SCSI disks are limited to the figures posted in the message you replied to. Some (a very few) expensive SCSI disks can transfer data at sustained rates of about 3 MegaBYTES/second. Some SCSI disks use fairly large buffers, and this gives them a short-term transfer rate of 4.5-5 MegaBYTES/second. The best DiskSpeed performance figures I have seen on an A2000 are about 1.5 MegaBYTES/second. -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 | +-----------------------------------------------------------------------+
telam@pyrps5.pyramid.com (Thomas Elam) (09/08/90)
In article <1990Sep1.231510.10650@agate.berkeley.edu> c60c-1gd@e260-1c (Joon Song) writes: >I'm sorry if this has been discussed before. I hope I'm not violating any rules of n-et-iquette in my follow-up. Could someone please tell by electronic mail to me if I am. >I've read several articles >claiming that hard disk transfer rates through a SCSI port is as high as >3.5 meg/sec. Is this the actual throughput of the hard disk system? I was confused too, until I remembered seeing disk I/O throughput measurements on our Pyramid mainframe computers. They were around 400 Kilobyte per second or higher, measured by user-level software, so this *is* the throughput of the hard disk system. This works out to be 3.2 Megabits per second (400,000 x 8 = 3,200,000) or higher. I believe some people thought SCSI systems have throughputs of 4 Mega-*bytes* per second. I'm not on the SCSI committee, but I'll bet an Amiga that the throughputs are really about 4 Mega-*bits* per second. >Does this involve data being cached? 3.5 meg/sec is considerably faster >than what I had thought possible for hard disk r/w. > >Suppose a hard disk had 34 sectors/track. A hard disk spins 60 rev/sec. >So the fastest disk transfer rate should be: > 34 sectors/track * 512 bytes/sector * 60 rev/sec = approx. 1 meg/sec. > >Can someone explain how 3.5 meg/sec transfer rate can be possible? I can't address myself to your other questions, but I have seen calculations made by UNIX-guru-grade I/O software engineers that work like your calculation. And I think the numbers are right, too. >Joon Song >c60c-1gd@web.berkeley.edu Regards, Tom
telam@pyrps5.pyramid.com (Thomas Elam) (09/08/90)
In article <126198@pyramid.pyramid.com> telam@pyrps5.pyramid.com (Thomas Elam) writes: [I'm adding to my own follow-up.] >In article <1990Sep1.231510.10650@agate.berkeley.edu> c60c-1gd@e260-1c (Joon Song) writes: >>I'm sorry if this has been discussed before. > >I hope I'm not violating any rules of n-et-iquette in my follow-up. >Could someone please tell by electronic mail to me if I am. > >>I've read several articles >>claiming that hard disk transfer rates through a SCSI port is as high as >>3.5 meg/sec. Is this the actual throughput of the hard disk system? > >I was confused too, until I remembered seeing disk I/O throughput >measurements on our Pyramid mainframe computers. They were around 400 >Kilobyte per second or higher, measured by user-level software, so this >*is* the throughput of the hard disk system. This works out to be 3.2 >Megabits per second (400,000 x 8 = 3,200,000) or higher. I believe >some people thought SCSI systems have throughputs of 4 Mega-*bytes* >per second. I'm not on the SCSI committee, but I'll bet an Amiga that >the throughputs are really about 4 Mega-*bits* per second. I'm sorry. I was wrong. I asked a guru here. The "fast synchronous data transfers" of SCSI use a clock that sets the transfer rate somewhere between 4 and 5 Megabytes per second, not faster or slower. For example, an HP SCSI drive we have here is specified to have fast synchronous data transfer rate of 4 MB. I think it would require an incredibly fast microcode-software-programmed controller to sustain a 4 MB transfer rate: not just the software would have to be efficient, but the controller's CPU and other hardware would have to be fast. >>Does this involve data being cached? 3.5 meg/sec is considerably faster >>than what I had thought possible for hard disk r/w. >> >>Suppose a hard disk had 34 sectors/track. A hard disk spins 60 rev/sec. >>So the fastest disk transfer rate should be: >> 34 sectors/track * 512 bytes/sector * 60 rev/sec = approx. 1 meg/sec. >> >>Can someone explain how 3.5 meg/sec transfer rate can be possible? > >I can't address myself to your other questions, but I have seen >calculations made by UNIX-guru-grade I/O software engineers that work >like your calculation. And I think the numbers are right, too. > >>Joon Song >>c60c-1gd@web.berkeley.edu > >Regards, >Tom Tom
daveh@cbmvax.commodore.com (Dave Haynie) (09/11/90)
In article <126198@pyramid.pyramid.com> telam@pyrps5.pyramid.com (Thomas Elam) writes: >In article <1990Sep1.231510.10650@agate.berkeley.edu> c60c-1gd@e260-1c (Joon Song) writes: >>I've read several articles >>claiming that hard disk transfer rates through a SCSI port is as high as >>3.5 meg/sec. Is this the actual throughput of the hard disk system? >I was confused too, until I remembered seeing disk I/O throughput >measurements on our Pyramid mainframe computers. They were around 400 >Kilobyte per second or higher, measured by user-level software, so this >*is* the throughput of the hard disk system. This works out to be 3.2 >Megabits per second (400,000 x 8 = 3,200,000) or higher. I believe >some people thought SCSI systems have throughputs of 4 Mega-*bytes* >per second. I'm not on the SCSI committee, but I'll bet an Amiga that >the throughputs are really about 4 Mega-*bits* per second. Typical SCSI devices use the asynchronous transfer mechanism, which is limited to about 1.5 MegaBYTES per second. Synchronous SCSI, which uses a clock rather than a handshake to clock its data, runs at a peak of 4-5 MegaBYTES per second. Currently, you won't find actual disk drives that can get data off their platters much faster than the 1.5 MegaBYTES per second of the asynchronous SCSI, and most are slower. But you don't necessarily have just one device connected to the SCSI bus, so if a drive is capable of buffering up a track and sending over SCSI a 4 MegaBYTES per second, rather than going directly from the disk at 1.5-something MegaBYTE per second, you have a big win in a system with multiple SCSI devices. >I can't address myself to your other questions, but I have seen >calculations made by UNIX-guru-grade I/O software engineers that work >like your calculation. And I think the numbers are right, too. UNIX is a bad example of "high speed disk I/O", in general. Most fast UNIX systems at the Workstation or PC level manage about 400 KB/s, or less. Under the Amiga OS, it's not all that unusual to have typical 800 KB/s transfers, and with a suitable hard disk (like of the Wren drives), you can get noticably over one MB/s. That is, of course, though the filing system. Part of the problem with UNIX is that most transfers are broken up into small blocks. You might have 10 separate I/O operations to load a 10K block, even if its contiguous out on disk. The Amiga's FFS will permit loading of a block of any size in one operation. >Tom -- 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!
ttavolij@praxis.cs.ruu.nl (Thomas Tavoly) (09/11/90)
In article <14330@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: [Loadsa-stuff deleted] > >Typical SCSI devices use the asynchronous transfer mechanism, which is limited >to about 1.5 MegaBYTES per second. Synchronous SCSI, which uses a clock >rather than a handshake to clock its data, runs at a peak of 4-5 MegaBYTES >per second. Currently, you won't find actual disk drives that can get data >off their platters much faster than the 1.5 MegaBYTES per second of the >asynchronous SCSI, and most are slower. > 1. Actually I read something about the IVS Trumpcard Professional version which will achieve a transfer rate of 1.8 MBytes/sec. Rumour has it that this card will be out soon (what? Maybe 1992? ;-). Is this with a stock 68k Amiga or some '030? I believe that the method employed here is using a 16 bit wide bus (dubbed SCSI II), instead of the former 8 bits. No info on whether it uses DMA or not, but probably yes. 2. Does anyone know of the transfer rates achieved by the GVP Series II SCSI controller as advertised on page 7 of AmigaWorld September? It's rather more expensive for me to call to the States than seeking the (free) advice of my fellow Amigos... [and other stuff deleted] On a more brighter note, would you believe this one: I told a friend, also on the net, that I would be upgrading my A500 (yes the 3000 is still beyond my reach...) with 2 MB's. He then exclaimed in horror: "Oh my God, then it will be bitching in stereo !!" :) ;) BTW, I'll be on the Koeln '90 Ami-expo too, look for that handsome - oh well you know - :-) Does someone know whether Mr. MB will be there? Should be an interesting discussion if I met him. I would love to exchange views on several subjects. Yes, I know I should have posted this to c.s.a. but the thread was here, besides there are 2 serious questions in there. M&M's: melt in your mouth, not on your keyboard (except if it's an Amiga, because they are sooo hot!)
h112706@assari.tut.fi (Herranen Henrik) (09/12/90)
In article <126198@pyramid.pyramid.com> telam@pyrps5.pyramid.com (Thomas Elam) writes: >In article <1990Sep1.231510.10650@agate.berkeley.edu> c60c-1gd@e260-1c (Joon Song) writes: >per second. I'm not on the SCSI committee, but I'll bet an Amiga that >the throughputs are really about 4 Mega-*bits* per second. You have just lost an Amiga. I've got a 68010-based A2000 with 3 Megs of RAM and the Hard Frame controller with a Quantum 105 MB drive, and the *actual* data read speed is about 690 kB/s, which is not (I think) 'about 4 Mbit/s'. The Amiga may be sent to: Henrik Herranen TTKK/Paarakennuksen neuvonta PL 527 33101 Tampere Finland -- Name: Henrik 'Leopold' Herranen h112706@lehtori.tut.fi Address: TTKK/P{{rakennuksen neuvonta/PL527/33101 Tampere/Suomi Finlandia "On d{htinen daevas ja kuutamoy|, on morsiamelta katkaistu p{{" E.L.1989
daveh@cbmvax.commodore.com (Dave Haynie) (09/14/90)
In article <3769@ruuinf.cs.ruu.nl> ttavolij@praxis.cs.ruu.nl (Thomas Tavoly) writes: >In article <14330@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave >Haynie) writes: >>Typical SCSI devices use the asynchronous transfer mechanism, which is limited >>to about 1.5 MegaBYTES per second. Synchronous SCSI, which uses a clock >>rather than a handshake to clock its data, runs at a peak of 4-5 MegaBYTES >>per second. Currently, you won't find actual disk drives that can get data >>off their platters much faster than the 1.5 MegaBYTES per second of the >>asynchronous SCSI, and most are slower. >1. Actually I read something about the IVS Trumpcard Professional version >which will achieve a transfer rate of 1.8 MBytes/sec. That's not bloody likely. You figure any no wait state cycle on the A2000 takes 560ns. Discounting the overhead of the copying loop itself, you need memory two cycles to transfer 16 bits, so you're capable of transferring 1 byte every 560ns. So it'll take 587,202,560ns to transfer a megabyte. Which is 1 Megabyte every 0.5872 seconds, or about 1.703 Megabytes/second. So, without DMA, you can't possibly get stuff off a hard disk any faster than that across the A2000 bus, and anyone who says differenly is lying to you. And in reality, it's slower than that, since the CPU needs to fetch instructions (you probably get close to this speed with a 68010 using loop mode for the transfer). Of course, none of this is going to tell you how fast the transfer or the effective disk speed is going to be. The speed of SCSI, if asynchronous, will be another limiting factor. The actual speed of the hard disk still another. >Rumour has it that this card will be out soon (what? Maybe 1992? ;-). To get close to those speeds with that card, you would need to have a synchronous SCSI interface going at 2 megabytes/second or so, and you would also need a SCSI device capable of actually supplying data that fast. This also implys, in a non-DMA device, that the device is parasitic -- it waits on the SCSI bus for data, to get it over as fast as possible, rather than buffering at SCSI speeds and transferring full speed once SCSI is done. >Is this with a stock 68k Amiga or some '030? A 68030 system with a non-DMA controller can get faster transfers across the A2000 bus. For example, while the A2630 can run a 560ns cycle out to the Zorro II bus, it can manage a 200ns cycle, at 32 bits wide, to it's own memory. So in theory, you could achieve a rate of 1 byte every 330ns, or 2.89 megabytes/second, though with synchronization delays considered, it'll be something less than this. With DMA, the theoretical limit on the A2000 is 3.41 megabytes/second. >I believe that the method employed here is using a 16 bit wide bus (dubbed >SCSI II), instead of the former 8 bits. SCSI II isn't 16 bits wide, it's still 8 bits. It specifies the SCSI command set in a much more standardized fashion than original SCSI, and has a fast synchronous transfer mode capable of 10 megabytes/second. But it really doesn't matter what your fastest transfer rate is capable of in a system, the limit is based on the slowest element in the link, whether that be A2000 bus transfer speed, SCSI speed, or the hard disk's own speed. -- 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!
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/19/90)
In <2253@impch.imp.com>, rumbo@impch.imp.com (Peter Kunz) writes: >>The best DiskSpeed performance figures I have seen on an A2000 are about 1.5 >>MegaBYTES/second. >> >HOW???? By using the right drive. >is this a bare bone a2000? >i have a standard a2000b with 4 megs 16 bit ram added, an a2091 and a quantum >105s. after adding 256k of buffers to each partition i get 640 kb/s. can this >be improved? Yes, but you will need to spend quite a few thousand dollars on a drive capable of VERY high transfer rates. I don't know the manufacturer or model number of the drive, but it was a beta version of a new drive from a well known company. The figure was reported on a thread on Bix. -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 | +-----------------------------------------------------------------------+
rumbo@impch.imp.com (Peter Kunz) (09/20/90)
>The best DiskSpeed performance figures I have seen on an A2000 are about 1.5 >MegaBYTES/second. > HOW???? is this a bare bone a2000? i have a standard a2000b with 4 megs 16 bit ram added, an a2091 and a quantum 105s. after adding 256k of buffers to each partition i get 640 kb/s. can this be improved? pete
jms@tardis.Tymnet.COM (Joe Smith) (09/20/90)
In article <1990Sep1.231510.10650@agate.berkeley.edu> c60c-1gd@e260-1c (Joon Song) writes: >I'm sorry if this has been discussed before. I've read several articles >claiming that hard disk transfer rates through a SCSI port is as high as >3.5 meg/sec. Is this the actual throughput of the hard disk system? A lot of the numbers I've seen bandied about do not have any qualifiers; they don't say that they are peak transfer rates instead of sustained rates. >Suppose a hard disk had 34 sectors/track. A hard disk spins 60 rev/sec. >So the fastest disk transfer rate should be: > 34 sectors/track * 512 bytes/sector * 60 rev/sec = approx. 1 meg/sec. Imagine a disk controller that is mounted on the disk drive and it has a buffer big enough for a full track. Such a device could send 34*512 = 17408 bytes every 1/60th of a second (ignoring the time it takes to switch heads and assuming it has enough heads per cylinder to be worthwile). If this imbedded disk controller waited until it had a full buffer and then blasted it into the Amiga as fast as the Amiga could handle it, the manufacturer could brag about having a 3.5 megabytes per second peak transfer rate. During the 1/60th second, the average transfer speed would be: 0 bytes/sec for 11.70 milliseconds + 3.5 Mbytes/sec for 4.97 milliseconds which is only 1.04 megabytes per second. Including the track-to-track access times, the sustained transfer rate would be even lower. Summary: Be sure to specify "peak" vs "sustained" transfer rates when discussing high-speed disk performance. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."
ridder@elvira.enet.dec.com (Hans Ridder) (09/21/90)
In article <14418@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >SCSI II isn't 16 bits wide, it's still 8 bits. It specifies the SCSI command >set in a much more standardized fashion than original SCSI, and has a fast >synchronous transfer mode capable of 10 megabytes/second. But it really >doesn't matter what your fastest transfer rate is capable of in a system, the >limit is based on the slowest element in the link, whether that be A2000 bus >transfer speed, SCSI speed, or the hard disk's own speed. I'm not an expert on SCSI II in any way, but what Dave says here is contrary to to what I've read about it. What I've read says that SCSI II allows bus widths of 1, 2, or 4 bytes. Using unbalanced tranceivers, the maximum speed is 5 megatransfers/sec. (synchronous I assume), and 10 megatransfers/sec. using balanced tranceivers. I dunno if they specify a slower asynchronous speed or not. So, a 4 byte wide bus using balanced transceivers could really move some data (and would really cost quite a few samolians.) Wish I had a copy of the spec. (it's 600 pages, whew!) >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" -hans ------------------------------------------------------------------------ Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
blgardne@javelin.es.com@bambam.UUCP (Blaine Gardner) (09/22/90)
rumbo@impch.imp.com (Peter Kunz) writes: >>The best DiskSpeed performance figures I have seen on an A2000 are about 1.5 >>MegaBYTES/second. >HOW???? >is this a bare bone a2000? >i have a standard a2000b with 4 megs 16 bit ram added, an a2091 and a quantum >105s. after adding 256k of buffers to each partition i get 640 kb/s. can this >be improved? Sure, all you have to do is replace that pokey Quantum with something like a 1.2 gigabyte Wren VII. The drive alone will only run you $5000 or so. You might also get similar performance with the cheaper Wren VI or V for only $3-4000. As has been stated many times, you're only as fast as the slowest link in the chain. The Quantum drives are FAR better than the cheaper Seagates, but they do lag behind the megabuck drives in speed. The best I've seen personally out of the Q105S is about 900K/sec (DiskSpeed 3.1) on an A3000. On an A2000 with the A2620 card I've got about 800-850K/sec. You'll never hit 1.5M/sec with the Quantum, but I would expect you could get better than 640K/sec. Were you running the test on an unfragmented (freshly formatted is best) partition? I've seen moderate fragmentation cut DiskSpeed test results in half. -- Blaine Gardner @ Evans & Sutherland 580 Arapeen Drive, SLC, Utah 84108 blgardne@esunix.UUCP BIX: blaine_g {decwrl, utah-cs}!esunix!blgardne DoD #0046 The Borg killed Laura Palmer!
jma@beach.cis.ufl.edu (John 'Vlad' Adams) (09/24/90)
Here's an interesting speed result for you demons out there. When I run Devspeed on my 2091/Quantum 40, I get reads in the 800-830k range, while my writes are in the 400-450k range. Talk about a big difference. The same program on a GVP/Segate combination gets read/writes in the 650k range. Oh, the 450k writes are on a freshly formatted partition as well. -- John M. Adams --**-- Professional Student on the six-year plan! /// Internet: jma@beach.cis.ufl.edu -or- vladimir@maple.circa.ufl.edu /// "We'll always be together, together in electric dreams" Tangerine Dream \\V// Cosysop of BBS:42; Amiga BBS FIDOnet 1:3612/42. 904-438-4803 (Florida) \X/
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (09/24/90)
In article <24541@uflorida.cis.ufl.EDU> jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: >Here's an interesting speed result for you demons out there. >When I run Devspeed on my 2091/Quantum 40, I get reads in >the 800-830k range, while my writes are in the 400-450k range. >Talk about a big difference. The same program on a GVP/Segate >combination gets read/writes in the 650k range. Oh, the >450k writes are on a freshly formatted partition as well. That's because of the read-ahead cache of the drive. As the name says it won't work with writes. 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."
jma@beach.cis.ufl.edu (John 'Vlad' Adams) (09/25/90)
In article <1245@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: > >That's because of the read-ahead cache of the drive. As the name >says it won't work with writes. Sure, the Quantum has a 64k cache, but I certainly hope that a Quantum is capable of better than 450k writes when all I've heard is how a Quantum is one of the best low-end drives. I also would hope that a DMA controller like the 2091 is faster than a non-DMA GVP card using a bloody slow Segate drive. I'm not satisfied with the 64k cache being the only saving grace of the drive. I guess I could drop my Quantum onto his GVP card sometime, although it would be one heck of a hassle with my parition setup. Or is GVP compatible with the 2091's RDB? -- John M. Adams --**-- Professional Student on the six-year plan! /// Internet: jma@beach.cis.ufl.edu -or- vladimir@maple.circa.ufl.edu /// "We'll always be together, together in electric dreams" Tangerine Dream \\V// Sysop of The Beachside. FIDOnet 1:3612/557. 904-492-2305 (Florida) \X/
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (09/26/90)
In article <24562@uflorida.cis.ufl.EDU> jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: >Sure, the Quantum has a 64k cache, but I certainly hope that a Quantum >is capable of better than 450k writes when all I've heard is how >a Quantum is one of the best low-end drives. I also would hope that >a DMA controller like the 2091 is faster than a non-DMA GVP card >using a bloody slow Segate drive. I'm not satisfied with the >64k cache being the only saving grace of the drive. I guess I >could drop my Quantum onto his GVP card sometime, although >it would be one heck of a hassle with my parition setup. Well, harddisk timings are a little difficult. There's the 'raw' data transfer rate from the drive (should be about 930K/sec for the Quantum) which is the theoretical maximum that can be achieved. The problem is that you may miss the next sector to read if anything interrupts the transmission. This can be a step to the next cylinder or the delay when another SCSI command is sent. What happens ? Without a cache you'll really miss the next sector and wait a complete revolution of the disk (thus the sustained data rate will be half of the maximum). What can be done ? To minimize the delay by the step you can introduce a track skew so that the next sector to read will just pass under the read/write head when the heads have settled onto the new track. Another method is to start reading at an arbitrary sector (which can't be transmitted yet) into a cache and start transmission when the right sector has been read. When the track has been read completely the drive can pump all pre-read sectors with the maximum data rate of the SCSI Bus. Even this takes some time which can be used to read ahead some sectors (maybe of another track) so that reading the drive will be more or less continously and approaches the raw data rate. Unfortunately, this is a little tricky to do when writing. >Or is GVP compatible with the 2091's RDB? Since RDB is a standard :-) any controller that supports RDB should allow to access any drive that has the RDB written on it. -- 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/26/90)
In article <24562@uflorida.cis.ufl.EDU> jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: > Or is GVP compatible with the 2091's RDB? Yup, version 3.x is. Ralph
jesup@cbmvax.commodore.com (Randell Jesup) (09/30/90)
In article <24562@uflorida.cis.ufl.EDU> jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: >In article <1245@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: >> >>That's because of the read-ahead cache of the drive. As the name >>says it won't work with writes. > >Sure, the Quantum has a 64k cache, but I certainly hope that a Quantum >is capable of better than 450k writes when all I've heard is how >a Quantum is one of the best low-end drives. I also would hope that >a DMA controller like the 2091 is faster than a non-DMA GVP card >using a bloody slow Segate drive. I'm not satisfied with the >64k cache being the only saving grace of the drive. The 40's have 16K caches, I think. The 80's and all the new generation models (50's, etc) have 64K+ I think. The Q40S software seems to have been a bit slow at writes compared to the others. Q50S's and Q210S's, and Q105S's seem to get 700-900K/s writes, and slightly faster reads. -- 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!"
jma@beach.cis.ufl.edu (John 'Vlad' Adams) (10/01/90)
> The 40's have 16K caches, I think. The 80's and all the new >generation models (50's, etc) have 64K+ I think. The Q40S software seems >to have been a bit slow at writes compared to the others. Q50S's and >Q210S's, and Q105S's seem to get 700-900K/s writes, and slightly faster >reads. Well, according to A) my 2091 manual, and B) the various config programs I have which scan all my cards, the Q40S has the same 64k cache. And when a buddy put his Q40S on a Kronos and an A2630 card, he got speeds in the upper 800k on both read and write operations. I guess I'll get a Kronos since I have a 2058 now. (Well, once the AmaxII HD driver is available...) -- John M. Adams --**-- Professional Student on the six-year plan! /// Internet: jma@beach.cis.ufl.edu -or- vladimir@maple.circa.ufl.edu /// "We'll always be together, together in electric dreams" Tangerine Dream \\V// Sysop of The Beachside. FIDOnet 1:3612/557. 904-492-2305 (Florida) \X/