AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090218122350.5e5fd125@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	2779531E7C760D4491C96305019FEEB5185204DE04@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 18 Feb 2009 12:24:19 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: Patrick Haverty <patrick.haverty@onstor.com>
Subject: Re: Finding Leopard Performance
Message-ID: <20090218122419.4a0ad59a@ripper.onstor.net>
In-Reply-To: <2779531E7C760D4491C96305019FEEB5185204DE04@exch1.onstor.net>
References: <20090218113919.5fdf4042@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB5185204DE04@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

A second or two won't make any real difference.  I could also write you
a little shell script that would synchronize everything, if you wanted.

Cheers,

a


On Wed, 18 Feb 2009 11:42:53 -0800 Patrick Haverty
<patrick.haverty@onstor.com> wrote:

> Thanks for the tip on syncing the start time.  I've just been
> clicking window to window and hitting enter.  Quick, but still may be
> a second or two diff. 
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Wednesday, February 18, 2009 11:39 AM
> To: Patrick Haverty
> Subject: Re: Finding Leopard Performance
> 
> 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
