Looks like this my host will crunch all of the remained WU's in S5R2 :)
Let it be so... Come on... Gimme all these huge S5R2 WU's - I'll crunch them! :)
On Host 579944, an AMD Opteron 285 running Linux FC3, I have noticed a gradual decline in the average amount of cobblestones/credit/points awarded each month.
[pre]MONTH CRUNCH TIME TYPE FIXED VALUE AVERAGE[/pre]
Not sure about the S5R1 dates as I mainly recorded the crunch times and fixed credit values. Have only recently started adding the WU type.
The average has slowly dropped from low 23's to low to mid 21's.
My average has now taken a dive from 21.47 to 12.36.
From the length of time taken to process I am not enthused by the credit value placed on my work.
A 42.43% drop in average credit.
The S5R3 average was only over 2 work units so I am interested in the others that I have to see if it is still worth the effort.
But we will see.
Well have now processed 4 S5R3 Work Units and the cobblestones per hour are still woeful,
[pre]Work Unit Process Time Claimed Credit Credit/Hour
0518.05 S5R3 66,500.88 221.97 12.02
0518.05 S5R3 62,969.81 221.97 12.69
0518.05 S5R3 63,276.57 221.97 12.63
0518.05 S5R3 60,591.06 221.97 13.19[/pre]
This averages out at just 12.62 credits per hour
My last Sept S5R2 average was 21.47 cr/h (which has been getting lower for months)
Making this an 41.22% DROP in awarded credit.
Only one more to process then I might have to put this project on the backburner in the hope that things will improve.
It was the first project I joined so I would like to keep it going (I would like to get at least to 500,000 cobblestones).
Same expierience , i worked now 6 units and the time is down but the credit per hour is not good its moving between 12.9 to 15.8 cr./hour compared with 21 to 23 cr/hour before. So will put the project to sleep until you have solved this issue.
h1_0059.70_S5R2__2_S5R3a -- is that a frequency of 59.7? I didn't really want to start a thread for this question so I posted here.
I'm used to seeing freqs in the 500 range. An article about GWs I saved on my computer says LIGO is most receptive to freqs from 100 to 3000. Just curious about the 59.7. I could be reading things wrong.
h1_0059.70_S5R2__2_S5R3a -- is that a frequency of 59.7? I didn't really want to start a thread for this question so I posted here.
I'm used to seeing freqs in the 500 range. An article about GWs I saved on my computer says LIGO is most receptive to freqs from 100 to 3000. Just curious about the 59.7. I could be reading things wrong.
You're correct, that's the frequency. Below 100Hz, the land-based interferometers suffer from seismic noise, but at 60 Hz the sensitivity is still high enough to make an analysis worthwhile. That's a good thing as, for example, one of the best known pulsars, the one at the center of Crab Nebula, is spinning at 30Hz, which means, IIRC, that according to theory it could emit a 60Hz gravitational wave.
On Host 579944, an AMD Opteron 285 running Linux FC3, I have noticed a gradual decline in the average amount of cobblestones/credit/points awarded each month.
[pre]MONTH CRUNCH TIME TYPE FIXED VALUE AVERAGE[/pre]
Not sure about the S5R1 dates as I mainly recorded the crunch times and fixed credit values. Have only recently started adding the WU type.
The average has slowly dropped from low 23's to low to mid 21's.
My average has now taken a dive from 21.47 to 12.36.
From the length of time taken to process I am not enthused by the credit value placed on my work.
A 42.43% drop in average credit.
The S5R3 average was only over 2 work units so I am interested in the others that I have to see if it is still worth the effort.
But we will see.
Well have now processed 4 S5R3 Work Units and the cobblestones per hour are still woeful,
[pre]Work Unit Process Time Claimed Credit Credit/Hour
0518.05 S5R3 66,500.88 221.97 12.02
0518.05 S5R3 62,969.81 221.97 12.69
0518.05 S5R3 63,276.57 221.97 12.63
0518.05 S5R3 60,591.06 221.97 13.19[/pre]
This averages out at just 12.62 credits per hour
My last Sept S5R2 average was 21.47 cr/h (which has been getting lower for months)
Making this an 41.22% DROP in awarded credit.
Only one more to process then I might have to put this project on the backburner in the hope that things will improve.
It was the first project I joined so I would like to keep it going (I would like to get at least to 500,000 cobblestones).
Same expierience , i worked now 6 units and the time is down but the credit per hour is not good its moving between 12.9 to 15.8 cr./hour compared with 21 to 23 cr/hour before. So will put the project to sleep until you have solved this issue.
G'Day Einstein,
Very disappointed with the new S5R3 application.
I let another batch download but whilst it has improved a little bit it has not improved enough.
Linux and possibly AMD also taking a big hit on this one.
Whilst a couple are pending the claimed is always 221.97 and the granted is 221.96, so I just put 221.96 for all. The last one (141_S5R3a) is still to complete, so going on Boinc Manager I have estimated the time.
Batch 'h1_0518.05_S5R2__162_S5R3a' to 'h1_0518.05_S5R2__158_S5R3a' have a credit average of just 12.73 cr/h (last S5R2 with 0518.05 frequency was 21.47 cr/h).
This improved a bit with batch 'h1_0518.05_S5R2__144_S5R3a' to 'h1_0518.05_S5R2__142_S5R3a' with 15.66 cr/h and with the estimated h1_0518.05_S5R2__141_S5R3a' came to 15.57 cr/h.
Overall now with 8 finished and 1 almost finished, I have an overall cr/h average on the S5R3 work units of 13.69 (13.85 when estimated 141_S5R3a WU is added).
THIS IS AN OVERALL DROP OF OVER 36% from S5R2 WU's. A small improvement from the initial 42% drop.
A large variation in run times in the same batch (almost 16,000 second difference in my case) of about 23.83%.
Can this please be looked at as I really like this Project and what it can achieve.
I like the science but I also like a value/reward for what I donate.
I too have the presentiment that AMD Athlon64-CPUs are a bit handicaped in S5R3.
Intel Pentium M 745 (1800): ~ 64000 s (219.42 c) (WinXP, 2 results)
Intel Core 2 Duo 6400 (2133): ~ 43300 s (221.33 c) (Win2k3, 4 result)
AMD Sempron 2800+ (1600): ~ 107200 s (218.52 c) (Linux 2.6.22, 1 result)
Maybe the small L2-Cache of the Sempron is a bit hampering but who knows...
I will try to throw in the Computer of my mother (X2 3800) and see, but this will take some time. ;)
I too have the presentiment that AMD Athlon64-CPUs are a bit handicaped in S5R3.
Intel Pentium M 745 (1800): ~ 64000 s (219.42 c) (WinXP, 2 results)
Intel Core 2 Duo 6400 (2133): ~ 43300 s (221.33 c) (Win2k3, 4 result)
AMD Sempron 2800+ (1600): ~ 107200 s (218.52 c) (Linux 2.6.22, 1 result)
Maybe the small L2-Cache of the Sempron is a bit hampering but who knows...
I will try to throw in the Computer of my mother (X2 3800) and see, but this will take some time. ;)
You cant really compare Windows and Linux for s5r3, also Intels running Linux are taking big performance hits. And 1 result on your Sempron isnt much to use for comparision, even on the same frequency r3 results vary too much in crunching time.
About gcc compiled apps, i think its time to say it doesnt affect Macs nearly as much as Linux, using the top 2 computers at einstein the numbers are looking much better for mac:
#2 Adam Brooks dual Xeon 5355 Linux:
s5r2 ~101,000 sec = ~651 credits
s5r3 40,000 to 48,000 = 220.28 credits
Peanuts rig is still increasing its RAC while Adam Brooks rig has been falling quite much since r3 started and will soon be pushed to third place.
From those 2 computers one can see how much r3 varies in CPU time compared to r2, need lots of results to get an idea of average Sec pr Credit, but even the fastest on Linux are slower than the slowest on macs.
Mac? You mean MacOS/BSD against Linux.
Both are PCs from Intel.
My Win2k3 (6400@2,133 GHz) box does not vary in runtime that much (a mere 1%) and is as fast as your 2,66 GHz Xeon under Linux.
Maybe your systems are experiencing PROC_HOT with the new Apps?
My Dual 5050-System has had the same problems back in december 06/january 07: unpredictable, erratic runtimes for a workunit due to this.
Better go check it out. ;)
(Or the new apps for Linux/MacOS/BSD are a bit crappy...)
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
Hello i have a problem einstein@home doesn't work since the S5R3 update !!
i remove the app and the xml info ; but einstein failed to download the S5R3 app for darwin-PPC :
Lun 1 oct 19:46:11 2007||[error] No URL for file transfer of einstein_S5R2_4.34_powerpc-apple-darwin
Lun 1 oct 19:46:11 2007|Einstein@Home|[error] Can't initialize file transfer for einstein_S5R2_4.34_powerpc-apple-darwin
Lun 1 oct 19:46:11 2007||Processor: 1 Power Macintosh Power Macintosh [Power Macintosh Model PowerMac7,2] [AltiVec]
Lun 1 oct 19:46:11 2007||Memory: 1.50 GB physical, 237.89 GB virtual
Lun 1 oct 19:46:11 2007||Disk: 297.97 GB total, 237.65 GB free
Lun 1 oct 19:46:11 2007|Einstein@Home|URL: http://einstein.phys.uwm.edu/; Computer ID: 721621; location: home; project prefs: default
And it appear that einstein try to download a S5R2 app ????
Looks like this my host will
)
Looks like this my host will crunch all of the remained WU's in S5R2 :)
Let it be so... Come on... Gimme all these huge S5R2 WU's - I'll crunch them! :)
RE: RE: On Host 579944,
)
Same expierience , i worked now 6 units and the time is down but the credit per hour is not good its moving between 12.9 to 15.8 cr./hour compared with 21 to 23 cr/hour before. So will put the project to sleep until you have solved this issue.
h1_0059.70_S5R2__2_S5R3a --
)
h1_0059.70_S5R2__2_S5R3a -- is that a frequency of 59.7? I didn't really want to start a thread for this question so I posted here.
I'm used to seeing freqs in the 500 range. An article about GWs I saved on my computer says LIGO is most receptive to freqs from 100 to 3000. Just curious about the 59.7. I could be reading things wrong.
RE: h1_0059.70_S5R2__2_S5R3
)
You're correct, that's the frequency. Below 100Hz, the land-based interferometers suffer from seismic noise, but at 60 Hz the sensitivity is still high enough to make an analysis worthwhile. That's a good thing as, for example, one of the best known pulsars, the one at the center of Crab Nebula, is spinning at 30Hz, which means, IIRC, that according to theory it could emit a 60Hz gravitational wave.
And what a beauty this pulsar is...
More infos here
CU
Bikeman
RE: RE: RE: On Host
)
G'Day Einstein,
Very disappointed with the new S5R3 application.
I let another batch download but whilst it has improved a little bit it has not improved enough.
Linux and possibly AMD also taking a big hit on this one.
[pre] WU TYPE PROCESS SECONDS CREDITS CR/H[/pre]
[pre]87116144 h1_0518.05_S5R2__162_S5R3a_2 66,500.88 221.96 12.02[/pre]
[pre]87123877 h1_0518.05_S5R2__161_S5R3a_1 62,969.81 221.96 12.69[/pre]
[pre]87126596 h1_0518.05_S5R2__160_S5R3a_0 63,276.57 221.96 12.63[/pre]
[pre]87126598 h1_0518.05_S5R2__159_S5R3a_0 60,591.06 221.96 13.20[/pre]
[pre]87126612 h1_0518.05_S5R2__158_S5R3a_0 60,580.76 221.96 13.19[/pre]
[pre]87260824 h1_0518.05_S5R2__144_S5R3a_1 51,072.22 221.96 15.65[/pre]
[pre]87263941 h1_0518.05_S5R2__143_S5R3a_1 51,400.12 221.96 15.55[/pre]
[pre]87266033 h1_0518.05_S5R2__142_S5R3a_1 50,653.28 221.96 15.77[/pre]
[pre] h1_0518.05_S5R2__141_S5R3a_1 52,200.00(est) 221.96 15.31[/pre]
Whilst a couple are pending the claimed is always 221.97 and the granted is 221.96, so I just put 221.96 for all. The last one (141_S5R3a) is still to complete, so going on Boinc Manager I have estimated the time.
Batch 'h1_0518.05_S5R2__162_S5R3a' to 'h1_0518.05_S5R2__158_S5R3a' have a credit average of just 12.73 cr/h (last S5R2 with 0518.05 frequency was 21.47 cr/h).
This improved a bit with batch 'h1_0518.05_S5R2__144_S5R3a' to 'h1_0518.05_S5R2__142_S5R3a' with 15.66 cr/h and with the estimated h1_0518.05_S5R2__141_S5R3a' came to 15.57 cr/h.
Overall now with 8 finished and 1 almost finished, I have an overall cr/h average on the S5R3 work units of 13.69 (13.85 when estimated 141_S5R3a WU is added).
THIS IS AN OVERALL DROP OF OVER 36% from S5R2 WU's. A small improvement from the initial 42% drop.
A large variation in run times in the same batch (almost 16,000 second difference in my case) of about 23.83%.
Can this please be looked at as I really like this Project and what it can achieve.
I like the science but I also like a value/reward for what I donate.
Thanks for your time.
I too have the presentiment
)
I too have the presentiment that AMD Athlon64-CPUs are a bit handicaped in S5R3.
Intel Pentium M 745 (1800): ~ 64000 s (219.42 c) (WinXP, 2 results)
Intel Core 2 Duo 6400 (2133): ~ 43300 s (221.33 c) (Win2k3, 4 result)
AMD Sempron 2800+ (1600): ~ 107200 s (218.52 c) (Linux 2.6.22, 1 result)
Maybe the small L2-Cache of the Sempron is a bit hampering but who knows...
I will try to throw in the Computer of my mother (X2 3800) and see, but this will take some time. ;)
RE: I too have the
)
You cant really compare Windows and Linux for s5r3, also Intels running Linux are taking big performance hits. And 1 result on your Sempron isnt much to use for comparision, even on the same frequency r3 results vary too much in crunching time.
About gcc compiled apps, i think its time to say it doesnt affect Macs nearly as much as Linux, using the top 2 computers at einstein the numbers are looking much better for mac:
#1 Peanuts dual Xeon 5365 Darwin:
s5r2 ~71,700 sec = ~638.25 credits
s5r3 26,000 to 32,000 sec = 219.42 credits
#2 Adam Brooks dual Xeon 5355 Linux:
s5r2 ~101,000 sec = ~651 credits
s5r3 40,000 to 48,000 = 220.28 credits
Peanuts rig is still increasing its RAC while Adam Brooks rig has been falling quite much since r3 started and will soon be pushed to third place.
From those 2 computers one can see how much r3 varies in CPU time compared to r2, need lots of results to get an idea of average Sec pr Credit, but even the fastest on Linux are slower than the slowest on macs.
Team Philippines
Mac? You mean MacOS/BSD
)
Mac? You mean MacOS/BSD against Linux.
Both are PCs from Intel.
My Win2k3 (6400@2,133 GHz) box does not vary in runtime that much (a mere 1%) and is as fast as your 2,66 GHz Xeon under Linux.
Maybe your systems are experiencing PROC_HOT with the new Apps?
My Dual 5050-System has had the same problems back in december 06/january 07: unpredictable, erratic runtimes for a workunit due to this.
Better go check it out. ;)
(Or the new apps for Linux/MacOS/BSD are a bit crappy...)
Hi all! Thanks for all the
)
Hi all!
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 i have a problem
)
Hello i have a problem einstein@home doesn't work since the S5R3 update !!
i remove the app and the xml info ; but einstein failed to download the S5R3 app for darwin-PPC :
Lun 1 oct 19:46:11 2007||[error] No URL for file transfer of einstein_S5R2_4.34_powerpc-apple-darwin
Lun 1 oct 19:46:11 2007|Einstein@Home|[error] Can't initialize file transfer for einstein_S5R2_4.34_powerpc-apple-darwin
Lun 1 oct 19:46:11 2007||Processor: 1 Power Macintosh Power Macintosh [Power Macintosh Model PowerMac7,2] [AltiVec]
Lun 1 oct 19:46:11 2007||Memory: 1.50 GB physical, 237.89 GB virtual
Lun 1 oct 19:46:11 2007||Disk: 297.97 GB total, 237.65 GB free
Lun 1 oct 19:46:11 2007|Einstein@Home|URL: http://einstein.phys.uwm.edu/; Computer ID: 721621; location: home; project prefs: default
And it appear that einstein try to download a S5R2 app ????