Hello,

Iam confused on the different result I get when I compile userland on
any machine better then a Dual Core 2.5Ghz 2GB RAM 160GB 7200 SATA /
SATA ii

On some machines I get a compile time of 45min, other machines 30min..
and the best of the case I get 30min.   Sometimes that machine that
takes 45min is far better hardware then a DualCore, in this case a
QuadCore with SATA II/sata...

Iam going to use these machines for database and Iam very concerned
about these results

Based on that I have this question:

Is it normal that this varies so much? (Afterall a variation from
35min to 45min represents an increase of about %25 less efficiency!!)

Is there a better way to benchmark the IO of a Hard Disk on OpenBSD ,
what should be the normal of a hard disk scanned as sd SATA/ SATA II
with similar CPU/RAM as mentioned?

Andres

[ message continues ]

Honestly, you'd do better asking that on a list dedicated to whatever
database you're going to be running.

In addition to helping you choose hardware to fit your needs, they'll
totally pimp your configs, too.

[ message continues ]

On Sun, Feb 28, 2010 at 11:10 AM, Bret S. Lambert

Thanks, it will still be interested then to know what the avergae
userland compilation is on similar hardware? Also any standard way of
benchmarking IO on openbsd?

Thanks

Andres

[ message continues ]

I would say it's probably bottlenecking on disk I/O based on what
you're telling me.  The quad core could have a shitty SATA chipset in
it, causing poor I/O scores.  If the times stop at 30 mins, it's
probably the SATA controller that's reached its limit.

Setting the controller to AHCI would give OpenBSD access to NCQ where
available, but the driver would also have to be written to take
advantage of this I would imagine.  There would also have to *be* a
driver for the controller, which wouldn't be needed if it's being run
in legacy mode (IDE emulation essentially).

If your hard drive comes up as wd0, it's set in Legacy mode.  If it's
sd0, it's in SATA/RAID/AHCI mode (dependant on manufacturer).

-- 
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse

[ message continues ]

On Sun, Feb 28, 2010 at 4:56 PM, Aaron Mason <simplersolution@gmail.com>

Where one would find documentation that tells one which drivers
support NCQ and which don't? Does the sili dirver support NCQ? sII3512
is supported by pciide, and not by the sili driver (drive gets
detected wd0, it's a SATA 1), while sii3124 is handled by the sili
driver, but the man page doesn't mention NCQ (this card supports it).

Thanks.

[ message continues ]

None of us will likely be able to tell you why, you'll have to figure 
out what part is the bottleneck in your setup, assuming you have 
identical configurations software-wise.  (softep?  Partition layout? 
Version?)

I don't know if building userland will take advantage of multiple CPUs, 

These results will be largely irrelevant for your database load. 
However, learning how to use the available tools to find the bottleneck 

The best way to benchmark the I/O will be to set up your database with 
some clients and run your workload.  Otherwise, you'll spend your time 
finding the fastest disk subsystem, only to discover that wasn't your 
bottleneck anyway.

[ message continues ]

Hi!

You didn't provide too many details. Based on that it could be any of the
following:

Different CPU (Intel vs. AMD, CPU generations, amount of CPU cache...)
Different FSB
Different memory setup or technology (integrated vs. on-board memory,
controller single-channel vs. dual-channel vs. triple-channel, DDR vs. DDR2
vs. DDR3, ECC vs. noECC, buffered vs. unbuffered, memory speed or timings,
...)
Different I/O or SATA controller
Different chipset
Misconfiguration (BIOS, OS, HDD, ...)
Different HDD (platter density, RPM, HDD cache, manufacturer, ...)
HDD layout (beginning vs. the end of disk)

and probably a ton of others I didn't think of.

How much, if at all, should any of these matter? No idea, you tell us :)

Regards, Daniel.

[ message continues ]

You're not even telling us how you compile userland. How should we help ?
is your obj in ram ? your tmp in ram ? are you building with make build ?
make -j4 build ? something else ?

[ message continues ]

Hello,

I dont have obj on ram, or /tmp . Iam using make build.

Thank you

Andres


[ message continues ]

Well, /tmp in RAM is going to make a big difference.

And src/ is mostly parallel-clean. There's an unlikely race in perl,
but otherwise make -jN build is going to go ~N times as fast on an n-core SMP
system.

[ message continues ]

[ message continues ]