windows apps get upto the same credit/hour as at the end of r2, ~15% less than at the start. The shortest WUs in the set are at that level, the longer ones are an addional decent sized hit.
EDIT: Unless the phenomenon behind the time variance can be figured out soon and adjusted for I think the project needs to temporarily rescale granted credit based on the penalty from all the debuggging code that's been added and the average length of the new WUs.
windows apps get upto the same credit/hour as at the end of r2, ~15% less than at the start. The shortest WUs in the set are at that level, the longer ones are an addional decent sized hit.
EDIT: Unless the phenomenon behind the time variance can be figured out soon and adjusted for I think the project needs to temporarily rescale granted credit based on the penalty from all the debuggging code that's been added and the average length of the new WUs.
Thank you, Dan. I have been complaining about this for nearly a month. Bikeman has been saying wait for the optimized app. I think a month is too long to wait for an adjustment (rescale).
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.
I will try the Beta test application and see if there is any improvement. I really hope there is improvement over the 35% plus credit drop I currently am getting with this project on Linux.
Still this should of all been sorted prior to the applications release.
Remember I was going to try and do some speed comparisons for workunits from different frequency bands, around two weeks ago?
Well, I finally managed to get rid of all the S5R2 re-sends, and got a couple of good observing runs - plot is crunch time (seconds) against workunit number.
So they don't keep getting faster and faster - they oscillate.
The blue curve is from host 1001562. I got a full cycle here (with a few gaps), and the average over the cycle was 19.72 credits/hour - very close to the 19.93 credits/hour I averaged for the last few S5R2 WUs using Beta app 4.40. The variation is about +/- 7.5%
The pink curve is from host 1001564. Here, I got a completely consecutive run, but unfortunately the server switched me to another frequency before I'd done a full cycle. The average yield for the points plotted is 20.06 credits/hour, slightly above the 19.84 cr/hr that box got for Beta 4.40, but as you can see the sample was biased towards the faster (better-yielding) part of the curve.
The boxes are identical Q6600s with 2GB RAM each, running at stock speed under Windows XP.
Edit - I meant to add that the 'yield' for Einstein S5R3 varies from a minimum of 17.90, to a maximum of 20.94, credits/hour on these machines.
By comparison, I did a similar timing run on one of them using the current SETI@home application (stock app 5.27 on multibeam data). The average yield for SETI was 23.49 credits/hour, but the variation was from 13.17 to 49.62 cr/hr. Although I ran it for about 200 WUs before installing an optimised application, it's hard to say that I got a true average.
Remember I was going to try and do some speed comparisons for workunits from different frequency bands, around two weeks ago?
Richard, let me try to add to your reporting with data from 542.70. My Stoll4 host is a Q6600. During the period in question it ran part of the time at 3.24 GHz, and part at 3.006. I've attempted to adjust the reported CPU time to equivalent 2.4 GHz times by simply multiplying by the frequency ratio. The two oddball points for 45 and 44 switched over in mid-run so this simple adjustment does not work.
Averaged over the points I have, this would give a credits per 2.4 GHz-equivalent CPU hour of 19.05, though I'm not sure how fairly I've sampled the cycle. Also, my overclocked box at 3.24 GHz was running relaxed memory timings, which may have hurt its adjusted speed slightly.
The period of the cyclicity of CPU time required appears to be 60 results, or something very close to that, and matches your data in that respect.
As an aside, BOINClogX made acquiring these data quite simple, though sadly it does not log requested credit, since they were all the same in this case that was not a problem.
I will try the Beta test application and see if there is any improvement. I really hope there is improvement over the 35% plus credit drop I currently am getting with this project on Linux.
I finished 10 WUs with the Beta 4.09 app, not 35% speedup but not bad:
Quote:: As an aside, BOINClogX made acquiring these data quite simple.
Anyone know if there is something like BOINClogx for Apple Macs? Or, does Einstein@Home provide any ability to download the same data contained on the Results and WorkUnit webpages for a Userid in a CSV file (or other format). Right now I automatically read the webpages to pull data from them. But I have to program in a multisecond wait time for each page. To get all my info takes nearly 2 hours. It would be great if I could download all my current information in one text file.
And S5R2 results has been computed on fresh OS with ~2-3% more high speed.
------------------------------------------
P.S.
Some funny (but real!) question:
Can I merge my NEW host into old?
I am a "one host cruncher" with "legendary" host 43575 that started crunch of Einstein units in 22 February 2005 and been restored (and renamed by project server) after OS reinstall in summer of 2007.
The pink curve is exactly the same as last time, and the yellow/turquoise ones are the next dataset on the same host 1001564. I've been lucky enough to get a continuous plot from result 134 to result 55, and the series is ongoing - the sequence extends to 43 with the results I've been allocated already, and if the scheduler keeps smiling on me, I might even chase it all the way down to 0.
Observations:
Changing from 4.01 to 4.07 seems to have made no difference at all.
The oscillations are not sinusoidal, but glaciated (sharp peaks and rounded valleys - at least, when you plot time rather than speed!)
There are lumps and bumps on the mountain flanks which definitely seem structural, rather than host processor artefacts - they happen repeatedly at the same level on successive cycles.
windows apps get upto the
)
windows apps get upto the same credit/hour as at the end of r2, ~15% less than at the start. The shortest WUs in the set are at that level, the longer ones are an addional decent sized hit.
EDIT: Unless the phenomenon behind the time variance can be figured out soon and adjusted for I think the project needs to temporarily rescale granted credit based on the penalty from all the debuggging code that's been added and the average length of the new WUs.
RE: windows apps get upto
)
Thank you, Dan. I have been complaining about this for nearly a month. Bikeman has been saying wait for the optimized app. I think a month is too long to wait for an adjustment (rescale).
RE: RE: Hi all! Thanks
)
I will try the Beta test application and see if there is any improvement. I really hope there is improvement over the 35% plus credit drop I currently am getting with this project on Linux.
Still this should of all been sorted prior to the applications release.
Remember I was going to try
)
Remember I was going to try and do some speed comparisons for workunits from different frequency bands, around two weeks ago?
Well, I finally managed to get rid of all the S5R2 re-sends, and got a couple of good observing runs - plot is crunch time (seconds) against workunit number.
(full-size image)
So they don't keep getting faster and faster - they oscillate.
The blue curve is from host 1001562. I got a full cycle here (with a few gaps), and the average over the cycle was 19.72 credits/hour - very close to the 19.93 credits/hour I averaged for the last few S5R2 WUs using Beta app 4.40. The variation is about +/- 7.5%
The pink curve is from host 1001564. Here, I got a completely consecutive run, but unfortunately the server switched me to another frequency before I'd done a full cycle. The average yield for the points plotted is 20.06 credits/hour, slightly above the 19.84 cr/hr that box got for Beta 4.40, but as you can see the sample was biased towards the faster (better-yielding) part of the curve.
The boxes are identical Q6600s with 2GB RAM each, running at stock speed under Windows XP.
Edit - I meant to add that the 'yield' for Einstein S5R3 varies from a minimum of 17.90, to a maximum of 20.94, credits/hour on these machines.
By comparison, I did a similar timing run on one of them using the current SETI@home application (stock app 5.27 on multibeam data). The average yield for SETI was 23.49 credits/hour, but the variation was from 13.17 to 49.62 cr/hr. Although I ran it for about 200 WUs before installing an optimised application, it's hard to say that I got a true average.
RE: Remember I was going to
)
Richard, let me try to add to your reporting with data from 542.70. My Stoll4 host is a Q6600. During the period in question it ran part of the time at 3.24 GHz, and part at 3.006. I've attempted to adjust the reported CPU time to equivalent 2.4 GHz times by simply multiplying by the frequency ratio. The two oddball points for 45 and 44 switched over in mid-run so this simple adjustment does not work.
Averaged over the points I have, this would give a credits per 2.4 GHz-equivalent CPU hour of 19.05, though I'm not sure how fairly I've sampled the cycle. Also, my overclocked box at 3.24 GHz was running relaxed memory timings, which may have hurt its adjusted speed slightly.
The period of the cyclicity of CPU time required appears to be 60 results, or something very close to that, and matches your data in that respect.
As an aside, BOINClogX made acquiring these data quite simple, though sadly it does not log requested credit, since they were all the same in this case that was not a problem.
RE: I will try the Beta
)
I finished 10 WUs with the Beta 4.09 app, not 35% speedup but not bad:
4.09
28360.57 / 220.74 = 128.48 Sec/Credit
29063.20 / 220.74 = 131.66 Sec/Credit
29995.44 / 220.74 = 135.89 Sec/Credit
30824.41 / 220.74 = 139.64 Sec/Credit
31329.95 / 220.74 = 141.93 Sec/Credit
30516.33 / 220.74 = 138.25 Sec/Credit
29290.84 / 220.74 = 132.69 Sec/Credit
28774.68 / 220.74 = 130.36 Sec/Credit
28893.22 / 220.74 = 130.89 Sec/Credit
28067.86 / 220.74 = 127.15 Sec/Credit
4.09 Beta Average 133.69 Sec/Credit
4.02
32562.63 / 220.28 = 147.82 Sec/Credit
33575.11 / 220.28 = 152.42 Sec/Credit
34321.54 / 220.28 = 155.81 Sec/Credit
32376.54 / 220.28 = 146.98 Sec/Credit
34645.60 / 220.28 = 157.28 Sec/Credit
35249.83 / 220.28 = 160.02 Sec/Credit
33758.51 / 220.28 = 153.25 Sec/Credit
34076.57 / 220.28 = 154.70 Sec/Credit
34012.44 / 220.28 = 154.41 Sec/Credit
4.02 Average 153.63 Sec/Credit
Almost 15% faster for my rig. It helps. But not enough too turn on the other Linux rig quite yet.
Team Philippines
RE: : As an aside,
)
Quote:: As an aside, BOINClogX made acquiring these data quite simple.
Anyone know if there is something like BOINClogx for Apple Macs? Or, does Einstein@Home provide any ability to download the same data contained on the Results and WorkUnit webpages for a Userid in a CSV file (or other format). Right now I automatically read the webpages to pull data from them. But I have to program in a multisecond wait time for each page. To get all my info takes nearly 2 hours. It would be great if I could download all my current information in one text file.
Thanks.
Results statistic from my
)
Results statistic from my Core 2 Duo GHz / ASUS P5K / PC2-6400 Hynix Dual Channel (2x1GB) / WinXPSP2 Prof.
S5R3:
Time (sec) Credit (CS)
33285.83 __ 220.28
32324.22 __ 221.63
32473.45 __ 221.63
32786.00 __ 221.63
32424.31 __ 220.28
31201.34 __ 220.28
31502.55 __ 220.28
------------------
225997.70 _ 1546.01
Average: 0.006840822 CS/sec.
S5R2:
Time (sec) Credit (CS)
92746.97 __ 662.78
93075.20 __ 662,80
93938.95 __ 662,75
------------------
279761.12 _ 1988.33
Average: 0,007107242
Average(S5R3) / Average(S5R2) = 0,962514259.
Only ~ 3.75% difference.
And S5R2 results has been computed on fresh OS with ~2-3% more high speed.
------------------------------------------
P.S.
Some funny (but real!) question:
Can I merge my NEW host into old?
I am a "one host cruncher" with "legendary" host 43575 that started crunch of Einstein units in 22 February 2005 and been restored (and renamed by project server) after OS reinstall in summer of 2007.
I got some favourable
)
I got some favourable comments on the graph I posted last week, so here's an update:
(direct link)
The pink curve is exactly the same as last time, and the yellow/turquoise ones are the next dataset on the same host 1001564. I've been lucky enough to get a continuous plot from result 134 to result 55, and the series is ongoing - the sequence extends to 43 with the results I've been allocated already, and if the scheduler keeps smiling on me, I might even chase it all the way down to 0.
Observations:
Changing from 4.01 to 4.07 seems to have made no difference at all.
The oscillations are not sinusoidal, but glaciated (sharp peaks and rounded valleys - at least, when you plot time rather than speed!)
There are lumps and bumps on the mountain flanks which definitely seem structural, rather than host processor artefacts - they happen repeatedly at the same level on successive cycles.
Stef, the owner of the
)
Stef, the owner of the graphical progress page has updated it to include S5R3 progress.