Date: Sat, 2 Sep 1995 06:33:26 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: vernick@CS.SunySB.EDU (Michael Vernick) Cc: freebsd-hackers@FreeBSD.org Subject: Re: 4GB Drives Message-ID: <199509021333.GAA15713@gndrsh.aac.dev.com> In-Reply-To: <199509020338.XAA24086@cs.sunysb.edu> from "Michael Vernick" at Sep 1, 95 11:38:51 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > >You see, in modern workstation disk drives you have something called > >spindle sync. Well, when you set up spindle sync you have 2 modeselect > >values you tweak. One bit says who is the sync master and who are > >the sync slaves. Then for each slave drive you tweak another value > >that is used to offset the spindles from perfect sync so that the I/O > >of block zero of a track on drive 0 of a stripe set has just finished > >the scsi bus transfer when block zero of a track on drive 1 is about to > >come under the heads. > > Why do you want the data under the heads when the SCSI bus becomes > free? Wouldn't you rather have the data already in the disk cache? If > the bus is free and the disk is transferring from the medium and out > over the bus, the bottleneck is the disk transfer rate. However if > the data had already been in the cache it can go at SCSI bus speeds. Your thinking to simple, if the data was in the cache when the I/O hit the drive it would immediatly go to data phase preventing me from issuing another I/O to the next drive. I actually _dont_ want the drive to come on the bus yet. I need to be able to get all transfer operations to the drives before _any_ drive grabs the bus for a data transfer. This causes all drives to operate as a parallel unit. To simplify my problem with this I have gone to one drive per controller for developement purposes, but am still trying to work the issue of how do I make 4 drives on one bus all operate such that I can get the commands to all 4 drives before anyone of them grabs the bus for what is a rather long data transfer phase. > As for the 85% bandwidth over the SCSI you have achieved, that is the > maximum that I can get. I am using more than 1 bus, each bus itself is only seeing a 44% load. > Rather than worry about seeks and latency > delays I simply request the same data over and over from the disks. I > bypass the file system code and make sure each request (64K, or 128 > sectors) goes back to the disk. However, the data is already in the > disk cache thus incurring no seeks, nor rotation delays. With 3,4 and > 5 disks on a single controller it maxes out at 8.5MBsec. Thus, the > controller, disk and bus overhead must account for the other 15%. If > you can get rid of that overhead, let me know. :) I can't eliminate that over head, but I sure can make it seem to be gone by using a pipeline effect. Problem is getting the timing of things right so that it is really a pipeline is rather difficult. I am not going to continue this thread much in public, it is takeing my time away from doing the research. Let it be known that I am rather deaply intrenched in this stuff and most of what is being talked about here I have a pretty much covered myself. I also have a bit of background in the hardware way of doing this stuff ala Auspex boxes where much of this technology is buried in the firmware of thier disk procesing boards (not really a controller by anyones standards, these are very smart boards). I am attempting to duplicate and reverse engineer as much of this technology as I can into a software model that will work with a specific controller/ set of hard drives initially and then expand upon that model to generalize it a bit, but it will always take deep study of the specific drives and controllers to properly tune it to pipeline correctly and operate at maxium utilization. It involves the study of latencies at all points of the pipe and control over the sequence of events to make it all humm. It may seem at times that I am asking about how to do some really counter performance types of things (turning off tag queueing and disconnect/reconnect) but this is being done to study fundemental latency delays without the side effects of these features. It is not my intention to leave them off in the final model. But without methods to study these fundemental things it makes derivation of good models very hard. I will probably have to use a software queueing modeling system to study the more complex effects these will have once they are understood at the fundemental level to derive full models. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509021333.GAA15713>