Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Feb 2000 20:33:28 +0100
From:      Brad Knowles <blk@skynet.be>
To:        Tom <tom@uniserve.com>
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: Initial performance testing w/ postmark & softupdates...
Message-ID:  <v04220823b4d1f68c1f85@[195.238.1.121]>
In-Reply-To: <Pine.BSF.4.05.10002171018260.13540-100000@shell.uniserve.ca>
References:  <Pine.BSF.4.05.10002171018260.13540-100000@shell.uniserve.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
At 10:37 AM -0800 2000/2/17, Tom wrote:

>    Uhhh... the paper says that an Ultra 1/170 running Solaris 2.5.  That is
>  an old system.

	I've run tmpfs tests with postmark on Ultra 2 and Ultra 5 systems 
with faster CPUs and newer versions of the OS, and they didn't run 
anywhere *NEAR* that fast (I've got an Ultra 5 I'm testing right 
now).  Heck, one person told me he had an older laptop running Linux 
with ReiserFS and he was getting better throughput going to disk than 
Sun did with tmpfs!

	Again, I have to seriously wonder what they were really testing on.

>    I'm not sure how comparing benchmark results from 1998 with current
>  hardware is relevant at all.  Postmark is performance is influenced more
>  by the disk & controller used, rather than the OS.  In fact, CPU is not
>  much of any issue either.  In fact, SMP is probably slowing the results
>  down!

	My results clearly show that there is a huge filesystem effect, 
and anything that could prevent operations from getting put into the 
queue to be flushed to disk would have a similar effect. 
OS/filesystem implementation efficiency could not *help* but have a 
huge impact on this.

>    You also compare results versus a NetApp F630.  I hope you realize that
>  these are VERY old units.

	Yes, I know that they are the previous generation devices, I've 
been told as much by folks from NetApp, when I was previously posting 
results from testing with postmark.

	I also know just how incredibly bloody expensive these things 
are, and how I did quite a good job of coming pretty close to their 
level of performance on a pretty low-end FreeBSD server with a 
*SINGLE* low-speed Quantum Atlas IV, and all I had to do was turn on 
softupdates.

	I also notice that softupdates on a slow disk beat out 
Linux/ext2fs+async on a single CPU system that was otherwise 
similarly configured, except for the DPT SmartRAID V controller that 
the Linux server had to it's advantage, and the 5-way RAID-5 volume 
that it was writing to.

>                             They came with Wide SCSI disks (not Ultra, not
>  Ultra2) for instance.  It doesn't mention, but I expect the test was only
>  done over 100BaseT.  In that case, the 100BaseT network would have been
>  the limiting factor.

	Yes, it was 100BaseT, but I don't see anything in any of these 
tests that should have come anywhere close to pushing the limits of 
100BaseT for speed -- ~400KBps read and ~600KBps write, with ~170 TPS 
shouldn't come anywhere close to network bottlenecks of 12.5MBps 
capacity.

>                        Also, the existing base model NetApp, the F720 has
>  over twice the performance of the F630!  And I've been told that NetApp
>  doesn't really sell anything but the high-end F760, which has over twice
>  the performance of the F720.  The entire F700 is already pretty old, and
>  is scheduled to be replaced by a new series this year.

	"Twice the performance."  I'm sorry, that term is just a little 
too vague for me.  Can you quantify these numbers in terms of 
transactions per second, data read per second, and data written per 
second?

>    So please, postmark is a useful tool.  See my previous e-mails about
>  postmark+softupdates.  But comparing results when a two year old document
>  is meaningless.  Especially with disk/controller performance doubling
>  every year or so.

	Their performance may theoretically be doubling every year or so, 
but the machine I tested with is not anywhere close to what I would 
consider to be a high-end server, and it definitely did not have the 
advantage of a vinum nine-way striped filesystem on 10kRPM disks or 
anything like that, and yet I still came pretty close to their level 
of performance.

	Let me get rawio working on this machine, and we can compare the 
low-level hardware performance of this disk device to the previous 
four-way 10kRPM vinum striped device I used for my previous 
benchmarking, and then we can extrapolate as to what might happen on 
that system if we enabled softupdates on it.  I'd be willing to bet 
that it would beat the crap out of the F630, and if I was allowed to 
do that on a nine-way striped 10kRPM volume, I could do some pretty 
good damage against the current crop of NFS servers.


	Take a look at what Joe Greco is talking about doing for his 
next-generation USENET news spool server (see message-id 
<38ac286b$0$86644@news.execpc.com> in news.software.nntp), and tell 
me that this wouldn't beat the crap out of NetApp as an NFS server.

-- 
   These are my opinions and should not be taken as official Skynet policy
  _________________________________________________________________________
|o| Brad Knowles, <blk@skynet.be>                 Belgacom Skynet NV/SA |o|
|o| Systems Architect, Mail/News/FTP/Proxy Admin  Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.13.11/726.93.11          B-1140 Brussels       |o|
|o| http://www.skynet.be                          Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
      Unix is very user-friendly.  It's just picky who its friends are.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v04220823b4d1f68c1f85>