Thanks for all the detailed reports which were of great use to identify the runtime characteristics of the new app on different platforms.
I know that the development is aware of the performance issues and working hard to fix this.
AFAIK, for S5R3, the Einstein@Home app is doing about 80-90% of its work in just two comparatively small subroutines. The "art" is to write this code in a way that all the compilers involved will produce code that is about as fast as the Windows code on the same/comparable hardware. The Windows app is the yardstick because most of the hosts are running Windows, of course, and Einstein@Home has to award credits comparable to other projects per CPU-second in order to be fair to the crunchers and to those other projects, so credits/(CPU hour) must first be calibrated for the Windows app.
Obviously, this time the gcc compiler flunked big time for Linux-i686 in S5R3, and to a lesser degree for Mac OS Intel /Mac OS PPC.
The final solution will be to have platform dependent code or hand-coded assembly subroutines (what is commonly known as "optimized apps" in BOINCspeak). Bernd has already announced this to happen once a few remaining stability issues are ironed out. Until then, the developers will have to tweak the app and the compilation settings in a away that it will improve performance for the gcc platforms but without hurting the Windows app., as you want to maintain a codebase that is as similar as possible for all platforms (certainly we don't want to have cross-platform validation problems again....).
I understand that Linux and Darwin users are anything but happy with the current credits/hour output of their machines. For most of S5R2, the Darwin and Linux apps seem to have been a bit faster that their Windows counterpart, but still, this must be rectified.
So again, thanks for all the useful reports, and hopefully you will bear with Einstein@Home while the team is working on the solution (as many AMD/Windows users did when their hosts were slowed down temporarily in S5R2). I think the science is definitely worth it. Even at reduced speed, every app makes a useful contribution to the scientific effort behind E@H.
Please continue to report your observations on the new S5R2 apps here
Happy crunching
Bikeman
Hello Bikeman,
would a credit adjustment be in order when they work out the bugs? Or are we (mainly) Linux users test bunnies till they work it all out and we just wear it as part of the project getting things (like the applications) to work?
I suppose I can wear it but it is disappointing that this performance hit could not have been detected prior to release as the Einstein farm has plenty of Linux computers that would of shown the same degree of slowing down that we have been reporting.
Credit adjustment is a tricky thing, credits are fixed per workunit and are always the same for both wingman at E@H, irrespective whether they crunch under Windows or Linux. A certain result gets you so many credits and that's it.
In my view it's no option to perform a significant global raise of credits because then the Windows E@H crunchers would get many more credits here than crunching on SETI, Rosetta, etc, and that's unfriendly against those other projects.
And basing the credits solely on the CPU seconds spent (paying by the CPU second) is completely unfair because you penalize people for upgrading their hardware or (later) using optimized apps.
I guess Bernd or Bruce will comment on this later. But please consider that on the other hand, no credit reduction was made for Linux crunchers for S5R2 were their apps seemed to be a bit faster either.
I'm confident that this is just a transitional problem.
Anything new about my problems with Win/AMD? Is it the AMD architecture? Something else about my box? Or just bad luck with the WU/frequency band?
Hi!
I doubt there is a specific AMD-Windows problem again. It's just that the S5R3 workunits require more memory bandwidth than S5R2 units.
But you have quite a rare type of result (from the lower end of the frequency band) where there are far less reports to compare your result to.
And all those strange debug messages in your result
[09/28/07 01:45:55] TRACE [2320]: Retrieved the required window station
[09/28/07 01:45:55] TRACE [2320]: Retrieved the required desktop
make me wonder whether this might be graphics related. Maybe using the new Windows beta with the graphics disabled (unsing a special file as indicator) could help? I guess it's worth the try.
What do you think?
CU
H-B
And all those strange debug messages in your result
[09/28/07 01:45:55] TRACE [2320]: Retrieved the required window station
[09/28/07 01:45:55] TRACE [2320]: Retrieved the required desktop
make me wonder whether this might be graphics related. Maybe using the new Windows beta with the graphics disabled (unsing a special file as indicator) could help? I guess it's worth the try.
What do you think?
CU
H-B
Hmm, now you mention it... odd indeed. I have no idea why that should turn up with Windows XP, an ordinary Geforce card and vanilla gfx drivers, but that doesn't have to mean a thing ;-) least of all when Windows is concerned. Maybe the new BOINC client and my box don't get along too well. Your idea sounds like it's definitely worth a try. :-)
My best guess is that those messages appear whenever I try to resume working after the screensaver kicked in... still don't know if they indicate a problem but that seems like the most likely explanation.
And yes, I know I shouldn't be using the screensaver, strictly speaking, but it's just so nice, especially with the large screen and reasonably fast gfx I don't have on my laptop, so I decided to give myself the treat ;-) I would of course stop it if it hurt my performance more than the "normal" amount.
To find out, I'm going to finish the current result with the vanilla core client then switch to the beta with no graphics for the next one. Hopefully we'll be able to see a performance increase.
EDIT: I just looked at my wingmens' results and they look about the same... maybe it is normal after all?
Credit adjustment is a tricky thing, credits are fixed per workunit and are always the same for both wingman at E@H, irrespective whether they crunch under Windows or Linux. A certain result gets you so many credits and that's it.
In my view it's no option to perform a significant global raise of credits because then the Windows E@H crunchers would get many more credits here than crunching on SETI, Rosetta, etc, and that's unfriendly against those other projects.
And basing the credits solely on the CPU seconds spent (paying by the CPU second) is completely unfair because you penalize people for upgrading their hardware or (later) using optimized apps.
I guess Bernd or Bruce will comment on this later. But please consider that on the other hand, no credit reduction was made for Linux crunchers for S5R2 were their apps seemed to be a bit faster either.
I'm confident that this is just a transitional problem.
CU
Bikeman
We've been operating for a month now on a roughly 15% cut in "pay." That means we've been getting lower credits against your chosen SETI, Rosetta, etc. "benchmarks." Why not simply adjust the per workunit credit to a level that reflects the credit rate we were getting before the added overhead? What's tricky about that?
Credit adjustment is a tricky thing, credits are fixed per workunit and are always the same for both wingman at E@H, irrespective whether they crunch under Windows or Linux. A certain result gets you so many credits and that's it.
In my view it's no option to perform a significant global raise of credits because then the Windows E@H crunchers would get many more credits here than crunching on SETI, Rosetta, etc, and that's unfriendly against those other projects.
And basing the credits solely on the CPU seconds spent (paying by the CPU second) is completely unfair because you penalize people for upgrading their hardware or (later) using optimized apps.
I guess Bernd or Bruce will comment on this later. But please consider that on the other hand, no credit reduction was made for Linux crunchers for S5R2 were their apps seemed to be a bit faster either.
I'm confident that this is just a transitional problem.
CU
Bikeman
We've been operating for a month now on a roughly 15% cut in "pay." That means we've been getting lower credits against your chosen SETI, Rosetta, etc. "benchmarks." Why not simply adjust the per workunit credit to a level that reflects the credit rate we were getting before the added overhead? What's tricky about that?
The tricky part is that some platforms are affected more than others. Windows apps should have almost the same credits/hour performance, but Mac OS suffered a bit and Linux quite a lot (see the new Linux beta app for an improved version).
Credit is granted on E@H per workunit and irrespective of platform. If you raise credits to be fair to Linux users, you "overpay" Windows users compared to Seti, Rosetta etc.
The right solution is to improve the app, not mess with the credits, see the new Linux app.
RE: Hi all! Thanks for all
)
Hello Bikeman,
would a credit adjustment be in order when they work out the bugs? Or are we (mainly) Linux users test bunnies till they work it all out and we just wear it as part of the project getting things (like the applications) to work?
I suppose I can wear it but it is disappointing that this performance hit could not have been detected prior to release as the Einstein farm has plenty of Linux computers that would of shown the same degree of slowing down that we have been reporting.
Credit adjustment is a tricky
)
Credit adjustment is a tricky thing, credits are fixed per workunit and are always the same for both wingman at E@H, irrespective whether they crunch under Windows or Linux. A certain result gets you so many credits and that's it.
In my view it's no option to perform a significant global raise of credits because then the Windows E@H crunchers would get many more credits here than crunching on SETI, Rosetta, etc, and that's unfriendly against those other projects.
And basing the credits solely on the CPU seconds spent (paying by the CPU second) is completely unfair because you penalize people for upgrading their hardware or (later) using optimized apps.
I guess Bernd or Bruce will comment on this later. But please consider that on the other hand, no credit reduction was made for Linux crunchers for S5R2 were their apps seemed to be a bit faster either.
I'm confident that this is just a transitional problem.
CU
Bikeman
Anything new about my
)
Anything new about my problems with Win/AMD? Is it the AMD architecture? Something else about my box? Or just bad luck with the WU/frequency band?
RE: Anything new about my
)
Hi!
I doubt there is a specific AMD-Windows problem again. It's just that the S5R3 workunits require more memory bandwidth than S5R2 units.
But you have quite a rare type of result (from the lower end of the frequency band) where there are far less reports to compare your result to.
And all those strange debug messages in your result
[09/28/07 01:45:55] TRACE [2320]: Retrieved the required window station
[09/28/07 01:45:55] TRACE [2320]: Retrieved the required desktop
make me wonder whether this might be graphics related. Maybe using the new Windows beta with the graphics disabled (unsing a special file as indicator) could help? I guess it's worth the try.
What do you think?
CU
H-B
RE: And all those strange
)
Hmm, now you mention it... odd indeed. I have no idea why that should turn up with Windows XP, an ordinary Geforce card and vanilla gfx drivers, but that doesn't have to mean a thing ;-) least of all when Windows is concerned. Maybe the new BOINC client and my box don't get along too well. Your idea sounds like it's definitely worth a try. :-)
Only small cr/hr hit on my
)
Only small cr/hr hit on my core 2 duo,
S5R2 641.32cr 106298sec 21.7cr/hr
S5R3 221.96cr 39037sec 20.5cr/hr
Pent M in heavy LTD on Einstein so no S5R3 units yet.
Andy
My best guess is that those
)
My best guess is that those messages appear whenever I try to resume working after the screensaver kicked in... still don't know if they indicate a problem but that seems like the most likely explanation.
And yes, I know I shouldn't be using the screensaver, strictly speaking, but it's just so nice, especially with the large screen and reasonably fast gfx I don't have on my laptop, so I decided to give myself the treat ;-) I would of course stop it if it hurt my performance more than the "normal" amount.
To find out, I'm going to finish the current result with the vanilla core client then switch to the beta with no graphics for the next one. Hopefully we'll be able to see a performance increase.
EDIT: I just looked at my wingmens' results and they look about the same... maybe it is normal after all?
Hey now :) I want some
)
Hey now :)
I want some official words from the admins on this slowdown for Linux.
I did some beta testing on the new app but it suddenly was scratched
RE: Credit adjustment is a
)
We've been operating for a month now on a roughly 15% cut in "pay." That means we've been getting lower credits against your chosen SETI, Rosetta, etc. "benchmarks." Why not simply adjust the per workunit credit to a level that reflects the credit rate we were getting before the added overhead? What's tricky about that?
RE: RE: Credit adjustment
)
The tricky part is that some platforms are affected more than others. Windows apps should have almost the same credits/hour performance, but Mac OS suffered a bit and Linux quite a lot (see the new Linux beta app for an improved version).
Credit is granted on E@H per workunit and irrespective of platform. If you raise credits to be fair to Linux users, you "overpay" Windows users compared to Seti, Rosetta etc.
The right solution is to improve the app, not mess with the credits, see the new Linux app.
CU
Bikeman