1 |
Sorry.. I should have clarified that.. That is not our 'official, |
2 |
complete' results.. just data that was thrown on as benchmarks |
3 |
completed. |
4 |
|
5 |
The bars represent percentage comparison to the highest scoring |
6 |
result. Aka: #1 is always 100%, the next is showing a percentage of |
7 |
that. The reason we did it that way was because some of the results |
8 |
where in the 76-78 range and some where in the several hundred |
9 |
thousand range.. We couldn't make a decent chart of all the results |
10 |
without normalizing them all to a percentage rate. |
11 |
|
12 |
Anyways.. the raw numbers represent an index from a base system that |
13 |
was setup when UnixBench was written. A score of 1 = just as fast as |
14 |
that system. 2 = some linear value faster.. etc. That system was a |
15 |
386 if I remember correctly so most scores are much much higher than |
16 |
1 any more. Things like memory performance and stuff have come light |
17 |
years. |
18 |
|
19 |
So the short of it is that higher is always better, and this is only |
20 |
a 'best as I personally' could do comparison. |
21 |
|
22 |
After our conversion things went together much smoother and now |
23 |
maintenance is fairly painless. I spend all of my time setting up our |
24 |
Apple cluster (The Gentoo ppc64 performance just wasn't good enough |
25 |
to wow the management into using it =) |
26 |
|
27 |
One big advantage of Gentoo is the ease in which new programs/ |
28 |
libraries can be installed. I have written dozens of ebuilds for all |
29 |
the programs we use here in order to simplify installation and |
30 |
administration. |
31 |
|
32 |
Now to install a new program I just have to build it on a node using: |
33 |
echo "emerge -b <program>" | qsub |
34 |
|
35 |
Then I install it on everything else using: |
36 |
emerge -K <program> ; pdsh -a emerge -K <program> |
37 |
|
38 |
|
39 |
(Though I am so lazy that I even scripted the whole thing so emerging |
40 |
a program on my cluster involves: |
41 |
mass_emerge <program> |
42 |
|
43 |
=) |
44 |
|
45 |
|
46 |
|
47 |
On Apr 11, 2006, at 2:07 PM, Donnie Berkholz wrote: |
48 |
|
49 |
> Brady Catherman wrote: |
50 |
>> I just converted out 134 node cluster from RedHat Enterprise Linux |
51 |
>> v4 to |
52 |
>> Gentoo 2005.1 |
53 |
>> |
54 |
>> Before and after the conversion we ran UnixBench as part of the |
55 |
>> Beowulf |
56 |
>> Performance Suite. |
57 |
>> |
58 |
>> There is a graphical representation of the results here: |
59 |
>> http://oceanus.ibest.uidaho.edu/~bcatherm/benchmark.png |
60 |
>> |
61 |
>> That shows Gentoo and Redhat on x86 hardware, and Gentoo and Macos |
62 |
>> on an |
63 |
>> dual XServe G5. |
64 |
> |
65 |
> The graph is a bit confusing because you essentially need to |
66 |
> compare the |
67 |
> two inner bars, and the two outer bars. It might be clearer with the 2 |
68 |
> x86 setups adjacent, and the 2 ppc setups adjacent. It's also a bit |
69 |
> unclear to me whether high values are universally good, or low values, |
70 |
> or whether it varies from test to test. From what I could find, it |
71 |
> looked like high was good for file copy and low for the rest, but |
72 |
> maybe |
73 |
> they've been modified so high is always good. |
74 |
> |
75 |
> Could you provide some more detailed hardware specs and `emerge info`? |
76 |
> I'd really like to put this data up somewhere on |
77 |
> gentoo.org/proj/en/cluster/ -- with your name etc withheld if |
78 |
> necessary. |
79 |
> |
80 |
> It would be interesting to do some performance analysis to see |
81 |
> where any |
82 |
> slowdowns come from and try to get things up to speed. |
83 |
> |
84 |
> Thanks, |
85 |
> Donnie |
86 |
> |
87 |
|
88 |
-- |
89 |
gentoo-cluster@g.o mailing list |