|
KIN DB 2004 Project - Tests
|
Project hosted at:
|
This is the test results section. Here you can find:
- Stress (benchmark) tests results.
- Newest stress tests results (dalmem tests only).
- Old stress tests results.
Some interesting conclussions from tests (that may help to build and efficient Kin cluster):
- CPU stepping may make huge diference for some instructions (like loop ones)
- Actual RAM access speed depends on chipset, and DDR II is usually slower than DDR
(you need at least DDRII at 667MHz to achieve better sustained access times than
a DDR system at 400MHz). This is mainly due to internal DDR II construction (has
a faster bus, but cells are at half speed so 667 memory operates at 333MHz in the
inside). Waiting for DDR II at 800MHz for a real improvement in speed...
- Shared video framebuffer reduces available RAM bandwidth, of course (as it is
shared among CPU and video subsystem), but it is only slightly noticeable when
you use text modes (more heavy if you refresh a big graphic screen, isn't it?)
- Cheap chipsets perform poorly with RAM access, unfortunately (a Xeon based server
with server chipset outperforms theoretically faster desktops). All still
keep far, far away from theoretical RAM bandwidth. For an instance, for dual
bank DDR400, bandwidth should be some 6.4GB/s, but best figures keep quite
above 3GB/s. For DDRII, this is slightly better but still far: we get about
3GB/s for a RAM that should deliver about 4.26GB/s sustained (DDRII 533).
AMD direct RAM management doesn't perform better (for Athlon64 chips), it gets
2.35GB/s at its best with the same dual bank DDRII 533...
Update: Intel Core 2 + a decent chipset (like Intel P965) seems to improve
RAM bandwidth by a large 20-25%, getting up to 4GB/s on DDRII @ 533MHz (much
closer to the theoretical limit), for a similar CPU cost (but processing speed
is smaller in that case).
- 64bit mode seems to double RAM writing bandwidth
These are raw memory tests, on a working system there's a combination of many other factors,
so maybe a cheap, not very efficient system, may compare to an apparent faster high end
server, once cache efficiency, task switching, etc, is taken into the equation. Or it
still performs a little slower, but it is much cheaper that you can set a few more nodes
into the cluster getting a faster overall system anyway. And maybe spending less power.
So these tests may help, but a deeper test is necessary (raw RAM access is an important
requirement for a Kin system, it is used intensively, but big caches and some algorithm
improvement may change its real importance in a real working system, depending on database
size and usage).
