Date: Thu, 12 Oct 2000 19:58:59 -0500 From: Carroll Kong <damascus@home.com> To: "Jeffrey J. Mountin" <jeff-ml@mountin.net> Cc: Leonard Chung <leonard@ssl.berkeley.edu>, Warner Losh <imp@village.org>, kline@tao.thought.org, freebsd-stable@FreeBSD.ORG Subject: Re: Bad IDE Drive Message-ID: <4.2.2.20001012192324.00c0de90@email.eden.rutgers.edu> In-Reply-To: <4.3.2.20001010190749.00c5cf00@207.227.119.2> References: <4.3.2.7.2.20001010124858.026637c0@yikes.com> <200010100509.XAA18135@harmony.village.org> <Your message of "Mon, 09 Oct 2000 19:06:31 PDT." <4.3.2.7.2.20001009190324.028c6d58@yikes.com> <4.3.2.7.2.20001009190324.028c6d58@yikes.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 07:45 PM 10/10/00 -0500, you wrote: >At 01:17 PM 10/10/00 -0700, Leonard Chung wrote: >> >>The differing RPMs is more of a marketing decision than any inherent >>limitation in IDE itself. SCSI is a premium product, so it gets the >>higher RPMs first and sometimes bigger buffers, but again, this is due >>not to the SCSI bus having higher performance. Where the focus is on >>spindle speed for SCSI, the focus for IDE is on areal density. IDE drives >>actually give better performance for the dollar in MAPS (megabyte >>accesses per second), KAPS (kilobyte accesses/s), and much better >>performance in sequential performance (i.e. all round) and for that >>price, you get the benefit of redundancy. So with IDE you get better >>performance and less cost. > >This smells like a techie sales pitch. Little meaningful info regardless >of terms and large words. Did I mention I'm a hard sell? Actually, it is probably true. On the low-end, IDE's although rather rare bursts, would most likely outperform an older scsi drive. I got a 9.1 G Ultrastar 9LP and a maxtor 27 gigabyte ide drive. Sorry, the maxtor usually wins out. However, do realize, sequential data is useless for certain applications. If you do serious streaming of random data, you are going to be seeking everywhere. Plus SCSI can usually give consistently throughput, IDE usually does not. I believe the average data size is ~32KBytes before a new seek. So as you scale up the IDE burst, you start to realize your "savings in time" are pretty much nothing even if you could move an infinite amount of data. (if you just start counting seeks to the next data block). Unfortunately, my old 9.1 SCSI drive's seek time is NOT impressive... so the maxtor gets darn close, and with it's superior data rate burst, the scsi drive loses. The superior data rate comes from the density. Please note, density drops on the scsi drive since they want to keep the disk platters lighter (optimized for the in between for speed and density). The Scsi bus is far superior to the Ide bus, overlapping queue commands, etc. Some reasons why scsi is more expensive, They are giving you a longer warranty on average, more liability. Scsi is harder to debug (the controllers), testing is a larger % of cost in all hardware. (this is a hard fact, the testing adding a large % of the cost that is). The entire "it's cheaper since i dont' need a scsi controller" bit. The controller on the drive itself probably costs a bit more due to economies of scale. You can argue researching for the fastest known drive at the time is expensive too. And the ever popular "It's a conspiracy by the harddrive makers!" (ok.. I do not vouch for this, as I strongly feel the former possibilities are the harder reason why). >You would need follow up with figures that involve more than one >transaction. Many more. The hardware may be similar, but the interface >is where the "real world" difference will be evident in a busy production >environment. > >The vagaries referring to price I must presume are talking about RAID >arrays (otherwise it's non-scenical). Seeing a comparison between the >same array with IDE vs SCSI would be interesting. Drives should have very >similar numbers using your comparison. > >With IDE I think most would agree that initial cost will be >lower. However, longevity counts, so total cost for the lifecycle should >be considered. The longer the period, the more likely that IDE will end >up costing more. With IDE I think most would agree that initial cost will be lower. However, longevity counts, so total cost for the lifecycle should be considered. The longer the period, the more likely that IDE will end up costing more. Despite the fact that if you count the warranty factor, it's still cheaper per megabyte to throw the old IDE drive away and get a new one. I do not believe there is a strong correlation as to "ide drives dying faster" than "scsi drives." In fact, from my personal experience, I believe I have felt the same if not more leaning towards the IDE drives. I still vote for SCSI for the most part though. >Going strictly by drive specs and current street cost isn't near enough to >sell me, and surely others, on your ideas. Don't take offense either, >there just seem to be a few holes that need to be fixed. Even if you are >referring to a workstation or single user application where I have opted >for older "slower" SCSI drives than years newer IDE drives for performance >reasons. > >Anxiously awaiting the test results... 8-) > > >Jeff Mountin - jeff@mountin.net Well, not sure how old you are comparing your "slower" scsi drives... just telling you from personal experience .... oh yeah you want numbers? www.storagereview.com Ignore the crap with the other benchmarks. The IoMeter benchmark (by intel) is the better test. If you got an older cheetah or barracuda, you will probably get comparable if not superior performance against the new ides. If you got anything less... it's almost definitely slower. Of course the drivers will make a difference for cpu utilization. (scsi usually wins in this one). Finally, I am neither an IDE fan nor SCSI fan in all situations. They have their places in different areas. For Dollar per Megabytes, you really win with IDE. For performance, you might even say so (economically). For the absolute best... SCSI wins out. As for the raid situation, you'd need a dedicated channel for each IDE drive... good lord, does that thing take up IRQs per channel? If so, cannot possibly scale to match up to a good scsi raid. -Carroll Kong To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.2.20001012192324.00c0de90>