Don't get me wrong, I didn't mean to say credits will definitely be lower, but that you should not expect them to remain the same, just because the apps are more or less the same. We will see next week. My personal view is that with the power/beta apps (and new S5R4 stock apps) E@H is now a bit over the average credits rate.
Actually in in the last weeks Einstein@home has been awarding 25% more credit on average than SETI@home. And the only reason for no credit adjustment being done within the run was just that it turned out to be too late for that (i.e. too close to the end of the run) anyway. We are currently making the final adjustments, but you should expect to get in the order of 20-25% less credit per CPU hour than in S5R3, especially if you ran PowerApps.
As far as BOINC goes... If you don't auger it in once in awhile, you're not trying hard enough. ;-)
Alinator
Sheesh Alinator, you just had to type those prophetic words without knocking on wood, didn't you?
So I'm back home, and I didn't run out of Einstein work, but one machine mysteriously locked up while I was gone so it didn't crunch anything for 4-5 days and another decided to go stupid on me and crashed every task for every project for 3 days until I could get back and reboot it. (whatever the problem was, it also prevented me from remoting in and rebooting... sigh :P) I've not had that happen for years.
I KNEW I should have knocked my forehead on something the moment I read your words!
Don't get me wrong, I didn't mean to say credits will definitely be lower, but that you should not expect them to remain the same, just because the apps are more or less the same. We will see next week. My personal view is that with the power/beta apps (and new S5R4 stock apps) E@H is now a bit over the average credits rate.
Actually in in the last weeks Einstein@home has been awarding 25% more credit on average than SETI@home. And the only reason for no credit adjustment being done within the run was just that it turned out to be too late for that (i.e. too close to the end of the run) anyway. We are currently making the final adjustments, but you should expect to get in the order of 20-25% less credit per CPU hour than in S5R3, especially if you ran PowerApps.
BM
They're arguing at Seti over the credit thing as a lot of people are complaining about Seti lowering their credits per hour with their new astropulse application. I think it has something to do with so many users using optimized clients that its throwing off the "Gold Standard" benchmark.
I'm not worried about it as long as I receive something above zero for my time.
[edit] Seti is just a fall back project for when there trouble here so my systems aren't idle. Guess you can tell what my main project is by my stats.
[/edit]
From what I am seeing, it seems there are some pretty real communications issues with S5R3 ending and the ramp up for the next series. For me, the best solution is to simply configure for no new work, and then on completion of existing work units hopefully be able to ram them thru the report process.
Then, assuming the new work availability settles down, I'll reset for new work from Einstein.
Thanks Bikeman, Ok as no more work will come for a while I will stop my computers asking for work and complete what I have then set to no new work, for a few days.
That's not quite right as there will be a flow of "high paying" resend work for the next several weeks. If you actually leave your app_info.xml file in place at the moment, when the new servers come back up next week, you should be able to get resend work from what has accumulated over the weekend. You wont get any "lower paying" new stuff but you can console yourself with the thought that you are doing your civic duty by helping clean up the old at the higher pay rate :-).
You really don't need to get the new app immediately and the scramble to get it may cause a frustrating time of congestion anyway. As there will be no primary S5R3 work next week, your client may have to ask a few times before getting some resends. If resends seem to be thin on the ground and you actually run out, then delete app_info and join the S5R4 scramble. At that time if you want to continue to do your civic duty, you could run both the new app and the old app under the anonymous platform mechanism (app_info.xml). Even in a month's time, someone will still need to be running the old app to handle the resends that will still be trickling through the system.
I expect to publish a suitable example of app_info.xml (probably around next Tuesday) for the benefit of those who wish to assist with the ongoing cleanup. You can always do it for yourself by following the links that Bikeman mentioned.
They're arguing at Seti over the credit thing as a lot of people are complaining about Seti lowering their credits per hour with their new astropulse application. I think it has something to do with so many users using optimized clients that its throwing off the "Gold Standard" benchmark.
To clarify [ and NOT to start yet another pie fight on the issue ] you are referring to optimised BOINC clients at SETI?
[ Which is not relevant here at EAH, as credit is determined server-side. It is the science apps that are the subject of optimisation at E@H. ]
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
They're arguing at Seti over the credit thing as a lot of people are complaining about Seti lowering their credits per hour with their new astropulse application. I think it has something to do with so many users using optimized clients that its throwing off the "Gold Standard" benchmark.
To clarify [ and NOT to start yet another pie fight on the issue ] you are referring to optimised BOINC clients at SETI?
[ Which is not relevant here at EAH, as credit is determined server-side. It is the science apps that are the subject of optimisation at E@H. ]
Cheers, Mike.
No, there is apparently going to be/has been a server-side adjustment that is reducing the credit multiplier for S@H WUs (regardless of opt-app or not). This is because the 'older' S@H science app awards ~15% more credit than it 'should' be awarding based on the 'Gold Standard' 100 credit/day system. (A bunch of nonsense if you ask me...but they didn't). Anyway, this should bring the S@H science app in line with the new Astropulse application so far as credit award on a per hour basis is concerned.
The major uproar at this point is that the credit multiplier is going to be re-adjusted on an on-going basis based on some mythical monthly rolling average project-wide. See this thread if you think you can stomach it.
They're arguing at Seti over the credit thing as a lot of people are complaining about Seti lowering their credits per hour with their new astropulse application. I think it has something to do with so many users using optimized clients that its throwing off the "Gold Standard" benchmark.
To clarify [ and NOT to start yet another pie fight on the issue ] you are referring to optimised BOINC clients at SETI?
[ Which is not relevant here at EAH, as credit is determined server-side. It is the science apps that are the subject of optimisation at E@H. ]
Cheers, Mike.
No, there is apparently going to be/has been a server-side adjustment that is reducing the credit multiplier for S@H WUs (regardless of opt-app or not). This is because the 'older' S@H science app awards ~15% more credit than it 'should' be awarding based on the 'Gold Standard' 100 credit/day system. (A bunch of nonsense if you ask me...but they didn't). Anyway, this should bring the S@H science app in line with the new Astropulse application so far as credit award on a per hour basis is concerned.
The major uproar at this point is that the credit multiplier is going to be re-adjusted on an on-going basis based on some mythical monthly rolling average project-wide. See this thread if you think you can stomach it.
The server side adjustment is not about the astropulse (AP) app, but because Seti is said to grant about 15% more than the average project. As per the first col of figures in Granted credit comparison.
The proposed low credits for AP when it is released, along with its long processing time, 40 hrs on Q6600, or 80+ on X2 6000+ is a separate problem.
If the new server side adjustment works correctly, then after about a month, the granted credits for all applications should be in line with each other.
AS Seti uses Flop counting to claim credits the optimised BOINC clients have no effect on Seti. The Flop counting method was introduced slightly before Einstein went to server side defined credits. If a host is still using an old client then under the validation rules the high claim is thrown out when using a quorum of two or three.
edit] If Seti is correct in its assessment of granting 15% above average then Einstein's granted credits might have to come down over 40% to remain in line. [/edit
.... See this thread if you think you can stomach it.
OOOOooooo .... tense ..... sort of sorry I asked now :-)
I seemed to follow that thread, generally, but what is the 'kitties' reference? Some hardware type?
So there's some co-incidence of several decisions/changes impacting there.
I gather 'flop counting' refers to the total number of flops executed for a given work unit. A proxy measure of algorithmic complexity. But who/what does the counting? Is it the BOINC client?
I never quite appreciated the cross-project complexities [ well I've always crunched purely for E@H, so I have been insulated-from/indifferent-to that aspect ]. The early, and good, decision to have a common modus operandi for DC, ie. BOINC, while quite an enabling technology is also the soil for the sociological side. The lever/weapon/deal is the 'credit' concept.
Cheers, Mike.
( edit ) Re-reading this post I think I'm going to sound rather naive. Anyone for telling me to get out more ? :-)
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
but what is the 'kitties' reference? Some hardware type?
Mark is very, very, very much into cats...
Quote:
I gather 'flop counting' refers to the total number of flops executed for a given work unit. A proxy measure of algorithmic complexity. But who/what does the counting? Is it the BOINC client?
Science application, reported in it and back into the client. Client needs to be at least 5.2.6 (or 5.2.7) to support it. This is why there are other discussions over there about how SETI did not force that to be the minimum version. The reason was because of a problem with NTLM proxy communications, i.e. they didn't work properly, so anyone who used that type of proxy would be "cut off" from doing work for SETI. The further unverified claim to contine to support not requiring the version as a minimum was the assumption that there was some nebulous "sponsor" that would get cut off and the fear of retribution of cutting off the funding and/or donations. That morphed over time to be a "no computer left behind" type of thing, where there was a decree that someone who installed 4.19 or 4.45 back in the day and just never updated still deserved to do science, even though those BOINC clients underclaimed (sometimes by 50%) and thus drug down granted credits. Statisticians amongst the SETI crowd typically made a statement that "all of us have an equal chance of being short-changed", so it drug on and on and on... For even more fun, they had a minimum at one point of 4.19, but even that was discontinued or got broken, as BOINC 3.x clients could get work. The credit situation on that if you were "lucky" enough to get paired up with one of those clients is...well...you got zero credits, as that's what the 3.x client was going to claim, and thus it is what you got since the grant is the lower of the two. 3.x and 4.x clients are still running amok there, still causing the short-changing in credits to various unsuspecting people, and some of us who do suspect it... It is rumored that some recent version of BOINC fixed the issue (libcurl update in it, I think), but no minimum version has been set to address the older clients. Not sure how that is going to work with this new plan, as even with the new plan, if I was paired up with a 3.x client over there, I'd be getting a goose egg.
[/my involvement in this touchy subject on this forum]
RE: Don't get me wrong, I
)
Actually in in the last weeks Einstein@home has been awarding 25% more credit on average than SETI@home. And the only reason for no credit adjustment being done within the run was just that it turned out to be too late for that (i.e. too close to the end of the run) anyway. We are currently making the final adjustments, but you should expect to get in the order of 20-25% less credit per CPU hour than in S5R3, especially if you ran PowerApps.
BM
BM
RE: As far as BOINC goes...
)
Sheesh Alinator, you just had to type those prophetic words without knocking on wood, didn't you?
So I'm back home, and I didn't run out of Einstein work, but one machine mysteriously locked up while I was gone so it didn't crunch anything for 4-5 days and another decided to go stupid on me and crashed every task for every project for 3 days until I could get back and reboot it. (whatever the problem was, it also prevented me from remoting in and rebooting... sigh :P) I've not had that happen for years.
I KNEW I should have knocked my forehead on something the moment I read your words!
So does this mean I'm trying hard enough? ;)
RE: RE: Don't get me
)
They're arguing at Seti over the credit thing as a lot of people are complaining about Seti lowering their credits per hour with their new astropulse application. I think it has something to do with so many users using optimized clients that its throwing off the "Gold Standard" benchmark.
I'm not worried about it as long as I receive something above zero for my time.
[edit] Seti is just a fall back project for when there trouble here so my systems aren't idle. Guess you can tell what my main project is by my stats.
[/edit]
From what I am seeing, it
)
From what I am seeing, it seems there are some pretty real communications issues with S5R3 ending and the ramp up for the next series. For me, the best solution is to simply configure for no new work, and then on completion of existing work units hopefully be able to ram them thru the report process.
Then, assuming the new work availability settles down, I'll reset for new work from Einstein.
RE: Thanks Bikeman,Ok as no
)
That's not quite right as there will be a flow of "high paying" resend work for the next several weeks. If you actually leave your app_info.xml file in place at the moment, when the new servers come back up next week, you should be able to get resend work from what has accumulated over the weekend. You wont get any "lower paying" new stuff but you can console yourself with the thought that you are doing your civic duty by helping clean up the old at the higher pay rate :-).
You really don't need to get the new app immediately and the scramble to get it may cause a frustrating time of congestion anyway. As there will be no primary S5R3 work next week, your client may have to ask a few times before getting some resends. If resends seem to be thin on the ground and you actually run out, then delete app_info and join the S5R4 scramble. At that time if you want to continue to do your civic duty, you could run both the new app and the old app under the anonymous platform mechanism (app_info.xml). Even in a month's time, someone will still need to be running the old app to handle the resends that will still be trickling through the system.
I expect to publish a suitable example of app_info.xml (probably around next Tuesday) for the benefit of those who wish to assist with the ongoing cleanup. You can always do it for yourself by following the links that Bikeman mentioned.
Cheers,
Gary.
RE: They're arguing at Seti
)
To clarify [ and NOT to start yet another pie fight on the issue ] you are referring to optimised BOINC clients at SETI?
[ Which is not relevant here at EAH, as credit is determined server-side. It is the science apps that are the subject of optimisation at E@H. ]
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: RE: They're arguing
)
No, there is apparently going to be/has been a server-side adjustment that is reducing the credit multiplier for S@H WUs (regardless of opt-app or not). This is because the 'older' S@H science app awards ~15% more credit than it 'should' be awarding based on the 'Gold Standard' 100 credit/day system. (A bunch of nonsense if you ask me...but they didn't). Anyway, this should bring the S@H science app in line with the new Astropulse application so far as credit award on a per hour basis is concerned.
The major uproar at this point is that the credit multiplier is going to be re-adjusted on an on-going basis based on some mythical monthly rolling average project-wide. See this thread if you think you can stomach it.
Seti Classic Final Total: 11446 WU.
RE: RE: RE: They're
)
The server side adjustment is not about the astropulse (AP) app, but because Seti is said to grant about 15% more than the average project. As per the first col of figures in Granted credit comparison.
The proposed low credits for AP when it is released, along with its long processing time, 40 hrs on Q6600, or 80+ on X2 6000+ is a separate problem.
If the new server side adjustment works correctly, then after about a month, the granted credits for all applications should be in line with each other.
AS Seti uses Flop counting to claim credits the optimised BOINC clients have no effect on Seti. The Flop counting method was introduced slightly before Einstein went to server side defined credits. If a host is still using an old client then under the validation rules the high claim is thrown out when using a quorum of two or three.
edit] If Seti is correct in its assessment of granting 15% above average then Einstein's granted credits might have to come down over 40% to remain in line. [/edit
RE: .... See this thread
)
OOOOooooo .... tense ..... sort of sorry I asked now :-)
I seemed to follow that thread, generally, but what is the 'kitties' reference? Some hardware type?
So there's some co-incidence of several decisions/changes impacting there.
I gather 'flop counting' refers to the total number of flops executed for a given work unit. A proxy measure of algorithmic complexity. But who/what does the counting? Is it the BOINC client?
I never quite appreciated the cross-project complexities [ well I've always crunched purely for E@H, so I have been insulated-from/indifferent-to that aspect ]. The early, and good, decision to have a common modus operandi for DC, ie. BOINC, while quite an enabling technology is also the soil for the sociological side. The lever/weapon/deal is the 'credit' concept.
Cheers, Mike.
( edit ) Re-reading this post I think I'm going to sound rather naive. Anyone for telling me to get out more ? :-)
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: but what is the
)
Mark is very, very, very much into cats...
Science application, reported in it and back into the client. Client needs to be at least 5.2.6 (or 5.2.7) to support it. This is why there are other discussions over there about how SETI did not force that to be the minimum version. The reason was because of a problem with NTLM proxy communications, i.e. they didn't work properly, so anyone who used that type of proxy would be "cut off" from doing work for SETI. The further unverified claim to contine to support not requiring the version as a minimum was the assumption that there was some nebulous "sponsor" that would get cut off and the fear of retribution of cutting off the funding and/or donations. That morphed over time to be a "no computer left behind" type of thing, where there was a decree that someone who installed 4.19 or 4.45 back in the day and just never updated still deserved to do science, even though those BOINC clients underclaimed (sometimes by 50%) and thus drug down granted credits. Statisticians amongst the SETI crowd typically made a statement that "all of us have an equal chance of being short-changed", so it drug on and on and on... For even more fun, they had a minimum at one point of 4.19, but even that was discontinued or got broken, as BOINC 3.x clients could get work. The credit situation on that if you were "lucky" enough to get paired up with one of those clients is...well...you got zero credits, as that's what the 3.x client was going to claim, and thus it is what you got since the grant is the lower of the two. 3.x and 4.x clients are still running amok there, still causing the short-changing in credits to various unsuspecting people, and some of us who do suspect it... It is rumored that some recent version of BOINC fixed the issue (libcurl update in it, I think), but no minimum version has been set to address the older clients. Not sure how that is going to work with this new plan, as even with the new plan, if I was paired up with a 3.x client over there, I'd be getting a goose egg.
[/my involvement in this touchy subject on this forum]