Date: Fri, 10 Jan 97 10:11:23 CST From: Joe Greco <jgreco@solaria.sol.net> To: SimsS@IBM.Net Cc: scrappy@hub.org, joe@via.net, freebsd-hackers@freebsd.org Subject: Re: CCD questions (news server) Message-ID: <199701101611.KAA17513@solaria.sol.net> In-Reply-To: <199701101335.NAA140969@smtp-gw01.ny.us.ibm.net> from "Steve Sims" at Jan 10, 97 08:34:14 am
next in thread | previous in thread | raw e-mail | index | archive | help
> For what it's worth, I've been playing (in the strictest sense of the word, > not actually *knowing anything* about ccd ;-) with CCD and various interleave > values. > > Empirically (using `iozone`) I've decided that performance appears to > "balance peak" (i.e.: best tradeoff between optimized read and optimized > write speeds) when the interleave value specified will *not quite* fill the > on-drive cache. > > So, with a farm of el-cheapo antique drives w/128K on-drive cache, I used an > interleave of 240. > > Tweaking the interleave value higher bumps up the write performance but > reading suffers. Moving the interleave downward didn't significantly help > reading or writing performance. (Although some settings caused the array to > lose, big time!) > > N.B.: This is in a plain-vanilla 4-drive, one controller, ccd configuration: > No mirroring, no CCDF_SWAP or CCDF_UNIFORM flags. I'd have to play some to > benchmark these. > > I briefly tested a configuration with dual Seagate 12550N's, one with 512K > and one with 1M (!) on-drive cache and the result was similar; performance > "balanced" best with an interleave of around 1000 (which is just under the > size of the smaller cache). > > YMMV, I learned a "lot" by just playing with the values and newfs'ing. This is all well and fine if you are interested in bandwidth out to your drives. If you want to be able to write a 100MB file as quickly as possible - great! But in Usenet news, you don't CARE about that as the average transfer size is pretty small, and therefore "pretty short", and going twice as fast results in "half of pretty short" time to do an operation. What you REALLY want is to let each drive do different operations. Let's say you have a big news box and 100 readers, and they are all pounding on six disks. If you use a small interleave, what will happen is that several drives will be involved with each individual reader access. Let's pretend that the number is three... three drives have to move their heads to do a single access for a single reader. You still have three drives free so another reader can also be accessing an article. So if you have 100 requests, you need 50 units of time to satisfy those requests. Now let's say you do it my way. The odds switch and favor a single drive being able to complete a file access for a single reader. That means that there are five drives available, so five other clients can be getting their articles off of other drives. So if you have 100 requests, you need about 16 units of time to satisfy those requests. In my book, if it takes less time to satisfy the same number of requests, it is a win :-) You don't give a damn about bandwidth. It is useless for a news spool. You want concurrency. You get that with large stripe sizes. Please read the mailing list archives for my long dissertations on this very subject! ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701101611.KAA17513>