[luau] INFO: Heavy duty storage needs
Dustin Cross
dusty at sandust.com
Thu May 2 19:58:12 PDT 2002
How much mail does it send? That is a monster machine for just mail and
proxy, unless you has TONS of users!
Dusty
> 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
>>
>
>
> _______________________________________________
> LUAU mailing list
> LUAU at videl.ics.hawaii.edu
> http://videl.ics.hawaii.edu/mailman/listinfo/luau
More information about the LUAU
mailing list