[luau] INFO: Heavy duty storage needs

[MonMotha]

I'm glad someone liked my explanation :)


I recently built a nice dualie AMD 1.4GHz, 2GB DDR, with 2xU160 36GB 
15kRPM hard drives.  It's (among other things) a proxy server and 
mailer.  Proxying, especially when also doing mail, involves some 
bandwidth (but not excessive, it's only a 1gbit uplink to the LAN), but 
it also involves a lot of seeking.  The tagged command queuing and 
reduced seek times of the SCSI drives are a big advantage on this puppy.

--MonMotha

R. Scott Belford wrote:
> I have searched for such a concise and practical explanation of why SCSI 
> is accepted as the better storage solution for high-intensive seeks.  
> Now I understand.  Thanks for explaining this so clearly.
> 
> On Thursday, May 2, 2002, at 12:46 PM, MonMotha wrote:
> 
>> This is true.  In terms of raw I/O speed, IDE drives have caught up 
>> with SCSI.  The reason?  The bus is no longer the bottleneck.  Even 
>> the best of SCSI drives would have trouble saturating a 100MB/sec bus 
>> (though SCSI is 160).  If all you need is raw I/O speed (which is a 
>> good chunk of what your average single user desktop will be working 
>> with, especially if they're doing a lot of multimedia), IDE drives are 
>> a great choice (especialy combined with a software RAID solution, such 
>> as the Linux software RAID or some of the software "RAID" cards that 
>> are now out for the 'dozers).
>>
>> SCSI shows it's strength in Tagged Command Queueing.  Unlike IDE 
>> devices, SCSI drives can work on more than one command at the same 
>> time, queueing them up in the best way possible.  For example, an IDE 
>> system where a person wants to simultaneously (quicker than a single 
>> seek on the drive) pull information from 10 places on the disk will 
>> have to do them in the order the system says.  With SCSI, the system 
>> can send all 10 (or usually 9) requests in quick succession, and the 
>> drive will service them in the best way possible, minimizing redundant 
>> seeking, serving out of cache when possible (often even during a seek 
>> for the next command in the queue), etc.  In multiuser environments, 
>> this can give SCSI a HUGE advantage over IDE.  SCSI drives also tend 
>> to have lower seek times, often due to smaller platter sizes rotating 
>> at significantly faster speeds (15,000 RPM vs. 7200 or even 5400 RPM). 
>> This is also the reason SCSI drives tend to have smaller capacity as 
>> compared to IDE drives while still being expensive.  The same 
>> "technology" has to be used to pack all those bits into a small space, 
>> but the overall space is smaller (many SCSI drives could almost fit 
>> their platters into 2.5" laptop HDD enclosures, see fujisu specs on 
>> platter size).  These lower seek times also help performance in 
>> multiuser environments.
>>
>> Also, though this is not as much of a deal with UDMA IDE, IDE uses the 
>> CPU for some of it's processing.  The same things are done on SCSI on 
>> the dedicated controller and onboard the drive itself.
>>
>> Conclusion: Don't assume SCSI is better, but don't assume raw I/O 
>> bandwidth is the only measure of a hard drive.
>>
>> --MonMotha
>>
>> R. Scott Belford wrote:
>>
>>> If you intend to record most or all of the traffic moving over your 
>>> network, you need to spend as much time thinking about your disk 
>>> subsystem as your processor and Ethernet card. Last year Sandstorm 
>>> spent several months comparing IDE drives with the UDMA100 interface 
>>> to SCSI LVD-160 drives. We also explored a variety of RAID systems. 
>>> The conclusion: today's IDE drives are significantly faster than SCSI 
>>> drives costing two or three times more per gigabyte stored.
>>> This is not the result we were expecting, and it goes directly 
>>> against the conventional wisdom that says SCSI is inherently better 
>>> than IDE. Nevertheless, it does seem to be the ugly truth, at least 
>>> for straightforward read/write tests in a single-user environment. 
>>> Although we saw the highest performance with a hardware-based RAID 5 
>>> system manufactured by _Advanced Computer & Network Corporation_, we 
>>> saw nearly the same performance with a RAID 5 system based on the 
>>> _3Ware Escalade 7000_ RAID controller.
>>> from an article about network data capture at
>>> http://www.oreillynet.com/lpt/a//network/2002/04/26/nettap.html
>>
>>
>>
>> _______________________________________________
>> LUAU mailing list
>> LUAU at videl.ics.hawaii.edu
>> http://videl.ics.hawaii.edu/mailman/listinfo/luau
>>
> 
> _______________________________________________
> LUAU mailing list
> LUAU at videl.ics.hawaii.edu
> http://videl.ics.hawaii.edu/mailman/listinfo/luau
>