On Mon, 16 Feb 2004, Orlando Andico wrote: > On Mon, 16 Feb 2004, ian sison (mailing list) wrote: > .. > > > translation.. with SCSI you can put at least 10 drives on a single > > > controller, assuming the application has lots of small files and lots of > > > random seek (true of Squid and email servers). > > > > True, but that discounts optimization done on the OS level as well the > > firmware level which can induce more data to be sent to the bus than the > > over all average 400K/second you mentioned. > > Yes that's true, but in reality the optimizations don't result in a > 100-fold increase of performance. and in SOME cases (e.g. running Oracle > on Linux, which has no KAIO support in the stock kernel) you WILL be > limited by the I/O's per second because a commit causes a flush which > means the kernel can't optimize the I/O. > > On a "saner" load, I've actually done the following braindead benchmark: > > cd /filesystem2 > time tar zxf /filesystem1/linux-2.4.24.tar.gz > > since you know how many files are contained in the tarball, and the total > size (unzipped) of the thing, you can get a good idea of the overall > performance of the drives. filesystem1 and filesystem2 have to be on > separate drives. > > you can argue that CPU is also being used, but with a modern CPU the > utilization for untar-ing and g-unzipping is small. > > wth this benchmark, i've found that the maximum I/O's per second max out > at around 120, and the raw speed to the disk is around 4-6MB/sec. so > that's a factor of 10 higher than my earlier figure, but still a factor of > 10 less than the hardware platter speed. > > the only way (i've found) to get platter speed is by doing > > time dd if=/dev/zero of=/filesystem1/big_file bs=1M count=1000 > > :) which is a very contrived example that doesn't reflect a real work-load > at all. > > bottom-line, two drives on an Ultra-Wide SCSI bus won't saturate the bus > under any realistic work load. Maybe my "10" figure was too optimistic, > but you CAN accommodate 10 drives easily. >
Agree. Your benchmarks speak for themselves. However is it also your point that you can _never_ get close to platter speed in a deployed system such as holden's server? Meaning you can never, ever get cache hits, or elevator optimizations resulting in a burst of data greater than the averages above? I premise that, on occasion, (not really that often, though) you will get bursts of data nearing the platter speed (or maybe even more if it's a cache hit!). And i say that if it's a raid 0+1, disk you may be getting elevator bursts or cache hits from multiple drives at that. This means you hit the limit of your bus, and at that point in time, when you are actually benefitting from theses optimizations, you hit the bus limit. One may say that the occasions these may happen may be so few it really would not matter. I say unless there is a benchmark that can take these situations into account and prove the claim correct, _and i have the xtra cash_ i'd go with multiple controllers, and cover all bases instead. -- Philippine Linux Users' Group (PLUG) Mailing List [EMAIL PROTECTED] (#PLUG @ irc.free.net.ph) Official Website: http://plug.linux.org.ph Searchable Archives: http://marc.free.net.ph . To leave, go to http://lists.q-linux.com/mailman/listinfo/plug . Are you a Linux newbie? To join the newbie list, go to http://lists.q-linux.com/mailman/listinfo/ph-linux-newbie
