Date: Sat, 11 Dec 1999 13:26:07 -0700 From: Brett Glass <brett@lariat.org> To: David Scheidt <dscheidt@enteract.com> Cc: Jay Nelson <noslenj@swbell.net>, Terry Lambert <tlambert@primenet.com>, chat@FreeBSD.ORG Subject: Re: dual 400 -> dual 600 worth it? Message-ID: <4.2.0.58.19991211131141.046bc880@localhost> In-Reply-To: <Pine.NEB.3.96.991211120959.96439B-100000@shell-3.enteract. com> References: <4.2.0.58.19991210230453.046806e0@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
At 11:32 AM 12/11/1999 , David Scheidt wrote: >For the highest level of performance, you really must have each disk on its >own IDE channel. I don't have much experience with machines with lots of >IDE disks. The most I have worked with is 4 IDE disks, with two on the >onboard controller and two on a PCI card controller. The machine didn't >seem to do as many IO transactions per second as a similiar machine with 4 >LVD SCSI disks. AFAIK, IDE doesn't really have an equivalent of disconnect/reconnect (though some vendors have tried to implement something like it). So, by having more than one drive per interface, you're likely to slow things down because one drive must wait for the other. The IDE interface is cheap TTL, though -- a lot cheaper than SCSI. So you really CAN have an interface per drive at reasonable expense. At that point, I suspect that the smartness of the OS, and the speed of the host CPU, would determine performance. I sometimes long for the days of ESDI, where the host could control EVERYTHING about the way the drive was read and written. (I did some experiments which involved positioning the head on a blank track when a write was expected, then writing the data to the very next sector that came along while simultaneously updating an intention FIFO for the metadata on a different spindle. The metadata itself was updated later, so the intention log kept things from getting out of sync due to power loss. You could pull the plug on that machine when the disks were grinding away and never lose a thing.) I also wrote some pretty good disk cache software during that era -- mostly in assembler. I decribed how I did it in an article in BYTE circa 1985, and even threw in a tool that let reader test the effectiveness of different algorithms in real life situations. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.0.58.19991211131141.046bc880>