I am attempting to do a credit analysis for Eric over on the Seti side, please take a moment to email me al.setiboinc (at) gmail.com
Thank You
Pappa
Quote:
Quote:
broadly speaking, it almost has to be approximately equal to the standard credit rate. If einstien were to offer official credit at a substantially different rate, it would cause problems between it's staff and the staff of other projects for screwing with the credit rate.
The intention is that the average Einstein@Home participant will get the same credit per hour "work" than what he gets on other BOINC projects. However with the large variety of Platforms, Apps and Clients we currently have it requires quite some investigation and testing to find out the average participant configuration, or the "standard credit rate" which you mentioned.
I got my S5 unit today as well. Crunch time for older stuff was on the order of an hour and ten minutes to two hours. I'm now at 42% progress after 15 hours and seven minutes with 10 hours and 19 minutes to completion. Here is the last of the messages:
6/15/2006 11:30:42 AM|SETI@home|Deferring task 24mr99ab.21115.31938.754822.3.91_2
6/15/2006 11:30:42 AM|Einstein@Home|Resuming task h1_1362.5_S5R1__3411_S5R1a_1 using einstein_S5R1 version 402
Another older, slower machine got S5 units and went wacko, showing 176 hours to completion and several messages showing that it was "overcommitted".
Will there be any optimized apps coming forth from the project/akos soon? I am refering to platform specific enhancements for say MMX,PIII, sse2,sse3,etc etc...as there are for the S4 search. BM I know you said you plan on improving the speed over the life of the S5.... would be nice to have platform specific enhancements near the start :)
Ignoring the issue of credit (which is always a touchy subject), there's another issue which may drive some crunchers away...
I have a strong preference for projects with work units that don't take more than 2-3 hours to compute on a reasonably fast CPU. There are other like me (scary thought?)
SETI massively increased their WU length. It was one of the reasons I stopped my involvement in that project and came back to Einstein. With AKOS apps, my slowest computer would take 2 hours at worst for a "long" work unit (and the fastest would do them in half an hour). Great!
If S5 work units are going to take over 9 hours on one of my fastest computers (Opteron 248), it is a disincentive for me to stay with Einstein when I can get similar credit elsewhere on work units that don't take as long.
Just offering my point of view on work unit length and how it may affect some people's choice of project, driving them away from Einstein.
We've been promised a scheduler that will selectively assign work unit lengths based on processor speeds. With the new, much larger WUs this is going to be badly needed. Processor specific asm should get a doubling in peroformance at some point, wether from a new batch of hand tweaked executables or the staff finally getting the combined app that can switch between different cpu optimized apps automatically.
4. Is the daily quota staying at 32 or changing to something different?
I'll let Bruce have the final word on it.
BM
I didn't plan to change the daily quota, but if you have machines running out of work, please shout and I will bump it up.
No I don't have a problem with machines running out of work. The two strategies I used for any boxes at risk were (i) Use backup projects, and (ii) Use the BoincStudio client to fake the number of CPUs. Most of the machines I have are of PIII and early P4 vintage and were at risk with the Akos S41.07 app. Judging by the early comments in this thread, we'll all be able to forget about the "Curse of 32" in the future. I had wondered if it might be in your thinking to scale it back a bit but I'm certainly not seeking that. Leaving it at 32 seems to be a very good thing to do as I'm guessing that even the fastest of boxes will have difficulty getting up to that level of production for a while yet :).
Even if it does cause an arguement I feel I must correct these comments.
Quote:
Quote:
I'm not aware of what's going on at SETI, and we all, I think, have our hands full with E@H. Can you give me a short summary (without initiating a new discussion here) what the trouble or different opinions are there @SETI?
The credit issues was a big problem, as was the fact the application was rushed and had some serious bugs still in it. They lengthened the units with a credit change at the same time. So the credit issued did a nose dive to about 1/3 what it was. This credit dive caused serious issues with the people that compete with them. This has hurt the project on total crunchers that left due to the issues.
The credit problem was only an issue with those credit hounds that refused to accept that the Fpops credit system returned the credits claimed/granted to the levels before optimised applications. I can see this also being a problem here.
Quote:
As far as the Application, it had some serious hang and loop issues that really had people bent out of shape. WU's that would run and get to finish, then restart and run again, things of that nature. They also did a complete stop of the old WU's and issued only new WU's with no real blend over period. So when the Bug issues came up, many crunchers had no way to keep going. Many got mad about the whole issue and left completly.
There were no serious bugs in the application, there was a bug server side that caused a few units to hang up or not error out gracefully. this was fixed fairly quickly. It affected those who run large work cache's the most because they tend to download blocks of units from the same tape, most people who run normal 'connect to network' settings only saw one or two of these units. I only saw one using three computers.
There was a period of over a week from first release of the enhanced application until units for the old application ceased.
Quote:
Quote:
The credit will be granted totally based on the size of the Workunits as determined on the server side, regardless of the time it takes a specific host or App to process it. Maesurements have been incorporated in the Apps so that they should also claim this credit for transparency, but the credit actually granted this way doen't need to have anythig to do with the claimed credit anymore.
It seems the credit system you are changing to may be a better solution than what SETI went to. Which was a flop count method. It seems to be in step with the longer WU's. I hope all goes much smoother here. If it does, it may be a model for SETI to change too.
I think this may work, if it is fixed NN credits for long units and fixed nn credits for short units I can see problems if there is any significant variation in process times, this would have to be less than +/- 5% to stop all complaints.
The credit will be granted totally based on the size of the Workunits as determined on the server side, regardless of the time it takes a specific host or App to process it. Maesurements have been incorporated in the Apps so that they should also claim this credit for transparency, but the credit actually granted this way doen't need to have anythig to do with the claimed credit anymore.
It seems the credit system you are changing to may be a better solution than what SETI went to. Which was a flop count method. It seems to be in step with the longer WU's. I hope all goes much smoother here. If it does, it may be a model for SETI to change too.
I think this may work, if it is fixed NN credits for long units and fixed nn credits for short units I can see problems if there is any significant variation in process times, this would have to be less than +/- 5% to stop all complaints.
Basic problem with SETI WUs is that the amount of work to be done for a particular WU is only a rough estimate which is mostly correct but is way off the line for some WUs. SETI came with an idea of measuring exact work done for any particular WU to avoid problems. Wether they succeeded in that or not is another question.
Until a rough analysis of recording data one can not predict how many signal spikes would have to be throughly analysed.
If amount of work can be easily and accurately predicted in advance, then fixing the amount of credit per WU is a way to go. This works perfectly for CPDN and may work fine for EAH S5 ...
Bernd I am attempting to
)
Bernd
I am attempting to do a credit analysis for Eric over on the Seti side, please take a moment to email me al.setiboinc (at) gmail.com
Thank You
Pappa
I got my S5 unit today as
)
I got my S5 unit today as well. Crunch time for older stuff was on the order of an hour and ten minutes to two hours. I'm now at 42% progress after 15 hours and seven minutes with 10 hours and 19 minutes to completion. Here is the last of the messages:
6/15/2006 11:30:42 AM|SETI@home|Deferring task 24mr99ab.21115.31938.754822.3.91_2
6/15/2006 11:30:42 AM|Einstein@Home|Resuming task h1_1362.5_S5R1__3411_S5R1a_1 using einstein_S5R1 version 402
Another older, slower machine got S5 units and went wacko, showing 176 hours to completion and several messages showing that it was "overcommitted".
Will there be any optimized
)
Will there be any optimized apps coming forth from the project/akos soon? I am refering to platform specific enhancements for say MMX,PIII, sse2,sse3,etc etc...as there are for the S4 search. BM I know you said you plan on improving the speed over the life of the S5.... would be nice to have platform specific enhancements near the start :)
Ignoring the issue of credit
)
Ignoring the issue of credit (which is always a touchy subject), there's another issue which may drive some crunchers away...
I have a strong preference for projects with work units that don't take more than 2-3 hours to compute on a reasonably fast CPU. There are other like me (scary thought?)
SETI massively increased their WU length. It was one of the reasons I stopped my involvement in that project and came back to Einstein. With AKOS apps, my slowest computer would take 2 hours at worst for a "long" work unit (and the fastest would do them in half an hour). Great!
If S5 work units are going to take over 9 hours on one of my fastest computers (Opteron 248), it is a disincentive for me to stay with Einstein when I can get similar credit elsewhere on work units that don't take as long.
Just offering my point of view on work unit length and how it may affect some people's choice of project, driving them away from Einstein.
Join the #1 Aussie Alliance on Einstein
RE: RE: One think (okay,
)
Thanks for that! I didn't realize that the app used "at most" as "at least" also.
.
We've been promised a
)
We've been promised a scheduler that will selectively assign work unit lengths based on processor speeds. With the new, much larger WUs this is going to be badly needed. Processor specific asm should get a doubling in peroformance at some point, wether from a new batch of hand tweaked executables or the staff finally getting the combined app that can switch between different cpu optimized apps automatically.
Perhaps a bit early for
)
Perhaps a bit early for predictions, but it's beginning to look like the mass exodus from Seti may be repeated here also. I hope not.
Like it or not:
longer WUs + lower credit / hour = fewer crunchers
RE: RE: RE: 4. Is the
)
No I don't have a problem with machines running out of work. The two strategies I used for any boxes at risk were (i) Use backup projects, and (ii) Use the BoincStudio client to fake the number of CPUs. Most of the machines I have are of PIII and early P4 vintage and were at risk with the Akos S41.07 app. Judging by the early comments in this thread, we'll all be able to forget about the "Curse of 32" in the future. I had wondered if it might be in your thinking to scale it back a bit but I'm certainly not seeking that. Leaving it at 32 seems to be a very good thing to do as I'm guessing that even the fastest of boxes will have difficulty getting up to that level of production for a while yet :).
Cheers,
Cheers,
Gary.
Even if it does cause an
)
Even if it does cause an arguement I feel I must correct these comments.
The credit problem was only an issue with those credit hounds that refused to accept that the Fpops credit system returned the credits claimed/granted to the levels before optimised applications. I can see this also being a problem here.
There were no serious bugs in the application, there was a bug server side that caused a few units to hang up or not error out gracefully. this was fixed fairly quickly. It affected those who run large work cache's the most because they tend to download blocks of units from the same tape, most people who run normal 'connect to network' settings only saw one or two of these units. I only saw one using three computers.
There was a period of over a week from first release of the enhanced application until units for the old application ceased.
I think this may work, if it is fixed NN credits for long units and fixed nn credits for short units I can see problems if there is any significant variation in process times, this would have to be less than +/- 5% to stop all complaints.
Andy
RE: RE: RE: The credit
)
Basic problem with SETI WUs is that the amount of work to be done for a particular WU is only a rough estimate which is mostly correct but is way off the line for some WUs. SETI came with an idea of measuring exact work done for any particular WU to avoid problems. Wether they succeeded in that or not is another question.
Until a rough analysis of recording data one can not predict how many signal spikes would have to be throughly analysed.
If amount of work can be easily and accurately predicted in advance, then fixing the amount of credit per WU is a way to go. This works perfectly for CPDN and may work fine for EAH S5 ...
[edit] formatting
Metod ...