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.
Winterknight, kindly take your flame baiting back to SETI. Many of us credit hounds as you call us, were still having looping and bombing issues weeks after the switch, not just the first week. This was such an issue many left SETI. Heck my whole team left SETI due to the application issues. All of which have agreed to take a look back at the project in August. Hopefully giving them time to sort all the issues out.
That is why our Team recruiting thread there says out to the beach until August.
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.
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 ...
On Einstein@Home the "Templates" (see aboove) are all identical in the processing time they take on a particular machine, so the total amount of "work" needed for a specific WU can be easily predicted (there is a bit of unpredictable overhead when e.g. restarting the App and processing the checkpoint, but that should be below 0.1% of the total time unless you interrupt the App more than once a minute). The run times of the WUs vary in the the order of +-5% on average, but this is taken into account when granting the credit (again, see my earlier posts).
Please try to avoid continuing the SETI discussion here; let's keep this thread dedicated to the (preliminary) S5 work of Einstein@Home.
Just saw the time expected for the new S-5 compared to the S-4.
Going to be going from 2 1/2 hours to 9 1/2 hours.
Well will give me a good taste as to what the credit system will look like I guess. I know basically what my per hour credit has been running on this machine. So a good test it will be.
Will not be getting to the first S-5 for about 2 days though. So will give some feedback once it is crunched and credit is back.
Just returned my first S5 unit. The claims with 4.61 official beta was 1 credit for 290 seconds, S5 claims 1 credit for 260 seconds. Looks like a fair deal to me.
If have got my first S5-WU´s and would like to ask, if the estimated CPU-time are correct (short 13 min, long 1:56 h A64 3500+) or if I can expect higher times?
And I would also be delighted, if Akos could say a word, if he´s working on opt. apps and how far the work on it is.
2. Will benchmark scores have any relevance to the credit claiming or granting process?
I can't guarantee that there is no unofficial BOINC Client out there that messes around with the information we pass from the Apps for claiming the credit. There may even be some older, official BOINC Clients that don't pass this information correctly. However the credit will be granted based on information exclusively from the server side, so no information from the Client (benchmark, timing etc.) will have an effect on the granted credit.
Since you're passing fpops_cumulative back to server just like Seti_Enhanced is doing, you also have the same limitation, that only v5.2.6 or later BOINC-clients will correctly pass-on this information. Earlier BOINC-clients will base claimed credit on benchmark * cpu-time, but since the validator overrides these values it won't be a problem for granted credit.
As for "optimized" BOINC-clients and so on, atleast until now they're only changing benchmark and reported cpu-time, so will not have any influence on claimed credit.
"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."
If have got my first S5-WU?s and would like to ask, if the estimated CPU-time are correct (short 13 min, long 1:56 h A64 3500+) or if I can expect higher times?
The "Result duration correction factor" is per project, not per application. Meaning, if you runs an optimized S4-application that is maybe 5x faster than the "standard", the "Result duration correction factor" will also be close to 1/5th of that it will expect a "standard" S5-application will be, and the estimated crunch-times is 1/5hth of the "correct" estimates. But, after finishing 1 S5-result, the correction-factor will be immediately increased up to "correct" for S5, and this again means S4-work has estimated 5x longer crunch-times than reality...
Also, if you uses a "calibrated" BOINC-client, not sure, but it's possible S4-claims will be "calibrated" down to 1/5th of that it was earlier...
Quote:
And I would also be delighted, if Akos could say a word, if he?s working on opt. apps and how far the work on it is.
Hopefully all his optimizations is added into the official applications, so everyone gets the benefit of the optimizations.
"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."
And I would also be delighted, if Akos could say a word, if he?s working on opt. apps and how far the work on it is.
Hopefully all his optimizations is added into the official applications, so everyone gets the benefit of the optimizations.
As it has been said, his generic optimizations, and some extra optimizations have been put into the new application. Specific optimizations like SSE, SSE2, SSE3, etc. can not be pushed out, because currently the BOINC system does not relay that information back to the projects as to ask for that deep of an optimization.
So, we are benifiting from AKOS, Bruce, Bernard, et al's, hard work and dedication to the project to make a better application for S5.
I am unsure what the agreements between the Einstein people and Akos is about optimization, but I would like to think that specific processor optimization can be done, again.
Quote:
Since you're passing fpops_cumulative back to server just like Seti_Enhanced is doing, you also have the same limitation, that only v5.2.6 or later BOINC-clients will correctly pass-on this information.
This is wrong for Einstein. The Server side will be giving the final number, not the application. It will ignore any application pushed time calculations and give the numbers per the designated calulations from the server. So it does not matter what BOINC application you run, everyone will be equal.
As a remote dial-up user, S5 presents a new challange.
Major data files are 15.47 MB.
At the blistering xfer speed of about 1.5 MB in a ten minute interval,
15.47 MB will take about 100 minutes.
Try telling the little woman she can't use the phone for a couple hours or so. :-):-)
As it has been said, his generic optimizations, and some extra optimizations have been put into the new application. Specific optimizations like SSE, SSE2, SSE3, etc. can not be pushed out, because currently the BOINC system does not relay that information back to the projects as to ask for that deep of an optimization.
v5.5.xx should pass this info back to server, but it's not even hit alpha yet, so it will be a long time before v5.6.xx is released.
Quote:
Quote:
Since you're passing fpops_cumulative back to server just like Seti_Enhanced is doing, you also have the same limitation, that only v5.2.6 or later BOINC-clients will correctly pass-on this information.
This is wrong for Einstein. The Server side will be giving the final number, not the application. It will ignore any application pushed time calculations and give the numbers per the designated calulations from the server. So it does not matter what BOINC application you run, everyone will be equal.
A good example of that you can get then you takes a quote out of it's contect...
If you re-reads the full quote, and also the text I commented on, you'll likely see:
1; Running earlier BOINC-clients than v5.2.6 will influence the claimed credit.
2; As I clearly stated, it doesn't matter for the granted credit that the claimed-credits is wrong, since the validator overrides the info.
"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."
RE: There were no serious
)
Winterknight, kindly take your flame baiting back to SETI. Many of us credit hounds as you call us, were still having looping and bombing issues weeks after the switch, not just the first week. This was such an issue many left SETI. Heck my whole team left SETI due to the application issues. All of which have agreed to take a look back at the project in August. Hopefully giving them time to sort all the issues out.
That is why our Team recruiting thread there says out to the beach until August.
Come Join us at Hawaiian Beach Bums
RE: RE: I think this may
)
On Einstein@Home the "Templates" (see aboove) are all identical in the processing time they take on a particular machine, so the total amount of "work" needed for a specific WU can be easily predicted (there is a bit of unpredictable overhead when e.g. restarting the App and processing the checkpoint, but that should be below 0.1% of the total time unless you interrupt the App more than once a minute). The run times of the WUs vary in the the order of +-5% on average, but this is taken into account when granting the credit (again, see my earlier posts).
Please try to avoid continuing the SETI discussion here; let's keep this thread dedicated to the (preliminary) S5 work of Einstein@Home.
BM
BM
My apologizes Bernd. And
)
My apologizes Bernd.
And in that spirit, holy cow!!
Just saw the time expected for the new S-5 compared to the S-4.
Going to be going from 2 1/2 hours to 9 1/2 hours.
Well will give me a good taste as to what the credit system will look like I guess. I know basically what my per hour credit has been running on this machine. So a good test it will be.
Will not be getting to the first S-5 for about 2 days though. So will give some feedback once it is crunched and credit is back.
Come Join us at Hawaiian Beach Bums
Just returned my first S5
)
Just returned my first S5 unit. The claims with 4.61 official beta was 1 credit for 290 seconds, S5 claims 1 credit for 260 seconds. Looks like a fair deal to me.
Now where can I opt for always short units? :)
If have got my first S5-WU´s
)
If have got my first S5-WU´s and would like to ask, if the estimated CPU-time are correct (short 13 min, long 1:56 h A64 3500+) or if I can expect higher times?
And I would also be delighted, if Akos could say a word, if he´s working on opt. apps and how far the work on it is.
RE: RE: 2. Will benchmark
)
Since you're passing fpops_cumulative back to server just like Seti_Enhanced is doing, you also have the same limitation, that only v5.2.6 or later BOINC-clients will correctly pass-on this information. Earlier BOINC-clients will base claimed credit on benchmark * cpu-time, but since the validator overrides these values it won't be a problem for granted credit.
As for "optimized" BOINC-clients and so on, atleast until now they're only changing benchmark and reported cpu-time, so will not have any influence on claimed credit.
"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."
RE: If have got my first
)
The "Result duration correction factor" is per project, not per application. Meaning, if you runs an optimized S4-application that is maybe 5x faster than the "standard", the "Result duration correction factor" will also be close to 1/5th of that it will expect a "standard" S5-application will be, and the estimated crunch-times is 1/5hth of the "correct" estimates. But, after finishing 1 S5-result, the correction-factor will be immediately increased up to "correct" for S5, and this again means S4-work has estimated 5x longer crunch-times than reality...
Also, if you uses a "calibrated" BOINC-client, not sure, but it's possible S4-claims will be "calibrated" down to 1/5th of that it was earlier...
Hopefully all his optimizations is added into the official applications, so everyone gets the benefit of the optimizations.
"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."
RE: RE: And I would also
)
As it has been said, his generic optimizations, and some extra optimizations have been put into the new application. Specific optimizations like SSE, SSE2, SSE3, etc. can not be pushed out, because currently the BOINC system does not relay that information back to the projects as to ask for that deep of an optimization.
So, we are benifiting from AKOS, Bruce, Bernard, et al's, hard work and dedication to the project to make a better application for S5.
I am unsure what the agreements between the Einstein people and Akos is about optimization, but I would like to think that specific processor optimization can be done, again.
This is wrong for Einstein. The Server side will be giving the final number, not the application. It will ignore any application pushed time calculations and give the numbers per the designated calulations from the server. So it does not matter what BOINC application you run, everyone will be equal.
As a remote dial-up user, S5
)
As a remote dial-up user, S5 presents a new challange.
Major data files are 15.47 MB.
At the blistering xfer speed of about 1.5 MB in a ten minute interval,
15.47 MB will take about 100 minutes.
Try telling the little woman she can't use the phone for a couple hours or so. :-):-)
Ned
Ol' Retired IT Geezer
RE: As it has been said,
)
v5.5.xx should pass this info back to server, but it's not even hit alpha yet, so it will be a long time before v5.6.xx is released.
A good example of that you can get then you takes a quote out of it's contect...
If you re-reads the full quote, and also the text I commented on, you'll likely see:
1; Running earlier BOINC-clients than v5.2.6 will influence the claimed credit.
2; As I clearly stated, it doesn't matter for the granted credit that the claimed-credits is wrong, since the validator overrides the info.
"I make so many mistakes. But then just think of all the mistakes I don't make, although I might."