Date: Sun, 15 Aug 2010 12:37:03 -0700 From: "Kevin Oberman" <oberman@es.net> To: Roland Smith <rsmith@xs4all.nl> Cc: stable@freebsd.org Subject: Re: Inconsistent IO performance Message-ID: <20100815193703.DA6461CC3A@ptavv.es.net> In-Reply-To: Your message of "Sun, 15 Aug 2010 00:07:40 %2B0200." <20100814220740.GA64697@slackbox.erewhon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Sun, 15 Aug 2010 00:07:40 +0200 > From: Roland Smith <rsmith@xs4all.nl> > Sender: owner-freebsd-stable@freebsd.org > > On Sat, Aug 14, 2010 at 02:36:31AM +0200, Roland Smith wrote: > > On Fri, Aug 13, 2010 at 01:36:12PM -1000, Clifton Royston wrote: > > > > Both figures seem quite low to me? I cannot exactly reproduce your test, > > > > because I don't have an empty second disk handy, but doing > > > > > > > > dd if=/dev/zero bs=1m count=100 of=/tmp/foo > > > > > > With a total write size of 100MB, aren't you just testing speed of > > > writing into cache RAM this way? I think you need to write amounts > > > dramatically greater than the total size of the RAM to get values which > > > appropriately measure disk speed. > > <snip> > > > This also supports that theory - off the top of my head, maximum > > > theoretical possible write throughput to a similarly sized 7200rpm > > > drive should be 70MB/s (buffer to disk data transfer rate according to > > > WDC's specs.) <http://wdc.com/en/library/sata/2879-701277.pdf>; > > > > Ok, so I tried this; > > > > dd if=/dev/zero of=/tmp/foo bs=10M count=1000 > > > > 10485760000 bytes transferred in 138.304953 secs (75816229 bytes/sec) > > 10485760000 bytes transferred in 139.125501 secs (75369073 bytes/sec) > > 10485760000 bytes transferred in 136.149871 secs (77016305 bytes/sec) > > > > Which is around 72 MiB/s with filesystem overhead, which sounds about > > right. The drive was making plenty of noise. The point is that it is _way_ > > more than the 18-22 MiB/s on a raw disk that Kevin is getting. > > > > I'll try the same on my laptop topmorrow and see what that gets me. This desktop > > machine is ICH7 with ata(4), laptop is ICH9 with ahci(4). > > Figures from the laptop running 8.1-RELEASE amd64, ahci driver with the > following harddisk; > > ada0: <ST9320423AS 0002SDM1> ATA-8 SATA 2.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) > > Running the same test; > > dd if=/dev/zero of=/tmp/foo bs=10M count=1000 > > Gives the following results. > > 10485760000 bytes transferred in 122.625997 secs (85510090 bytes/sec) > 10485760000 bytes transferred in 126.081170 secs (83166741 bytes/sec) > 10485760000 bytes transferred in 126.101845 secs (83153105 bytes/sec) > > Which is about 10% faster than on the desktop. OK. It's pretty clear that disk IO is terrible on this system. I suspect it's the SATA/PATA converter that is the throttle. In any case, nothing is going to help much when the best sequential read speed is only 34 MB/sec. I suppose something in the ATA driver may be an issue, but I doubt it will improve. I still have no explanation for the variation. It's not vibration. Some of my best times were while the system was sitting in my trunk while commuting from my home to work. So have some of the worst. I can only hope that my next laptop, which should have ACHI, will improve the situation. I'll probably be getting a new laptop in the spring, so it won't be too long. Almost time to start trying to figure out what to buy. Thanks to everyone who made suggestions and offered ideas. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100815193703.DA6461CC3A>