I'm not that much into assembler-programming yet, it's a bit too early (also I will try again to take more advantage of auto-vectorization this time, giving much more flexibility).
BM
I seem to remember that for the current run SSE2 and SSE3 didn't provide much of a performance boost over SSE. Will this still be the case for S5R2 and S5R3? And does the upcoming SSE4 look like it might provide any useful instructions?
After sometime I terminated the first unit with S5R2.
I need a long time, about 12 hours (51.900 sec). So I needed about 5,4 times
more than normal. So I am a little bit disapointed that I get only 113 points.
The double of the normal units.
After sometime I terminated the first unit with S5R2.
I need a long time, about 12 hours (51.900 sec). So I needed about 5,4 times
more than normal. So I am a little bit disapointed that I get only 113 points.
The double of the normal units.
Wow, 41,873.89 CPU seconds for a Core 2 E6600 to finish one result. Looks like some long crunch times ahead. The bright spot is that will amortize the network traffic of the big downloads.
Well, I haven't had any luck so far, only "S5RI" WUs... hope to finish them soon and try again ;-)
Same here. I think, I will switch off the light at the S5RI. ;)
Quote:
Wow, 41,873.89 CPU seconds for a Core 2 E6600 to finish one result. Looks like some long crunch times ahead. The bright spot is that will amortize the network traffic of the big downloads.
And what about the credits for this monster of WU?
Archae, are you serious? That will mean some gigantic crunching times on slower boxes... Luckily I've got two fast ones which should cope well. Maybe I'll switch the slower ones over to other projects and alter the resource shares on the racehorses a bit to make up for it.
(1) We fixed a problem with the validator where some results where erroneously being marked as validate errors. I re-ran the fixed validator on these results so credit was granted.
(2) I've done some preliminary analysis of credit granted and determined that we were not awarding enough credit. For all S5R2 workunits WITHOUT a valid result (at the moment, all but 52) I have fixed this in the database. Credit awarded for the S5R2 WU will now be larger by a factor of 2.222. Note that in the past Einstein@Home has been giving out 30% too much credit compared with other projects (see BOINC cross-project credit comparison for details). The factor of 2.222 takes this into account.
Further updates will follow.
Note: we are still in the process of rsyncing (mirroring) our new S5 data to the mirror download servers. So the first S5R2 workunits all reference the Einstein@Home server in Wisconsin as the data source.
Archae, are you serious? That will mean some gigantic crunching times on slower boxes... Luckily I've got two fast ones which should cope well. Maybe I'll switch the slower ones over to other projects and alter the resource shares on the racehorses a bit to make up for it.
I'm just reading Chilango's results from the link to his id in message 66051.
Quote:
And what about the credits for this monster of WU?
Again relying on the results page for Chilango's one computer.
Eyeballing an average, it has recently been spending typically about 7400 CPU seconds to do an S5RIa result, getting 53.6 cobblestones. The single S5R2c turned in so far on that machine reported consuming 41,873.89 CPU seconds and is poised to receive 112.59 cobblestones. With two cores on the machine, that would be a drop from 52 cobblestones/hour to 19, before allowing for less than 100% usage, efficiency, etc.
It is but a single sample, and I may be misreading it, but, yes, it seems we shall be getting results which take much longer to compute, and our rate of cobblestones/hour looks set to drop by well over a factor of two. There might be something special about the E6600 here, but I actually think that unlikely.
[edit: this post was, I think, accurate at the time I wrote it--however it took some time before I was able to post it, by which time it was overtaken by Bruce Allen's post. If I understand correctly, the above-mentioned result would now be awarded 249.95 cobblestones, which would make the stock E6600 implied hourly rate something like 42 cobblestones/hour, not 19]
Is Chilango's result (the only one I've seen linked so far) likely to be typical in terms of production run-time - i.e. 5.4 times S5RI run-time, in his estimation? (I stress production run-time, since it looks as if it still has a lot of debug output).
If so, you might like to consider whether 14 days is still the appropriate deadline: my Celeron, allowing for its current 50% share with SETI, would take about 17 days pro-rata. Not that the project should be run for the benefit of one superannuated cruncher, of course!
sorry Mike, always nice to
)
sorry Mike, always nice to chat with you, I hope we'll pick up later. some bugs will eat me here if I don't kill them now...
BM
BM
RE: I'm not that much into
)
I seem to remember that for the current run SSE2 and SSE3 didn't provide much of a performance boost over SSE. Will this still be the case for S5R2 and S5R3? And does the upcoming SSE4 look like it might provide any useful instructions?
RE: After sometime I
)
Well, I haven't had any luck
)
Well, I haven't had any luck so far, only "S5RI" WUs... hope to finish them soon and try again ;-)
RE: After sometime I
)
Wow, 41,873.89 CPU seconds for a Core 2 E6600 to finish one result. Looks like some long crunch times ahead. The bright spot is that will amortize the network traffic of the big downloads.
RE: Well, I haven't had any
)
Same here. I think, I will switch off the light at the S5RI. ;)
And what about the credits for this monster of WU?
Archae, are you serious? That
)
Archae, are you serious? That will mean some gigantic crunching times on slower boxes... Luckily I've got two fast ones which should cope well. Maybe I'll switch the slower ones over to other projects and alter the resource shares on the racehorses a bit to make up for it.
An update on our
)
An update on our progress:
(1) We fixed a problem with the validator where some results where erroneously being marked as validate errors. I re-ran the fixed validator on these results so credit was granted.
(2) I've done some preliminary analysis of credit granted and determined that we were not awarding enough credit. For all S5R2 workunits WITHOUT a valid result (at the moment, all but 52) I have fixed this in the database. Credit awarded for the S5R2 WU will now be larger by a factor of 2.222. Note that in the past Einstein@Home has been giving out 30% too much credit compared with other projects (see BOINC cross-project credit comparison for details). The factor of 2.222 takes this into account.
Further updates will follow.
Note: we are still in the process of rsyncing (mirroring) our new S5 data to the mirror download servers. So the first S5R2 workunits all reference the Einstein@Home server in Wisconsin as the data source.
Cheers,
Bruce
Director, Einstein@Home
RE: Archae, are you
)
I'm just reading Chilango's results from the link to his id in message 66051.
Again relying on the results page for Chilango's one computer.
Eyeballing an average, it has recently been spending typically about 7400 CPU seconds to do an S5RIa result, getting 53.6 cobblestones. The single S5R2c turned in so far on that machine reported consuming 41,873.89 CPU seconds and is poised to receive 112.59 cobblestones. With two cores on the machine, that would be a drop from 52 cobblestones/hour to 19, before allowing for less than 100% usage, efficiency, etc.
It is but a single sample, and I may be misreading it, but, yes, it seems we shall be getting results which take much longer to compute, and our rate of cobblestones/hour looks set to drop by well over a factor of two. There might be something special about the E6600 here, but I actually think that unlikely.
[edit: this post was, I think, accurate at the time I wrote it--however it took some time before I was able to post it, by which time it was overtaken by Bruce Allen's post. If I understand correctly, the above-mentioned result would now be awarded 249.95 cobblestones, which would make the stock E6600 implied hourly rate something like 42 cobblestones/hour, not 19]
Thanks to Bernd & Bruce for
)
Thanks to Bernd & Bruce for the heads-up.
Is Chilango's result (the only one I've seen linked so far) likely to be typical in terms of production run-time - i.e. 5.4 times S5RI run-time, in his estimation? (I stress production run-time, since it looks as if it still has a lot of debug output).
If so, you might like to consider whether 14 days is still the appropriate deadline: my Celeron, allowing for its current 50% share with SETI, would take about 17 days pro-rata. Not that the project should be run for the benefit of one superannuated cruncher, of course!