I have got some S5 WU now short ones and they have crunched between 3560-3580s on my AMD64 3500+ instead of about 38-40min for the old S4 with S41.07 so that must be good for a standard app, just waitÃng too see when I get a large one too see what time that take.
I'm not aware of what's going on at SETI, and all project people, I think, have their 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?
I didn't read all the postings here, so I don't know if anybody has already explained what was going on at SETI.
SETI has released a new application which doesn't rely on the time * benchmark method anymore to calculate the credit claims. It counts the floating point operations instead. The credit claims of the new system were adjusted to give approximately the same credits per hour like the old system.
But some optimizations were incorporated into the new application. As a result it is much harder to achieve further optimizations. The credit production rate of the "power crunchers" who are using optimized third party applications has dropped by 1/3 to 1/2 because the "bonus" they get with their improved applications has dropped. These power crunchers demanded to adjust the new credit system to get the same credit per hour rate like before. But of course SETI refused to do so, because the average user would claim to much credits. As a result the entire project would claim to much credits compared to other projects.
But I got the impression that nobody really understood why they got the drop of their credit production rate. Everybody blamed the new credit system. But nobody understood that they would also get this drop with the old system.
We are switching to a new uniform system for awarding credits. All users on all platforms will claim the same credit for each workunit, with an amount of credit proportional to the length of the workunit: 'equal credit for equal work'.
Another nice side effect for this is that those who queue quite a bit in advance won't be able to pick n' choose what wunits they want to run so as to make sure they maximize their credit score. I've noticed some that look through their queue and abort work 'cause of being paired with 2 machines that claim low "stock" credit before their machine(s) has gotten around to crunch those wunits.
We are switching to a new uniform system for awarding credits. All users on all platforms will claim the same credit for each workunit, with an amount of credit proportional to the length of the workunit: 'equal credit for equal work'.
Another nice side effect for this is that those who queue quite a bit in advance won't be able to pick n' choose what wunits they want to run so as to make sure they maximize their credit score. I've noticed some that look through their queue and abort work 'cause of being paired with 2 machines that claim low "stock" credit before their machine(s) has gotten around to crunch those wunits.
Yep, I was one of them. But this was only when I was paired with really lowscoring partners e.g. using akos but not using calibrating clients. Belonging decency I never killed WUs where one of the crunching partners would have brought minimum 35 credits for a long or 10 credits for short WU.
At least it was less 10% killing. If you have a fast running machine or a few, you have not the time to look after every WU.
In another thread I stated, “Hopefully Einstein doesn’t make the same mistake as Seti when they switch to S5�
Well, I must have been psychic!!!! In actual fact, Einstein has out done Seti with an additional 32% drop in granted credit.
SETI Enhanced
Pentium 4, 650 3.4 GHz, 2 GB RAM, 2 MB L2, 800 MHz FSB with Hyper Threading ON
5.3.12.tx36 BOINC client and Crunch3r’s Seti SSE3 V5.12 (average of 31 work units)
CPU time = 13,751.11 sec., Claimed credit = 14.38 CS/hr., Granted credit = 14.13 CS/hr.
Einstein New and Improved S5
Pentium 4, 650 3.4 GHz, 2 GB RAM, 2 MB L2, 800 MHz FSB with Hyper Threading ON
5.4.9 BOINC client and 4.02 app. (average of 2 short work units, 1.75 hrs each.)
CPU time = 6,326.31 sec., Claimed credit = 9.60 CS/hr., Granted credit = 9.60 CS/hr.
5.4.9 BOINC client and 4.02 app. (average of 2 long work units, 16.25 hrs each.)
CPU time = 58,479.20 sec., Claimed credit = 9.53 CS/hr., Granted credit = 9.50 CS/hr.
Is this some sinister diabolic plot on the part of those running DC projects to get us credit junkies to run out and buy bigger and faster computers? And/or buy the latest and slickest compiler and spent dozens of hours for nothing compiling faster science apps?
At the moment, both Seti and Einstein are on “No more work�. I’m just trying to decide if I should highlight the BOINC directory and hit DELETE.
Bruce Allen posted: "We are switching to a new uniform system for awarding credits. All users on all platforms will claim the same credit for each workunit, with an amount of credit proportional to the length of the workunit: 'equal credit for equal work'".
Another nice side effect for this is that those who queue quite a bit in advance won't be able to pick n' choose what wunits they want to run so as to make sure they maximize their credit score. I've noticed some that look through their queue and abort work 'cause of being paired with 2 machines that claim low "stock" credit before their machine(s) has gotten around to crunch those wunits.
Yep, I was one of them. But this was only when I was paired with really lowscoring partners e.g. using akos but not using calibrating clients. Belonging decency I never killed WUs where one of the crunching partners would have brought minimum 35 credits for a long or 10 credits for short WU.
At least it was less 10% killing. If you have a fast running machine or a few, you have not the time to look after every WU.
faeshn
Since you decided to step up to the plate... z1_1359.0__215_S4R2a
Yes, you were paired up with really low scoring partners but they were unable to use an Akos client. So they had to wait 4 days for your computer to report that it was GUI aborted and now have to wait another 6 days (avg.) for the 4th participant to finish and report. The other 2 have no choice in the matter to satisfy your 35 credit minimum.
z1_1359.0__231_S4R2a
In this example we have 1 that is using a trux calibrating client with an Akos application but unfortunately fell short of your 35 credit minimum. At least they only had to wait 6 or so days to receive their due.
The reason for my previous post was to point out the 'credit hunting' aspect of dumping units will become a nil point for the S5. Well, at least until the S4 wunits completely run out. Until then I'm sure some will be dumping S5 units that are received mixed in with the S4 to maximize their credit. But hey, the wu's will get sent back out sometime...
Since you decided to step up to the plate... z1_1359.0__215_S4R2a
Yes, you were paired up with really low scoring partners but they were unable to use an Akos client. So they had to wait 4 days for your computer to report that it was GUI aborted and now have to wait another 6 days (avg.) for the 4th participant to finish and report. The other 2 have no choice in the matter to satisfy your 35 credit minimum.
z1_1359.0__231_S4R2a
In this example we have 1 that is using a trux calibrating client with an Akos application but unfortunately fell short of your 35 credit minimum. At least they only had to wait 6 or so days to receive their due.
The reason for my previous post was to point out the 'credit hunting' aspect of dumping units will become a nil point for the S5. Well, at least until the S4 wunits completely run out. Until then I'm sure some will be dumping S5 units that are received mixed in with the S4 to maximize their credit. But hey, the wu's will get sent back out sometime...
I don't feel ashamed. On that 15th I had to change strategy. It was last time that S4-units were aborted because even paired with lowscoring machines will bring more credits than S5. It is the last chance to get (reasonable) credit. When only S5-units will be spread RAC of some windowsmachines will be a fourth than before while RAC of most linuxboxes (specially that 600 dualcoreboxes of Bruce) will rise. Windows and linux are now comparable fast. Same credit for the same unit that is o.k. If there will be no processorspecific or other optimisations I will switch my machine to linux.
I have got some S5 WU now
)
I have got some S5 WU now short ones and they have crunched between 3560-3580s on my AMD64 3500+ instead of about 38-40min for the old S4 with S41.07 so that must be good for a standard app, just waitÃng too see when I get a large one too see what time that take.
Just found in the result for
)
Just found in the result for a S5 app: application version 4.37 here http://einsteinathome.org/task/34194416
Is this correct?
This is also my first finished S5. 53 min on A64 3500+
RE: Just found in the
)
Not sure what you're drinking...CC: 5.4.9,
Application version 4.02
Seti Classic Final Total: 11446 WU.
Hi, RE: I'm not aware of
)
Hi,
I didn't read all the postings here, so I don't know if anybody has already explained what was going on at SETI.
SETI has released a new application which doesn't rely on the time * benchmark method anymore to calculate the credit claims. It counts the floating point operations instead. The credit claims of the new system were adjusted to give approximately the same credits per hour like the old system.
But some optimizations were incorporated into the new application. As a result it is much harder to achieve further optimizations. The credit production rate of the "power crunchers" who are using optimized third party applications has dropped by 1/3 to 1/2 because the "bonus" they get with their improved applications has dropped. These power crunchers demanded to adjust the new credit system to get the same credit per hour rate like before. But of course SETI refused to do so, because the average user would claim to much credits. As a result the entire project would claim to much credits compared to other projects.
But I got the impression that nobody really understood why they got the drop of their credit production rate. Everybody blamed the new credit system. But nobody understood that they would also get this drop with the old system.
Regards,
Carsten
RE: RE: Just found in the
)
Normally I´m only drinking "Krümeltee". Don´t know, what I was looking for...
Bruce Allen
)
Bruce Allen posted:
Another nice side effect for this is that those who queue quite a bit in advance won't be able to pick n' choose what wunits they want to run so as to make sure they maximize their credit score. I've noticed some that look through their queue and abort work 'cause of being paired with 2 machines that claim low "stock" credit before their machine(s) has gotten around to crunch those wunits.
RE: Bruce Allen
)
Yep, I was one of them. But this was only when I was paired with really lowscoring partners e.g. using akos but not using calibrating clients. Belonging decency I never killed WUs where one of the crunching partners would have brought minimum 35 credits for a long or 10 credits for short WU.
At least it was less 10% killing. If you have a fast running machine or a few, you have not the time to look after every WU.
faeshn
In another thread I stated,
)
In another thread I stated, “Hopefully Einstein doesn’t make the same mistake as Seti when they switch to S5�
Well, I must have been psychic!!!! In actual fact, Einstein has out done Seti with an additional 32% drop in granted credit.
SETI Enhanced
Pentium 4, 650 3.4 GHz, 2 GB RAM, 2 MB L2, 800 MHz FSB with Hyper Threading ON
5.3.12.tx36 BOINC client and Crunch3r’s Seti SSE3 V5.12 (average of 31 work units)
CPU time = 13,751.11 sec., Claimed credit = 14.38 CS/hr., Granted credit = 14.13 CS/hr.
Einstein New and Improved S5
Pentium 4, 650 3.4 GHz, 2 GB RAM, 2 MB L2, 800 MHz FSB with Hyper Threading ON
5.4.9 BOINC client and 4.02 app. (average of 2 short work units, 1.75 hrs each.)
CPU time = 6,326.31 sec., Claimed credit = 9.60 CS/hr., Granted credit = 9.60 CS/hr.
5.4.9 BOINC client and 4.02 app. (average of 2 long work units, 16.25 hrs each.)
CPU time = 58,479.20 sec., Claimed credit = 9.53 CS/hr., Granted credit = 9.50 CS/hr.
Is this some sinister diabolic plot on the part of those running DC projects to get us credit junkies to run out and buy bigger and faster computers? And/or buy the latest and slickest compiler and spent dozens of hours for nothing compiling faster science apps?
At the moment, both Seti and Einstein are on “No more work�. I’m just trying to decide if I should highlight the BOINC directory and hit DELETE.
Franz
RE: RE: RE: Bruce Allen
)
Since you decided to step up to the plate... z1_1359.0__215_S4R2a
Yes, you were paired up with really low scoring partners but they were unable to use an Akos client. So they had to wait 4 days for your computer to report that it was GUI aborted and now have to wait another 6 days (avg.) for the 4th participant to finish and report. The other 2 have no choice in the matter to satisfy your 35 credit minimum.
z1_1359.0__231_S4R2a
In this example we have 1 that is using a trux calibrating client with an Akos application but unfortunately fell short of your 35 credit minimum. At least they only had to wait 6 or so days to receive their due.
The reason for my previous post was to point out the 'credit hunting' aspect of dumping units will become a nil point for the S5. Well, at least until the S4 wunits completely run out. Until then I'm sure some will be dumping S5 units that are received mixed in with the S4 to maximize their credit. But hey, the wu's will get sent back out sometime...
RE: Since you decided to
)
I don't feel ashamed. On that 15th I had to change strategy. It was last time that S4-units were aborted because even paired with lowscoring machines will bring more credits than S5. It is the last chance to get (reasonable) credit. When only S5-units will be spread RAC of some windowsmachines will be a fourth than before while RAC of most linuxboxes (specially that 600 dualcoreboxes of Bruce) will rise. Windows and linux are now comparable fast. Same credit for the same unit that is o.k. If there will be no processorspecific or other optimisations I will switch my machine to linux.
Wish you a sunny sunday, faeshn