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 >>> [EMAIL PROTECTED] >>> http://videl.ics.hawaii.edu/mailman/listinfo/luau >>> >> >> _______________________________________________ >> LUAU mailing list >> [EMAIL PROTECTED] >> http://videl.ics.hawaii.edu/mailman/listinfo/luau >> > > > _______________________________________________ > LUAU mailing list > [EMAIL PROTECTED] > http://videl.ics.hawaii.edu/mailman/listinfo/luau
