After some more testing, it looks like the new core is faster that on_wine on intel CPU, but still slower if linux runs on AMD CPU...
Just an observation...
I always runned winehq optimized for i686 or atlon
Not really great testing, but...
AMD barton 3000+, linux 2.4 RH6.2: on_wine 24Ksec, on_linux 28,5Ksec
AMD sempron 3000+, linux 2.6 FC4: wine 24Ksec, linux 29Ksec
P4 3000, linux 2.6 FC3, HT but cruncher uses only 1CPU: wine 28Ks, linux 25K, linux using HT: 56,5Ks
Celeron 466, linux 2.4, RH6.2: wine 169Ks linux 130Ks
for dual p3 see my post below (running gentoo linux 2.6)
p3 700 linux 2.6, FC4: wine 88Ks linux 78Ks
that's for now.
This is probably the wrong thread to raise this issue, but I have searched, and all the ones I've found are about running Einstein@home under Wine or optimising Einstein itself.
So here goes, flame away if you think I'm in the wrong place :) Or point me in the right direction.
Now that we have this wonderful new Linux client (thanks guys!), what is the general opinion about running it on an optimised BIONC core client?
I have been getting results between 27,425.21 seconds and 28,510.32 seconds
with the new Einstein client :)
As we all know the BOINC core client is responsible for the benchmarking, which affects credit awarded, and I have been getting miserable benchmark scores under Linux :(
Here are my Linux and WindowsXP benchmarks:
Slackware Linux (std 2.6.12.3 kernel), BOINC 4.43:
Measured floating point speed 986.5 million ops/sec
Measured integer speed 1913.33 million ops/sec
WinXP SP2, BOINC 4.44:
Measured floating point speed 1875.86 million ops/sec
Measured integer speed 3126.59 million ops/sec
The computer is a dual-boot system, so everything should be effectively identical, other than me still having to recompile the Linux kernel to recognise 4Gig of Ram.
My Linux benchmarks speak for themselves :(
Is it worth going for the 20% to 30% improvement in benchmark figures? Will it make a difference at the end of the day? Most importantly, will it affect the quality of the science?
If this was Seti@home I would just go for it, but the quality of the science seems far more important here, so that is why I am asking for an opinion.
Thanks in advance, and sorry if I am in the wrong thread.
Edit: Spelling and grammer. Clarified a bit
Need Help? Try the excellent Unofficial BOINC Wiki!
We are the BOINC. Prepare to be assimilated.
'anthrax beats WinXP' - The Register
I don't want to be negative but it is only fair that I report the behaviour of the linux client on my PC's.
Speed seems good but there is a nasty bug.
The client stops working but reports itself as still active.
It just sits there taking no CPU cycles.
The client runs for a while then stops doing any work.
boincmgr and boincview say it's stil active but running top shows the client is dead.
What other projects are you running?
I've seen this before running redhat and various CC's over the last year, and it's been noted to the Boinc devs. It also seems to happen on Macs, and Paul Buck did file a problem report.
The times I've seen it in the last 1-2 months, is this:
-CPDN is running (active)
-the CC decides it's time for a new benchmark
-CPDN doesn't shutdown in time and benchmarks are canceled
-nothing runs again until the CC is restarted
It could be that Einstine also doesn't shutdown in time for the autobenchmark, and things are left in the same state.
Do you have the log of when things went wacko?
Does shutting down the CC and restarting it resolve the problem?
Benchmarks weren't run by me or auto.
There was still a few days to go before they autorun.
Einstein was working in round robin mode with Predictor and SZTAKI.
The boxes I noticed it happening on were my athlon MP duals, these provide services TFTP, NFS etc for my PXE nodes.
The OS on these is Centos 4 a RH AS clone.
kernel is 2.6
CC is ver 4.72
Being dual 2 instances of Einstein were running on each server and only one instance was dying.
The other instance was working fine.
When the Scheduler decided to swap to predictor or SZTAKI both instances came up and worked fine.
I didn't spot this problem straight away as the reporting tools said all was well.
If I stopped boinc and killed the Einstein exe's, then restarted boinc both instances of Einstein would then work for a while but one instance kept dying.
After seeing this I experimented adding a few more projects, XtrmLab, LHC etc
and have been closely watching the Dualies.
They are fine running all the above projects except Einstein.
I haven't run CPDN so i don't know if that would exhibit the same behaviour.
After some more testing, it
)
After some more testing, it looks like the new core is faster that on_wine on intel CPU, but still slower if linux runs on AMD CPU...
Just an observation...
I believe it was optimized
)
I believe it was optimized for SSE instructions only.
RE: After some more
)
That's really surprising, as the Windows App should favour the Intel (P4) a bit.
True, but the SSE is present in both (modern) types of CPUs. (btw: The App didn't gain much from SSE2 compared to SSE)
This may depend on the CPUs as well as the Linux kernel and Wine version. wijata.com, what were the systems you made this observation on?
BM
BM
RE: True, but the SSE is
)
hah! I need to read up on this stuff again, haven't been keeping up with the past couple of years :)
I always runned winehq
)
I always runned winehq optimized for i686 or atlon
Not really great testing, but...
AMD barton 3000+, linux 2.4 RH6.2: on_wine 24Ksec, on_linux 28,5Ksec
AMD sempron 3000+, linux 2.6 FC4: wine 24Ksec, linux 29Ksec
P4 3000, linux 2.6 FC3, HT but cruncher uses only 1CPU: wine 28Ks, linux 25K, linux using HT: 56,5Ks
Celeron 466, linux 2.4, RH6.2: wine 169Ks linux 130Ks
for dual p3 see my post below (running gentoo linux 2.6)
p3 700 linux 2.6, FC4: wine 88Ks linux 78Ks
that's for now.
I don't want to be negative
)
I don't want to be negative but it is only fair that I report the behaviour of the linux client on my PC's.
Speed seems good but there is a nasty bug.
The client stops working but reports itself as still active.
It just sits there taking no CPU cycles.
The client runs for a while then stops doing any work.
boincmgr and boincview say it's stil active but running top shows the client is dead.
Slightly Off-topic Post
)
Slightly Off-topic Post
This is probably the wrong thread to raise this issue, but I have searched, and all the ones I've found are about running Einstein@home under Wine or optimising Einstein itself.
So here goes, flame away if you think I'm in the wrong place :) Or point me in the right direction.
Now that we have this wonderful new Linux client (thanks guys!), what is the general opinion about running it on an optimised BIONC core client?
I have been getting results between 27,425.21 seconds and 28,510.32 seconds
with the new Einstein client :)
As we all know the BOINC core client is responsible for the benchmarking, which affects credit awarded, and I have been getting miserable benchmark scores under Linux :(
Here are my Linux and WindowsXP benchmarks:
Slackware Linux (std 2.6.12.3 kernel), BOINC 4.43:
Measured floating point speed 986.5 million ops/sec
Measured integer speed 1913.33 million ops/sec
WinXP SP2, BOINC 4.44:
Measured floating point speed 1875.86 million ops/sec
Measured integer speed 3126.59 million ops/sec
The computer is a dual-boot system, so everything should be effectively identical, other than me still having to recompile the Linux kernel to recognise 4Gig of Ram.
My Linux benchmarks speak for themselves :(
Is it worth going for the 20% to 30% improvement in benchmark figures? Will it make a difference at the end of the day? Most importantly, will it affect the quality of the science?
If this was Seti@home I would just go for it, but the quality of the science seems far more important here, so that is why I am asking for an opinion.
Thanks in advance, and sorry if I am in the wrong thread.
Edit: Spelling and grammer. Clarified a bit
Need Help? Try the excellent Unofficial BOINC Wiki!
We are the BOINC. Prepare to be assimilated.
'anthrax beats WinXP' - The Register
RE: I don't want to be
)
What other projects are you running?
I've seen this before running redhat and various CC's over the last year, and it's been noted to the Boinc devs. It also seems to happen on Macs, and Paul Buck did file a problem report.
The times I've seen it in the last 1-2 months, is this:
-CPDN is running (active)
-the CC decides it's time for a new benchmark
-CPDN doesn't shutdown in time and benchmarks are canceled
-nothing runs again until the CC is restarted
It could be that Einstine also doesn't shutdown in time for the autobenchmark, and things are left in the same state.
Do you have the log of when things went wacko?
Does shutting down the CC and restarting it resolve the problem?
Benchmarks weren't run by me
)
Benchmarks weren't run by me or auto.
There was still a few days to go before they autorun.
Einstein was working in round robin mode with Predictor and SZTAKI.
The boxes I noticed it happening on were my athlon MP duals, these provide services TFTP, NFS etc for my PXE nodes.
The OS on these is Centos 4 a RH AS clone.
kernel is 2.6
CC is ver 4.72
Being dual 2 instances of Einstein were running on each server and only one instance was dying.
The other instance was working fine.
When the Scheduler decided to swap to predictor or SZTAKI both instances came up and worked fine.
I didn't spot this problem straight away as the reporting tools said all was well.
If I stopped boinc and killed the Einstein exe's, then restarted boinc both instances of Einstein would then work for a while but one instance kept dying.
After seeing this I experimented adding a few more projects, XtrmLab, LHC etc
and have been closely watching the Dualies.
They are fine running all the above projects except Einstein.
I haven't run CPDN so i don't know if that would exhibit the same behaviour.
PCZ: From what you write I
)
PCZ:
From what you write I suspect that you are running a Linux kernel 2.6.x with x <
BM