Date: Fri, 13 Dec 1996 00:51:35 +0100 From: se@freebsd.org (Stefan Esser) To: lada@ws2301.gud.siemens.co.at (Hr.Ladavac) Cc: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies), freebsd-hackers@freefall.freebsd.org Subject: Re: ccd - some measurements Message-ID: <Mutt.19961213005135.se@x14.mi.uni-koeln.de> In-Reply-To: <199612121529.AA154004578@ws2301.gud.siemens.co.at>; from Hr.Ladavac on Dec 12, 1996 16:29:38 %2B0100 References: <199612120805.JAA25514@gilberto.physik.rwth-aachen.de> <199612121529.AA154004578@ws2301.gud.siemens.co.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 12, lada@ws2301.gud.siemens.co.at (Hr.Ladavac) wrote: > E-mail message from Christoph Kukulies contained: > > Quantum Atlas 2GB, PPRO-200/256, 32MB > > > > Bonnie result: > > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > > PPRO 100 5006 43.3 4959 11.3 2290 6.3 5022 43.7 4890 7.0 87.1 1.9 > ^^^^ ^^^^ > These percentages are bad. Should be higher. It > means that the machine is IO limited even in the > per char test which does getchar() and should be > CPU limited instead. This thing needs a faster > disk or ccd *badly* No, it seems the test was run on a file system that restricted the data rate to just about 5MB/s. Both the per char and the block I/O results are within a 1% window around 4950KB/s ... There are not so many faster disks than the Atlas (well, the IBM DHCS, the Quantum Atlas II, and the latest Seagate drives seem to go from 10MB/s to 7MB/s sustained, outer to inner tracks). But what is bad about having half the CPU available to do some real work :) If you are doing compilations, then the system has half a PPro-200 for the compiler, while reading the sources at 5MB/s. That's the way it is supposed to be (IMHO) ... > > CCD Amd K5/PR-133, two ncr/pci controllers, 2 Quantum Tempest 3.2 GB (slow) > > > > I/L > > 8 100 2103 39.5 2118 10.9 828 7.0 2555 39.6 2324 13.6 58.9 4.3 > > 96 100 4312 69.6 4404 19.7 2414 19.5 6359 93.6 6486 34.4 67.8 4.1 > ^^^^ ^^^^ > Getting better. Okay, it's a slower CPU, but it's > still IO limited in getchar(). You can get some more > out of the box. Same here: The CPU is usually limiting the per char results, but with CPUs getting faster and faster we just have to get used to have systems, that have cycles left, when all I/O channels are busy. Reading is much faster than writing, here, and I'd try to get the write spead up. But the drives used have very small caches, which don't hold even a single track of data. It is possible that with tags disabled and write caching on (ie. early write success status delivery) the writes will become as fast as reads ... It would be really interesting to compare bonnie throughput with and without tags for this CCD file system ... Gruss, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19961213005135.se>