Date: Wed, 7 Oct 1998 21:25:23 +0100 From: James Mansion <james@westongold.com> To: "Christopher G. Petrilli" <petrilli@amber.org>, freebsd-smp@FreeBSD.ORG Subject: RE: hw platform Q - what's a good smp choice these days? Message-ID: <32BABEF63EAED111B2C5204C4F4F502017F9@WGP01>
next in thread | raw e-mail | index | archive | help
Well ... I'm going to disagree with you. At least to some extent. It is undeniable that SCSI is (at least in theory) a great deal more sophisticated and that an IDE solution (even a UDMA one) will tend to eat more CPU, and have more queueing of IO requests in the system. I'm not going to argue that SCSI isn't better in an absolute sense. But some people are dramatically oversimplifying the issue, and 'opposition' to IDE and snide remarks are as useless (and as childish and stupid) as similar comments about Microsoft. However, > -----Original Message----- > From: Christopher G. Petrilli [mailto:petrilli@amber.org] > difficult to guess as to the best mixture. I will hazard this > statement, *IF* the system is not a pure CPU server (i.e. Beowulf, > whatever), then it's I/O bound, I promise you :-) I've been building No. Absolutely no. I promise you ;-) > everything from mainframes to Sun Starfires to little embedded > machines, and ALWAYS they are I/O bound. When you think you've fixed No they aren't. Maybe your experience is that they are, but mine is not. It may be that I am spoilt having worked primarily in investment banks. (Lets be clear, I am objecting to your use of 'ALWAYS') My observation has been that systems that have been sensibly configured are net IO bound or CPU bound, but rarely disk transfer bound. Sometimes seek bound, I grant. My experience is mostly with trading systems for derivatives. These tend to behave more like decision support systems than transaction processing systems. On the Sybase systems I'm most familiar with, CPU becomes the limiting factor quickly - even on mullti-CPU 'big iron' from Sun and HP. Where this hasn't been the case, some minor tuning to avoid table scans and help index coverage has been enough to bring the working set well within affordable RAM. On web servers, it is usually the case that you are either bound on your ISP connection, or are CPU bound on CGI/ISAPI/whatever running dynamic services. FTP and some file serving I guess can have very large working sets and be IO bound - fine. None of the systems I've worked with have been very dependent on non-transactional disk stores. From what I can tell, the sensitivity of news servers to disk performance is because news servers tend to use naff software that works like a file server rather than a DBMS. And hopefully the soft writes will dramatically improve things if the memory is there for buffering and the traffic is bursty. If you're running a turnkey system with a bunch of users I'd still think very carefully before going with the knee-jerk reaction that its not a single user client and should be SCSI. In this country a competitive price for a fast-wde 9GB 7200RPC SCSI drive is about UKP350. An 8GB UDMA IDE is less than half that. The UKP200 difference will buy you 192MB of memory, and the controller is probably right there too. UKP200 gets you a 330MHz CPU if you have the motherboard for it, as an alternative. If the 192MB is the difference between swapping and running from RAM with a good deal of file system cached, its the smart way to go. There's no simple answer to which is better. A definitive 'servers need SCSI' is a gross oversimplification - if you're likely to be seek bound then you would be well to see how many bus-master IDE controllers you can handle, and use multiple 4GB or 8GB UDMA IDE spindles - they're a steal. My current and previous machines - apart from the portable I'm using to write this - have been SCSI. Its served me well as a platform for handling decent CD-ROM and DAT as well as disk. But running out of disk space has always been more of a headache than waiting an extra couple of seconds when the system is busy, and I don't know many fileservers that don't suffer from this. > that they're memory bandwidth bound, they're never CPU bound. > > Having said that, assuming this machine is aimed at general purpose > web/etc, I would recommend getting a dual CPU board, but if > you have to > cut costs, NEVER cut it in the I/O subsystem on a server (clients are > different stories). Also, more spindels is better, and I > often try and > find a small drive for my root drive, and use another small drive for > swap, just to keep it off everything. This is again an I/O at all > costs design, and I'm known to put 3 SCSI busses on a machine that has > any load. I agree that cutting seeks by splitting IOs is a good idea, and any database tuning book will tell you that. But for any budget, you can afford way more IDEs and if you're performance bound on your swap device then you really have screwed up the way the system budget was spent. > > Note that anythign that is heavily disk bound, i.e. database, or news > servers, should put even more emphasis on the I/O side of the > house---something unfortunately that PCs still are pretty > miserable at. Not sure this is a wise thing to say. FreeBSD does rather well at controlling IO and you have a hard time getting mid-range Suns and HPs to hit disks as hard as a PC will, simply because its so much easier to get 80MB/s subsystems and disks for your PC. > > Chris > > > James > > > > > -----Original Message----- > > > From: Steve Passe [mailto:smp@csn.net] > > > > > SNIP > > > > > > > If you are going to multiple disks and have the money, > SCSI is the > > > > way to go. But IDE disks are so much less! For a single drive, > > > > the new IDE DMA driver does as well as SCSI. > > > > > > I agree with this point, but I think of SCSI as much more > than a disk > > > controller. I typically hang a jaz or zip drive off it, > plus a SCSI > > > DAT tape for backup, or possibly a scanner, or a CD-ROM > drive, or ... > > > > > > -- > > > Steve Passe | powered by > > > smp@csn.net | Symmetric MultiProcessor FreeBSD > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-smp" in the body of the message > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-smp" in the body of the message > > -- > | Christopher Petrilli > | petrilli@amber.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32BABEF63EAED111B2C5204C4F4F502017F9>