AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090218140844.49f5af75@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	2779531E7C760D4491C96305019FEEB5185204DE6C@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 18 Feb 2009 14:09:35 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: Patrick Haverty <patrick.haverty@onstor.com>
Subject: Re: Finding Leopard Performance
Message-ID: <20090218140935.29343ffd@ripper.onstor.net>
In-Reply-To: <2779531E7C760D4491C96305019FEEB5185204DE6C@exch1.onstor.net>
References: <20090218122419.4a0ad59a@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB5185204DE6C@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

Hey, I like a guy who's happy just to get a tip!  Here's a strawman
type thing:

on every client:

========= begin shell script ==============
#!/bin/sh

socat listen for a udp packet on port 666
bonnie -foo -bar
=========  end shell script ==============


then, on a machine on the same network, or one of the networks, that
the clients are on:

socat send udp packet to port 666 on IP_BCAST_ADDR

IP_BCAST_ADDR being a variable that is equal to the broadcast address
for the subnet, or one of the subnets, all the clients are on.

You can look up all the info on the socat command here:

http://ripper.onstor.net/cgi-bin/man/man2html?query=socat



On Wed, 18 Feb 2009 13:33:38 -0800 Patrick Haverty
<patrick.haverty@onstor.com> wrote:

> An example of a shell script that could run a command on four clients
> would be a godsend to me.  I've had some success writing scripts for
> one client, but I don't have a clue as to how sync four clients
> (except for the tip you sent me previously) and having an example
> would be a great help.
> 
> Thanks!
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Wednesday, February 18, 2009 12:24 PM
> To: Patrick Haverty
> Subject: Re: Finding Leopard Performance
> 
> 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
