Dear All,
On my system (and not only on it, see this message) each S5R4 WU takes twice the processing time as a S5R3 WU. I believe the (Windows/x86) 6.04 application has not been properly compiled, and therefore does not recognise some of the processors - I am comparing the run times to the power application I used for S5R3.
Thus, I am now earning less than half credits per processor hour for each S5R4 WU on 6.04, as compared to S5R3 on power application.
I hope someone could look at this?
Cheeers, Igor
Copyright © 2024 Einstein@Home. All rights reserved.
processor recognition by 6.04 aplication on windows vista
)
Hi Igor,
I don't think you have a problem with processor recognition, it just the S5R4's are much more processor intensive and they are bigger than the R3's. They take longer to process.
As for the credits it was mentioned in another message thread that the claimed and the granted have been adjusted for S5R4. The granted is now higher than the claimed amount but still different to what you used to get for S5R3.
BOINC blog
This is the message I was
)
This is the message I was trying to find earlier that explains things.
BOINC blog
RE: This is the message I
)
It does not to me.
Note added in proof of my previous statement:
the einstein_S5R4_6.04_windows_intelx86_1.exe file, which is supposed to use the sse, has exactly the same byte count as the einstein_S5R4_6.04_windows_intelx86_0.exe file, which does not use sse. However, the einstein_S5R3_4.46_windows_intelx86_1.exe and einstein_S5R3_4.46_windows_intelx86_0.exe files have different byte counts.
Therefore, obviously the einstein_S5R4_6.04_windows_intelx86_1.exe has been compiled with wrong keys.
Cheers, Igor
Hmmm... Interesting, but
)
Hmmm...
Interesting, but you cannot go by byte count.
If you check the MD5 hash for them, you find that the hash for 4.46_1 is different from 6.04_0 even though they have the same displayed byte count to 3 significant digits. Also, if you check the properties dialog, the actual byte count is different as well.
Alinator
RE: RE: This is the
)
Which bit doesn't it explain? The part about them being bigger/more processor intensive (to start with) or the credit?
Just because they have the same byte count doesn't mean they are the same. I did a couple of compares (comp and FC) and it thinks they are different. Berndt would be the best person to explain if they have been compiled with SSE enabled or not.
BOINC blog
RE: Just because they have
)
Agreed, and I'm pretty sure Bernd has already said as much. ;-)
Alinator
I have been comparing the
)
I have been comparing the wu's for years myself and have seen the differences running the different WU versions on Vista XP and XP Pro OS's using AMD's and P4's including dual processors.
Like now running the current version they may appear to be the same but there usually is a small difference.
Same with the time to complete on each (such as an AMD 3200 on XP Pro doing them at an average of 14hrs and a older P4 2.5 in an average of 24hrs and a dual P4 3.2 in an average of 22.5 hours.....and so on and slight differences on each running the same unit)
And as you can see the claimed and granted are 2 different stories......all that counts is the granted.
I have many that are granted 192.24 but even as high as 223.12 and the lowest of 153.04 just once.
http://einsteinathome.org/account/tasks&offset=0
(yes I know I am kind of going off this particular track but figured I would put it all together here)
Well, we don't have to
)
Well, we don't have to speculate about the relative speed of the apps, we can actually test it stand-alone with the reference unit as a benchmark.
See this message for a windows version of the scripts in the reference workunit.
But as has been written, the longer runtime of the S5R4 is seen across OSes, and the reason is that they are packaged differently than the S5R3 units, e.g. the units work on data from a different (longer) segment of the S5 science run.
CU
Bikeman
For the curious, see this
)
For the curious, see this message for an attempt to estimate how the "ammount of science" in the WUs affect the runtime.
CU
Bikeman