AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090218113854.73ee3e48@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:exch1.onstor.net
NSV:
SSH:
R:<patrick.haverty@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@exch1.onstor.net/INBOX	0	2779531E7C760D4491C96305019FEEB5185204DC2A@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 18 Feb 2009 11:39:19 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: Patrick Haverty <patrick.haverty@onstor.com>
Subject: Re: Finding Leopard Performance
Message-ID: <20090218113919.5fdf4042@ripper.onstor.net>
In-Reply-To: <2779531E7C760D4491C96305019FEEB5185204DC2A@exch1.onstor.net>
References: <20090217103010.5e5d4c27@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB5185204DC2A@exch1.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Definitely running it on clients would be instructive.  There is
a way to sync up the clients, too, if that's necessary.  Use the at(1)
command to start bonnie, and make sure the clients all have their time
synchronized with ntp to the same time.  Should work pretty well.

Cheers,

a

On Tue, 17 Feb 2009 16:53:52 -0800 Patrick Haverty
<patrick.haverty@onstor.com> wrote:

> So, would running the bonnie++ from a client, across a network, add
> the NFS/TCP/IP overhead to the test results?  I guess even if it
> does, there's no good way to sync up the clients to know that they
> are reading or writing at the same time.  Damn, We need 10GbE.
> 
> Thanks!
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Tuesday, February 17, 2009 10:30 AM
> To: Patrick Haverty
> Cc: dl-Leopard
> Subject: Re: Finding Leopard Performance
> 
> On Mon, 16 Feb 2009 17:06:24 -0800 Patrick Haverty
> <patrick.haverty@onstor.com> wrote:
> 
> > -Andy Wrote-
> > 
> > On page 5 & 6, it looks like something got funky with the cached 8k 
> > random writes.  Since it's cached, the two should be the same, just 
> > like all the other cached tests (is this "cached" v. "uncached"
> > thing a ZFS or Slowaris thing?  I've not seen this before).
> > 
> > PJH - I was just thinking, maybe my assumption that the random
> > write of a file half the size of the system DRAM would "cache" into
> > the DRAM is off the mark and a cached write is not really
> > happening.  Is this what you were trying to point out?
> 
> No, my thought was possibly a number got transcribed wrong or digits
> kicked or something more along those lines.  Or something different
> happened during that test that wasn't happening during the other
> cached tests.  There's an obvious trend with the cached tests, and
> that one test doesn't follow it, so I just wanted to point it out.
> 
> Cheers,
> 
> a
