Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Jul 1995 19:01:34 -0700 (PDT)
From:      "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
To:        rpt@miles.sso.loral.com (Richard Toren)
Cc:        hackers@freebsd.org
Subject:   Re: ramspeed results - ??
Message-ID:  <199507210201.TAA10376@gndrsh.aac.dev.com>
In-Reply-To: <Pine.SUN.3.91.950720205408.3746B-100000@miles> from "Richard Toren" at Jul 20, 95 08:59:20 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> I saw that this would swap itself to death when I first inspected the 
> code. I asked Poul-Henning Kamp about the malloc size and received:
> 
> >For the results to be comparable you cannot change that number.
> >If you want to run it with less memory, you also need to remove the
> >checksum check's later.
> 
> > >>> IF YOU CHANGE IT:  DO NOT PUBLISH YOUR NUMBERS !!! <<<

Though it is true you can't easily compare numbers of modified benchmarks,
so very few people report enough information that makes the data usefull
anyway.  There are only a few million things that effect this data that
I doubt one more would be significant, especially if it was clearly
marked (and since the checksum value would be wrong, well....]

ram-speed is not a good benchmark, plain and simple.  It was written
to do one small set of test conditions and if you can't meet the conditions
I suggest you don't use it as a benchmark.

Instead go get something more comprehensive like lmbench.

> i did mention that I had only 8MB of memory. If the checksum fails, I 
> don't think anything will be reported. And will the summary results 
> (uSec/op) values really be comparable?

For a 486DX2/66, I don't know the uSec/op number off the top of my head,
but the MB/sec should be in the 5 to 15 range, unless you have an ASUS
PCI/I-486SP3G, then it should be 14 for writting and 31 for reading,
or well, thats the values for a DX4/100, but CPU speed should not drastically
effect this test for the same cpu family and same external bus clock
frequency.

> 
> I think I will modify the block size, remove the checksum checks and see 
> what I get. What order of magnitude seems reasonable?
> 
>                          ====================================================
> Rip Toren               | The bad news is that C++ is not an object-oriented |
> rpt@miles.sso.loral.com | programming language. .... The good news is that   |
>                         | C++ supports object-oriented programming.          |
>                         |    C++ Programming & Fundamental Concepts          |
>                         |     by Anderson & Heinze                           |
>                          ====================================================
> On Thu, 20 Jul 1995, Rodney W. Grimes wrote:
> 
> > > 
> > > I picked up ramspeed from this list a week ago or so. Ran it last night.
> > > 1> Don't know how long it took, but it was over 90 minutes.
> > 
> > :-(.
> > 
> > > 2> iT's 486DX66, BT SCSI2 VLB controller, 8 MB memory
> >                                             ^^^^^^^^^^^
> > 
> > That code as supplied requires at least 8MB of totally free
> > and unused memory or you machine pages faults and swaps to
> > death.  This means you need a machine with at least 12MB and
> > usually more like 16MB to run it as supplied.
> > 
> > > 
> > > Results -
> > >  49005fb0 44.464 uS/op 2.25e+04 op/sec  0.086 mb/sec
> > >  8938c0df 44.845 uS/op 2.23e+04 op/sec  0.085 mb/sec
> > > 
> > > What is this telling me. How does it compare? Is the 3rd a disk swap rate 
> > > or something?
> > 
> > It is meaningless given the configuration.  All 3 result values are
> > the same result just expressed in 3 different ways, they all have
> > very simply mathmatical relations and given any 1 of them I can
> > calculate the other 2.
> > 
> > Change:
> > #define TESTSIZE (8192*1024)
> > 
> > to something like
> > #define TESTSIZE (4096*1024)
> > 
> > And boot your system single user to run the test to maximize the
> > free memory pool and to make sure that no vm page fragmentation
> > has happened.
> > 
> > 
> > 
> > -- 
> > Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
> > Accurate Automation Company                 Reliable computers for FreeBSD
> > 
> 


-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD



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