Re: Inconsistent IO performance
On Fri, 13 Aug 2010, Kevin Oberman wrote: Date: Sat, 14 Aug 2010 11:06:58 +0800 From: TJ Varghese t...@tjvarghese.com [..] You're using a laptop with 2 HDDs, so does that mean you're using the Ultrabay for the 2nd HDD? Perhaps anything connected to that drops down to ATA33 (pure speculation on my part) since it was designed for optical drives ...dmesg/atacontrol logs would be useful here. You may want to try dd with the of=/dev/null instead to remove the 2nd variable and benchmark solely the read speed of the 1st hdd. For this test I get a very consistent 34.75 MB. (1000 10M blocks). Distressingly low when there is almost no seek activity. Nope, it is running at UDMA100 using a SATA-PATA converter. (The ICH6 controller is SATA.) But that was a good idea. For some sort of comparison, on a T23 (1133MHz P3-M, ICH3 PATA, Fujitsu MHV2120AH 120GB 5400rpm UDMA100 drive, single device on channel, 768MB RAM), I do better than that: # dd if=/dev/ad0 of=/dev/null count=1024 bs=10M gets, over two runs, just either side of 40,500,000 bytes/s. Same result, just slightly better, with bs=512M count=20. (I also tried bs=1024M count=10, but that was really dumb with 768MB RAM :) But with if=/dev/ad0s4 (starts about 70% into the disk) just either side of 29,200,000 bytes/s. All tests show 0.5-0.7% CPU, so hardly a factor, and with that usage powerd kept the CPU at 733MHz. Could be as you suggest, the SATA to PATA converter is a bottleneck? I see mine has acoustic management on also; let us know if it matters? Oh, and that's on 8.0R, about to be brought up to 8.1-S, if relevant. cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Inconsistent IO performance
On Saturday 14 August 2010 05:57:51 Kevin Oberman wrote: Date: Sat, 14 Aug 2010 11:33:57 +0800 From: TJ Varghese t...@tjvarghese.com The deviation in your disk I/O isn't a major surprise (to me anyway), given the system specs. What *does* surprise me is your abysmal I/O speeds in general. 18MB/sec min, 24MB/sec max?! ICH6-M can do a lot more than that. Something isn't right. it's possible that the hw is...suboptimal. From a 2005 post, http://forum.thinkpads.com/viewtopic.php?f=2t=13036start=0 Check out the link to the hddbenchmark, http://img57.imageshack.us/img57/6430/hddbenchmark1no.jpg Thanks, TJ! I guess the disk IO on these boxes simply sucks. Looks like the 34.75MB/sec sequential read speed is all I can hope for. I'm guessing the SATA-PATA converter is to blame. Oh, well. But all of this does not address my real question, why is performance so inconsistent? I agree that it sucks, but that does not explain why it suck so much worse on one run than another. I'm still baffled. My backup disk normally odes not leave my office storage cabinet except when it is in the computer being written, so I don't have it handy ATM. I will try a couple of things on Monday, though. Perhaps the measurements are taken while the laptop is on a different (less/more stable) surface each time? Disk vibrations could account for the differences. Check out this cool video from Sun: http://news.cnet.com/8301-13556_3-10138666-61.html No idea how this affects sequential read and write workloads however. -- Pieter de Goeje ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: zfs destroy snapshot doesn't free space
Hi, what do you see when you cd to /var/.zfs? There should be a snapshot directory there. Is there any contents in it? Regards Christian Walther PS: Sorry for the repost, forgot to hit reply all (and fixed a bug, btw. It should be /var/.zfs insead of .zsh, of course.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [CFT] if_ath updates - ar5416 (macbook pro, etc)
Hi, I've committed a couple more small AR9160 related fixes. Please test if_ath if you're using AR9160 in any mode (hostap, adhoc, station) and provide some feedback. Thanks, Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Inconsistent IO performance
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 1048576 bytes transferred in 138.304953 secs (75816229 bytes/sec) 1048576 bytes transferred in 139.125501 secs (75369073 bytes/sec) 1048576 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. 1048576 bytes transferred in 122.625997 secs (85510090 bytes/sec) 1048576 bytes transferred in 126.081170 secs (83166741 bytes/sec) 1048576 bytes transferred in 126.101845 secs (83153105 bytes/sec) Which is about 10% faster than on the desktop. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpPCf0xQAOsM.pgp Description: PGP signature
