Re: Inconsistent IO performance

2010-08-14 Thread Ian Smith
On Fri, 13 Aug 2010, Kevin Oberman wrote:
 > > Date: Sat, 14 Aug 2010 11:06:58 +0800
 > > From: TJ Varghese 
[..]
 > > 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

2010-08-14 Thread Pieter de Goeje
On Saturday 14 August 2010 05:57:51 Kevin Oberman wrote:
> > Date: Sat, 14 Aug 2010 11:33:57 +0800
> > From: TJ Varghese 
> >
> > > 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=2&t=13036&start=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

2010-08-14 Thread Christian Walther
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)

2010-08-14 Thread Adrian Chadd
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

2010-08-14 Thread Roland Smith
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.
> 
> >   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.) 
> 
> 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:  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