It's humungously overpowered :)
The proxying can be a bit harsh at times though. As I said, it is on a
1gbit link to the LAN.
--MonMotha
Dustin Cross wrote:
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
_______________________________________________
LUAU mailing list
[EMAIL PROTECTED]
http://videl.ics.hawaii.edu/mailman/listinfo/luau
