Date: Sun, 22 Apr 2001 12:01:20 -0500 From: Andrew Hesford <ajh3@chmod.ath.cx> To: Seth <aberrant@superconductor.rush.net> Cc: Andrew Hesford <ajh3@chmod.ath.cx>, freebsd-questions@freebsd.org Subject: Re: ATA100 read/write perofrmance disparity Message-ID: <20010422120120.A26375@cec.wustl.edu> In-Reply-To: <20010422124619.A29944@superconductor.rush.net>; from aberrant@superconductor.rush.net on Sun, Apr 22, 2001 at 12:46:20PM -0400 References: <20010422114836.A6234@superconductor.rush.net> <20010422110843.A99388@cec.wustl.edu> <20010422124619.A29944@superconductor.rush.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 22, 2001 at 12:46:20PM -0400, Seth wrote: > 268435456 bytes transferred in 34.603850 secs (7757387 bytes/sec) > 0.054u 8.725s 0:34.65 25.3 89+263k 19+2050io 0pf+0w > > > > For a real disk I/O benchmark, try bonnie. It's in the ports tree. > > > > Using bonnie++ with -s256, I get: > > Using uid:65534, gid:65534. > Writing with putc()...done > Writing intelligently...done > Rewriting...done > Reading with getc()...done > Reading intelligently...done > start 'em...done...done...done... > Create files in sequential order...done. > Stat files in sequential order...done. > Delete files in sequential order...done. > Create files in random order...done. > Stat files in random order...done. > Delete files in random order...done. > Version 1.01 ------Sequential Output------ --Sequential Input- --Random- > -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- > Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP > 256M 7260 83 7501 22 2845 11 6137 87 25597 47 124.6 2 > > The CPU appeared pegged at around 95% sys for most of the "Create files" and > "Delete files" tests. Other times, it was a mix of sys/int and idle. > This indicates to me that the CPU is the limiting factor here -- it is, > after all, a relatively sluggish PPro 200. Is this a sane conclusion to > reach given the evidence? During the dd write, your system is being used less than 25% of the time. This is absolutely horrible. Recall that, for my small-block write, my CPU was being used >50% of the time, and I had Mozilla building in the background. This means my CPU usage was much higher. This must be a CPU bottleneck. Make sure every daemon you can live without for five minutes (while you test throughput) is dead. Something has got to be using that extra CPU time. I agree about bonnie/bonnie++, the output is garbled. I was able to clean it up above by deleting one space on each output line, so that the columns don't spill off the ledge. If the writers of the software had done this at first, it would be a lot easier to read. Something is definitely wrong. On the I/O writes where you get 6000-7000 K/sec, I get 9000-13000 K/sec. And mine is a UDMA-4 (UltraATA/66) controller and drive pair. On the Block I/O, where you get 25000 K/sec, I get 86000. I have a 733MHz PIII, 256K L2 cache. The partitions I tested with bonnie were 7 and 10G FFS with soft updates. The block and fragment size are the default, 8K block and 1K fragment. Each partition has 16 cylinders per group. I have 320M PC-100 SDRAM in the system. The spin rate of my disk is 7200 RPM. The problem could be a processor issue, a PCI bus issue, a RAM issue, or any number of things. I really have no idea why your performance is so bad. -- Andrew Hesford ajh3@chmod.ath.cx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010422120120.A26375>