Date: Wed, 7 Oct 1998 20:13:51 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: petrilli@amber.org (Christopher G. Petrilli) Cc: freebsd-smp@FreeBSD.ORG Subject: Re: hw platform Q - what's a good smp choice these days? Message-ID: <199810072013.NAA14751@usr08.primenet.com> In-Reply-To: <19981007111054.39986@amber.org> from "Christopher G. Petrilli" at Oct 7, 98 11:10:54 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Its all very well, but SCSI disks are a LOT more expensive than IDE > > > ones. No, they aren't. > > > Might be faster IO per drive with SCSI, but I'd rather have twice the > > > capacity and spend the remainder on more RAM. The I/O is faster by a factor of N, where N is the number of tagged commands supported by the drive. For IBM drives, SCSI can be as much as 64 times faster than IDE because it can be as much as 64 times more concurrent. > > Well, IDE tends to use significantly more CPU for IO than SCSI. False. This applies only to PIO based IDE controllers. The controllers that support DMA (or "Ultra DMA") can transfer with similar load to their SCSI counterparts. That's burst rate. For sustained rate, concurrency is an issue; see abbove for "tagged command queueing". > > Isn't that what does all the DMA work for IDE? Nope. See above. Either you use PIO, where the transfers are via CPU copies, or you use DMA, where the transfers are via bus mastering, and the CPU is idle during the transfer. > > If you have cycles to burn, why pay for an SMP configuration? Good question, but not relevent in this context, since DMA IDE doesn't burn cycles (only PIO DMA). > > I wouldn't recommend IDE on anything but a single user machine, > > because of the synchronous access to the drives. (Has the > > sycnhronous drive access been dropped from EIDE? I don't follow > > IDE developments much.) EIDE supports tagged command queuing. EIDE drives do not support tagged commands, however, so it's rather irrelevent. > Well, even under SCSI, most people run it in syncronous mode because This is a different meaning of "synchronous". Tagged commands aren't asynchronous, they're concurrent. Probably the source of the confusion. > it's faster unless your kernel supports full blown tag-command queing, > and the drive does reordering, AND you're doing small transfers and Drive reordering is bad for cached writes, and OK for tagged commands, so long as the data is committed to stable storage in the correct order. > high transaction rate. This is kinda the mainframe model of I/O---you > send out a bunch of requests to drives for information, then you let > the drive respond in whatever order is best given it's current > "state".... Yes. And the High end PC server model, as well. > This is kinda why spindle sync isn't used much that I cna tell, outside > of the ultra-high end. Actually, Rod Grimes distributed patches for spindle sync to be used with CCD on FreeBSD about two years ago. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199810072013.NAA14751>