For the past week I have been watching my RAC drop and my quad's position in the top 20 computers slip. I was kinda curious as to why my position was slipping that much with a Q6600 phase cooled and running at 3.87ghz. Why are the other top 20 not falling with me?

I did a bit of poking around and I think I have my answer. Of the 11 rigs above me, 9 of them seem to be overclaiming credit. Using either 2.2b Chicken or Alex Kan's Mac app. And the trouble is, they are getting the benefit of their overclaiming a fair percentage of the time, because they are paired with another user who also is using 2.2b or Alex's app, so both are getting the overclaimed credit amount. Which is not fair to other users on the stock app or updated Chicken apps, nor good for the project long term.

When Simon and crunch3r released the new optimized apps, I took the high road and tried to set an example here by doing the honorable thing and updating all of my rigs to the new app with the corrected credit multiplier. And it is now costing me in terms of credit earned. Which I can live with.

But I am starting to see that many others here have neither followed my example nor honored Simon's request that all optimized app users update their apps to be in compliance with the Seti project's new credit calibration.

I would again ask that all optimized app users update to the current science apps. I do not know if Alex's Mac apps have been updated with the correct credit multi or not. If not, I understand, but I would hope tha Alex would correct the situation very soon.

And I would ask even more strongly that the high profile users in the top 100 list (especially the top 20) do what it right and get your rigs in compliance with the project. Do what is right please. I know this is a hard thing to do when you are proud of your current position. You are leading the way in Seti crunching production, please help me set an example and do it within the current set of rules.

If there are enough users that continue to abuse the 'anonymous platform' and refuse to update their apps, I fear that at some point, the admins could say 'enough is enough' and do away with the problem by dissallowing the use of anything other than the stock app. Please let's not let it come to that.

And the kitties say....'Thank You'.

---

"Time is simply the mechanism that keeps everything from happening all at once."

If there are enough users that continue to abuse the 'anonymous platform' and refuse to update their apps, I fear that at some point, the admins could say 'enough is enough' and do away with the problem by dissallowing the use of anything other than the stock app.

They should somehow make optimized apps the stock app so that no one would have to manually download and install them. I think this is possible some day.

---

Manned mission to Mars in 2019 Petition <-- Sign this, please.

If there are enough users that continue to abuse the 'anonymous platform' and refuse to update their apps, I fear that at some point, the admins could say 'enough is enough' and do away with the problem by dissallowing the use of anything other than the stock app.

They should somehow make optimized apps the stock app so that no one would have to manually download and install them. I think this is possible some day.

Yes, it is possible. It's just that at the current time, the project admins do have the resources in terms of time to devote to such a change. It would be a major undertaking, considering all of the code changes required to support the multitude of individual platforms out there running Seti. But maybe some day, if the project it's primary work done, it could happen.
Until then, we will all just have to try to work things out.

So let's all try to work within the system and rules that are in place right now and make it work.

---

"Time is simply the mechanism that keeps everything from happening all at once."

If there are enough users that continue to abuse the 'anonymous platform' and refuse to update their apps, I fear that at some point, the admins could say 'enough is enough' and do away with the problem by dissallowing the use of anything other than the stock app.

They should somehow make optimized apps the stock app so that no one would have to manually download and install them. I think this is possible some day.

As the units are marked with a Berkeley version number, 5.27 at present, who would your computer be informed that the optimised app you use, which comes from Simons lunatics site, has been updated, due to the optimiser's finding further enhancements. It could be that the new enhancement is for Intel SSSE3 capable cpu's only, so all other versions remain as they are.

I think if you look at it from the other side you will soon find it is a management nightmare.

The best you could hope for is a script that tells your computer to contact Simons site periodically and check if the optimised app hes been upgraded, download it and do a pop-up, like MS, firefox or AV s/ware, to say it is here and do you want to install.

Don't forget your wishes either divert Berkeley staff from essential work, or you are asking Simon et al to go way beyond what can be expected, they passed that threshold ages ago.

Andy

If there are enough users that continue to abuse the 'anonymous platform' and refuse to update their apps, I fear that at some point, the admins could say 'enough is enough' and do away with the problem by dissallowing the use of anything other than the stock app.

They should somehow make optimized apps the stock app so that no one would have to manually download and install them. I think this is possible some day.

As the units are marked with a Berkeley version number, 5.27 at present, who would your computer be informed that the optimised app you use, which comes from Simons lunatics site, has been updated, due to the optimiser's finding further enhancements. It could be that the new enhancement is for Intel SSSE3 capable cpu's only, so all other versions remain as they are.

I think if you look at it from the other side you will soon find it is a management nightmare.

The best you could hope for is a script that tells your computer to contact Simons site periodically and check if the optimised app hes been upgraded, download it and do a pop-up, like MS, firefox or AV s/ware, to say it is here and do you want to install.

Don't forget your wishes either divert Berkeley staff from essential work, or you are asking Simon et al to go way beyond what can be expected, they passed that threshold ages ago.

Andy

All of your points are valid, I was just saying that it is technically possible IF the project had the resources to devote to it. It would be possible to have an optimized app data bank at Seti with the best tested app for each platform, with the correct coding to direct each platform to it's correct download.
It's a valid concept, but would only be possible if Seti had the resources to devote to it, which they do not at present.

So for now, we have to ask that users do it manually.

But could we please limit further discussion in this thread to responses to my initial request that all users update their apps? Just so as not to sidetrack the point.

Thank You.

---

"Time is simply the mechanism that keeps everything from happening all at once."

If there are enough users that continue to abuse the 'anonymous platform' and refuse to update their apps, I fear that at some point, the admins could say 'enough is enough' and do away with the problem by dissallowing the use of anything other than the stock app.

They should somehow make optimized apps the stock app so that no one would have to manually download and install them. I think this is possible some day.

Yes, it is possible. It's just that at the current time, the project admins do have the resources in terms of time to devote to such a change. It would be a major undertaking, considering all of the code changes required to support the multitude of individual platforms out there running Seti. But maybe some day, if the project it's primary work done, it could happen.
Until then, we will all just have to try to work things out.

So let's all try to work within the system and rules that are in place right now and make it work.

I think I made my point with the X-Project, in the mean time, I agree with you, even with incredible hardware, and optimized software to death, I barely catch up with them, and trust me, I putted a lot of effort into it. I beat them, as my units reported it, but by a little at stock frequency. I don't want to say the frequency of X-Project, but I should get a RAC much higher than them, it is for sure.

There is definitely something wrong about it. I though about doing the same on my own code, but I don't think it is appropriate.

I guess, I ll just return to Rosetta, where competition is fair.
Let me know when we are doing with "over-reporting" on SETI.

this unit is the perfect example of the tricks in action, this units should report a credit of 30, as the entier lot of units.
Here is the right behavior for the same lot of units: unit over estimated
since the server requires only 2 PC to agree on the units, it is 33% more often that 2 PC agrees on over estimating a workload. Since the fast renderer use the over estimated version, they get 35/30 ==> 16% RAC increase.
I found this few weeks ago, I just did not dare to say, affraid to get "hooooo" from the top guys.

16% is quiet a "trick" ... in some case, it goes up to 49% ... on this one, Alex computer tried to get 45 credit, while the right amout is 30 , this temptative failled, but it succeed here: 49% performance for free!!!! (This units is reported by Both V2.2B, and the credit should be 30, not 45!)

The fact that 2 computers only are required to validate a unit increase dramatically the chance the get over-estimated credit. the admin needs to do something, 49% credit increase on a workload is not acceptable.

I know it is not Alex intentionally cheating, he does not have the control on this, it is just the statistic helping people who use OVER-REPORTING.

Mister Admin, any plan to fix this? (You got hard fact here)

who?

If there are enough users that continue to abuse the 'anonymous platform' and refuse to update their apps, I fear that at some point, the admins could say 'enough is enough' and do away with the problem by dissallowing the use of anything other than the stock app.

They should somehow make optimized apps the stock app so that no one would have to manually download and install them. I think this is possible some day.

Yes, it is possible. It's just that at the current time, the project admins do have the resources in terms of time to devote to such a change. It would be a major undertaking, considering all of the code changes required to support the multitude of individual platforms out there running Seti. But maybe some day, if the project it's primary work done, it could happen.
Until then, we will all just have to try to work things out.

So let's all try to work within the system and rules that are in place right now and make it work.

I think I made my point with the X-Project, in the mean time, I agree with you, even with incredible hardware, and optimized software to death, I barely catch up with them, and trust me, I putted a lot of effort into it. I beat them, as my units reported it, but by a little at stock frequency. I don't want to say the frequency of X-Project, but I should get a RAC much higher than them, it is for sure.

There is definitely something wrong about it. I though about doing the same on my own code, but I don't think it is appropriate.

I guess, I ll just return to Rosetta, where competition is fair.
Let me know when we are doing with "over-reporting" on SETI.

this unit is the perfect example of the tricks in action, this units should report a credit of 30, as the entier lot of units.
Here is the right behavior for the same lot of units: unit over estimated
since the server requires only 2 PC to agree on the units, it is 33% more often that 2 PC agrees on over estimating a workload. Since the fast renderer use the over estimated version, they get 35/30 ==> 16% RAC increase.
I found this few weeks ago, I just did not dare to say, affraid to get "hooooo" from the top guys.

16% is quiet a "trick" ... in some case, it goes up to 49% ... on this one , the temptative failled, but it succeed here: 49% performance for free!!!! (This units is reported by Both V2.2B, and the credit should be 30, not 45!)

The fact that 2 computers only are required to validate a unit increase dramatically the chance the get over-estimated credit. the admin needs to do something, 49% credit increase on a workload is not acceptable.

I know it is not Alex intentionally cheating, he does not have the control on this, it is just the statistic helping people who use OVER-REPORTING.

Mister Admin, any plan to fix this? (You got hard fact here)

who?

Who?....please check out my 'possible credit multiplier solution' thread for a thought I had on a way to fix this, and a response with another good possiblity.

---

"Time is simply the mechanism that keeps everything from happening all at once."

If there are enough users that continue to abuse the 'anonymous platform' and refuse to update their apps, I fear that at some point, the admins could say 'enough is enough' and do away with the problem by dissallowing the use of anything other than the stock app.

They should somehow make optimized apps the stock app so that no one would have to manually download and install them. I think this is possible some day.

Yes, it is possible. It's just that at the current time, the project admins do have the resources in terms of time to devote to such a change. It would be a major undertaking, considering all of the code changes required to support the multitude of individual platforms out there running Seti. But maybe some day, if the project it's primary work done, it could happen.
Until then, we will all just have to try to work things out.

So let's all try to work within the system and rules that are in place right now and make it work.

I think I made my point with the X-Project, in the mean time, I agree with you, even with incredible hardware, and optimized software to death, I barely catch up with them, and trust me, I putted a lot of effort into it. I beat them, as my units reported it, but by a little at stock frequency. I don't want to say the frequency of X-Project, but I should get a RAC much higher than them, it is for sure.

There is definitely something wrong about it. I though about doing the same on my own code, but I don't think it is appropriate.

I guess, I ll just return to Rosetta, where competition is fair.
Let me know when we are doing with "over-reporting" on SETI.

this unit is the perfect example of the tricks in action, this units should report a credit of 30, as the entier lot of units.
Here is the right behavior for the same lot of units: unit over estimated
since the server requires only 2 PC to agree on the units, it is 33% more often that 2 PC agrees on over estimating a workload. Since the fast renderer use the over estimated version, they get 35/30 ==> 16% RAC increase.
I found this few weeks ago, I just did not dare to say, affraid to get "hooooo" from the top guys.

16% is quiet a "trick" ... in some case, it goes up to 49% ... on this one , the temptative failled, but it succeed here: 49% performance for free!!!! (This units is reported by Both V2.2B, and the credit should be 30, not 45!)

The fact that 2 computers only are required to validate a unit increase dramatically the chance the get over-estimated credit. the admin needs to do something, 49% credit increase on a workload is not acceptable.

I know it is not Alex intentionally cheating, he does not have the control on this, it is just the statistic helping people who use OVER-REPORTING.

Mister Admin, any plan to fix this? (You got hard fact here)

who?

Who?....please check out my 'possible credit multiplier solution' thread for a thought I had on a way to fix this, and a response with another good possiblity.

I Don't see any easy solution, in racing, as long as the federation does not force a policie, the trick is legal. I am affraid that the only solution for the moment will be to turn back on the 3 PC for the quorum, it makes the statistic work again the over reporting, and cancel it out. You may want to distribute workload differently, like pairing fast computers with Stock Seti code publish by SETI, this one will definitively cancel the over reporting.

who?

If there are enough users that continue to abuse the 'anonymous platform' and refuse to update their apps, I fear that at some point, the admins could say 'enough is enough' and do away with the problem by dissallowing the use of anything other than the stock app.

They should somehow make optimized apps the stock app so that no one would have to manually download and install them. I think this is possible some day.

Yes, it is possible. It's just that at the current time, the project admins do have the resources in terms of time to devote to such a change. It would be a major undertaking, considering all of the code changes required to support the multitude of individual platforms out there running Seti. But maybe some day, if the project it's primary work done, it could happen.
Until then, we will all just have to try to work things out.

So let's all try to work within the system and rules that are in place right now and make it work.

I think I made my point with the X-Project, in the mean time, I agree with you, even with incredible hardware, and optimized software to death, I barely catch up with them, and trust me, I putted a lot of effort into it. I beat them, as my units reported it, but by a little at stock frequency. I don't want to say the frequency of X-Project, but I should get a RAC much higher than them, it is for sure.

There is definitely something wrong about it. I though about doing the same on my own code, but I don't think it is appropriate.

I guess, I ll just return to Rosetta, where competition is fair.
Let me know when we are doing with "over-reporting" on SETI.

this unit is the perfect example of the tricks in action, this units should report a credit of 30, as the entier lot of units.
Here is the right behavior for the same lot of units: unit over estimated
since the server requires only 2 PC to agree on the units, it is 33% more often that 2 PC agrees on over estimating a workload. Since the fast renderer use the over estimated version, they get 35/30 ==> 16% RAC increase.
I found this few weeks ago, I just did not dare to say, affraid to get "hooooo" from the top guys.

16% is quiet a "trick" ... in some case, it goes up to 49% ... on this one , the temptative failled, but it succeed here: 49% performance for free!!!! (This units is reported by Both V2.2B, and the credit should be 30, not 45!)

The fact that 2 computers only are required to validate a unit increase dramatically the chance the get over-estimated credit. the admin needs to do something, 49% credit increase on a workload is not acceptable.

I know it is not Alex intentionally cheating, he does not have the control on this, it is just the statistic helping people who use OVER-REPORTING.

Mister Admin, any plan to fix this? (You got hard fact here)

who?

Who?....please check out my 'possible credit multiplier solution' thread for a thought I had on a way to fix this, and a response with another good possiblity.

I Don't see any easy solution, in racing, as long as the federation does not force a policie, the trick is legal. I am affraid that the only solution for the moment will be to turn back on the 3 PC for the quorum, it makes the statistic work again the over reporting, and cancel it out. You may want to distribute workload differently, like pairing fast computers with Stock Seti code publish by SETI, this one will definitively cancel the over reporting.

who?

Yet another angle to solving the problem, but I think more difficult and server intensive to impliment than the proposals floated in my 'possible credit multiplier solution' thread. I actually think I favor WinterKnight's thought about just embedding the correct mutli into the WU header via the splitter. No muss, no fuss.

---

"Time is simply the mechanism that keeps everything from happening all at once."

If there are enough users that continue to abuse the 'anonymous platform' and refuse to update their apps, I fear that at some point, the admins could say 'enough is enough' and do away with the problem by dissallowing the use of anything other than the stock app.

They should somehow make optimized apps the stock app so that no one would have to manually download and install them. I think this is possible some day.

Yes, it is possible. It's just that at the current time, the project admins do have the resources in terms of time to devote to such a change. It would be a major undertaking, considering all of the code changes required to support the multitude of individual platforms out there running Seti. But maybe some day, if the project it's primary work done, it could happen.
Until then, we will all just have to try to work things out.

So let's all try to work within the system and rules that are in place right now and make it work.

I think I made my point with the X-Project, in the mean time, I agree with you, even with incredible hardware, and optimized software to death, I barely catch up with them, and trust me, I putted a lot of effort into it. I beat them, as my units reported it, but by a little at stock frequency. I don't want to say the frequency of X-Project, but I should get a RAC much higher than them, it is for sure.

There is definitely something wrong about it. I though about doing the same on my own code, but I don't think it is appropriate.

I guess, I ll just return to Rosetta, where competition is fair.
Let me know when we are doing with "over-reporting" on SETI.

this unit is the perfect example of the tricks in action, this units should report a credit of 30, as the entier lot of units.
Here is the right behavior for the same lot of units: unit over estimated
since the server requires only 2 PC to agree on the units, it is 33% more often that 2 PC agrees on over estimating a workload. Since the fast renderer use the over estimated version, they get 35/30 ==> 16% RAC increase.
I found this few weeks ago, I just did not dare to say, affraid to get "hooooo" from the top guys.

16% is quiet a "trick" ... in some case, it goes up to 49% ... on this one , the temptative failled, but it succeed here: 49% performance for free!!!! (This units is reported by Both V2.2B, and the credit should be 30, not 45!)

The fact that 2 computers only are required to validate a unit increase dramatically the chance the get over-estimated credit. the admin needs to do something, 49% credit increase on a workload is not acceptable.

I know it is not Alex intentionally cheating, he does not have the control on this, it is just the statistic helping people who use OVER-REPORTING.

Mister Admin, any plan to fix this? (You got hard fact here)

who?

Who?....please check out my 'possible credit multiplier solution' thread for a thought I had on a way to fix this, and a response with another good possiblity.

I Don't see any easy solution, in racing, as long as the federation does not force a policie, the trick is legal. I am affraid that the only solution for the moment will be to turn back on the 3 PC for the quorum, it makes the statistic work again the over reporting, and cancel it out. You may want to distribute workload differently, like pairing fast computers with Stock Seti code publish by SETI, this one will definitively cancel the over reporting.

who?

Yet another angle to solving the problem, but I think more difficult and server intensive to impliment than the proposals floated in my 'possible credit multiplier solution' thread. I actually think I favor WinterKnight's thought about just embedding the correct mutli into the WU header via the splitter. No muss, no fuss.

The only problem ... you can always multiply the splitter by the same constant, and be compatible with the install based over-reporting community. this is the best optimization you can do right now, not need to be ASM skilled to do so :)
It took a long time before we figure out this one. darn!

who?

If there are enough users that continue to abuse the 'anonymous platform' and refuse to update their apps, I fear that at some point, the admins could say 'enough is enough' and do away with the problem by dissallowing the use of anything other than the stock app.

They should somehow make optimized apps the stock app so that no one would have to manually download and install them. I think this is possible some day.

Yes, it is possible. It's just that at the current time, the project admins do have the resources in terms of time to devote to such a change. It would be a major undertaking, considering all of the code changes required to support the multitude of individual platforms out there running Seti. But maybe some day, if the project it's primary work done, it could happen.
Until then, we will all just have to try to work things out.

So let's all try to work within the system and rules that are in place right now and make it work.

I think I made my point with the X-Project, in the mean time, I agree with you, even with incredible hardware, and optimized software to death, I barely catch up with them, and trust me, I putted a lot of effort into it. I beat them, as my units reported it, but by a little at stock frequency. I don't want to say the frequency of X-Project, but I should get a RAC much higher than them, it is for sure.

There is definitely something wrong about it. I though about doing the same on my own code, but I don't think it is appropriate.

I guess, I ll just return to Rosetta, where competition is fair.
Let me know when we are doing with "over-reporting" on SETI.

this unit is the perfect example of the tricks in action, this units should report a credit of 30, as the entier lot of units.
Here is the right behavior for the same lot of units: unit over estimated
since the server requires only 2 PC to agree on the units, it is 33% more often that 2 PC agrees on over estimating a workload. Since the fast renderer use the over estimated version, they get 35/30 ==> 16% RAC increase.
I found this few weeks ago, I just did not dare to say, affraid to get "hooooo" from the top guys.

16% is quiet a "trick" ... in some case, it goes up to 49% ... on this one , the temptative failled, but it succeed here: 49% performance for free!!!! (This units is reported by Both V2.2B, and the credit should be 30, not 45!)

The fact that 2 computers only are required to validate a unit increase dramatically the chance the get over-estimated credit. the admin needs to do something, 49% credit increase on a workload is not acceptable.

I know it is not Alex intentionally cheating, he does not have the control on this, it is just the statistic helping people who use OVER-REPORTING.

Mister Admin, any plan to fix this? (You got hard fact here)

who?

Who?....please check out my 'possible credit multiplier solution' thread for a thought I had on a way to fix this, and a response with another good possiblity.

I Don't see any easy solution, in racing, as long as the federation does not force a policie, the trick is legal. I am affraid that the only solution for the moment will be to turn back on the 3 PC for the quorum, it makes the statistic work again the over reporting, and cancel it out. You may want to distribute workload differently, like pairing fast computers with Stock Seti code publish by SETI, this one will definitively cancel the over reporting.

who?

Yet another angle to solving the problem, but I think more difficult and server intensive to impliment than the proposals floated in my 'possible credit multiplier solution' thread. I actually think I favor WinterKnight's thought about just embedding the correct mutli into the WU header via the splitter. No muss, no fuss.

The only problem ... you can always multiply the splitter by the same constant, and be compatible with the install based over-reporting community. this is the best optimization you can do right now, not need to be ASM skilled to do so :)
It took a long time before we figure out this one. darn!

who?

'S all OK. If we can get the credit multi included with the WU, optimizing can continue at full speed, and the correct credit multi would always be applied. No one would overclaim if the WU itself controlled the multi.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Now back on topic.......
It has been explained that the app for Macs has not been corrected yet....per Richard Haselgrove's post in another thread......

"The Mac situation is more problematical. The stock Mac app is still at v5.23, which IIRC has the overclaiming beta multiplier - it's still a mystery why it was ever released here. It's higher even than 2.2B, and needs correcting urgently. Alex Kan used to do the optimisations from somewhere on Berkeley campus, and had time to volunteer (student?), but now has a 'proper job' and has moved away, and has less time. I haven't even looked for any website where he might have posted his current committment to the project/future plans."

So we're kinda stuck on that one at the moment. Which buttresses my theory about taking the credit multi out of the hands of the science app.

Could the Chicken users please get on board and update to 2.4??

---

"Time is simply the mechanism that keeps everything from happening all at once."

Now back on topic.......
It has been explained that the app for Macs has not been corrected yet....per Richard Haselgrove's post in another thread......

"The Mac situation is more problematical. The stock Mac app is still at v5.23, which IIRC has the overclaiming beta multiplier - it's still a mystery why it was ever released here. It's higher even than 2.2B, and needs correcting urgently. Alex Kan used to do the optimisations from somewhere on Berkeley campus, and had time to volunteer (student?), but now has a 'proper job' and has moved away, and has less time. I haven't even looked for any website where he might have posted his current committment to the project/future plans."

See here:

http://forums.macnn.com/72/team-macnn/344590/optimized-seti-multibeam-worker/

---

Dublin, California
Team: SETI.USA

...
in some case, it goes up to 49% ... on this one, Alex computer tried to get 45 credit, while the right amout is 30 , this temptative failled, but it succeed here: 49% performance for free!!!! (This units is reported by Both V2.2B, and the credit should be 30, not 45!)
...
who?

You missed the fact that the 30 claim was from a host running BOINC 4.45, hence lower than correct. For the 2.85 multiplier, the claim should be 38.57, see wuid 148185895 for fpops_cumulative based claims at that angle range from the stock Windows and Mac applications.

                                                                Joe

...
in some case, it goes up to 49% ... on this one, Alex computer tried to get 45 credit, while the right amout is 30 , this temptative failled, but it succeed here: 49% performance for free!!!! (This units is reported by Both V2.2B, and the credit should be 30, not 45!)
...
who?

You missed the fact that the 30 claim was from a host running BOINC 4.45, hence lower than correct. For the 2.85 multiplier, the claim should be 38.57, see wuid 148185895 for fpops_cumulative based claims at that angle range from the stock Windows and Mac applications.

                                                                Joe

Still largely over reporting!

who?

...
in some case, it goes up to 49% ... on this one, Alex computer tried to get 45 credit, while the right amout is 30 , this temptative failled, but it succeed here: 49% performance for free!!!! (This units is reported by Both V2.2B, and the credit should be 30, not 45!)
...
who?

You missed the fact that the 30 claim was from a host running BOINC 4.45, hence lower than correct. For the 2.85 multiplier, the claim should be 38.57, see wuid 148185895 for fpops_cumulative based claims at that angle range from the stock Windows and Mac applications.

                                                                Joe

Still largely over reporting!

who?

For now, the Macs are going to continue to overclaim, because Alex's optimized app has not yet been updated to correct the credit multiplier. Hopefully he can find the time to do it soon.
Some ideas have been floated in my 'possible credit multiplier solution' thread to get the multi control out of the science app, and this would eliminate a problem like this happening in the future.
As for the Chicken users still on 2.2b, please update.

---

"Time is simply the mechanism that keeps everything from happening all at once."

While I was using Chickens 2.2B, while it overclaimed, that high claim almost never counted as the claim of the other result of that unit was lower in accordance with 2.4 or the stock cruncher. So my award was lower, anyway. I see that the 2.4 computes more efficiently, too, at least on some units. It's really hard to compare 2.2B and 2.4, though, since computations to complete a result generally have increased.

---

While I was using Chickens 2.2B, while it overclaimed, that high claim almost never counted as the claim of the other result of that unit was lower in accordance with 2.4 or the stock cruncher. So my award was lower, anyway. I see that the 2.4 computes more efficiently, too, at least on some units. It's really hard to compare 2.2B and 2.4, though, since computations to complete a result generally have increased.

reposting here:
correct, but compare to a correct reporting SETI, there is still a big gap.
it is over reporting by more than 20%!!!
and If i report a unit at 30, it will drag me down too, so, compare to me, the delta is still very big: 20 of OVER REPORTING, and 29% of under reporting.
in the big picture, the MAC get 49% better credits than I can do in some case.



who?

For now, the Macs are going to continue to overclaim, because Alex's optimized app has not yet been updated to correct the credit multiplier. Hopefully he can find the time to do it soon.
Some ideas have been floated in my 'possible credit multiplier solution' thread to get the multi control out of the science app, and this would eliminate a problem like this happening in the future.
As for the Chicken users still on 2.2b, please update.

Perhaps, for the time being, if someone could find the location of the multiplier in Alex's app(s) and create a patch to set it to the proper value, we might put this overclaim to rest.

I would again ask that all optimized app users update to the current science apps. I do not know if Alex's Mac apps have been updated with the correct credit multi or not. If not, I understand, but I would hope tha Alex would correct the situation very soon.

And I would ask even more strongly that the high profile users in the top 100 list (especially the top 20) do what it right and get your rigs in compliance with the project. Do what is right please. I know this is a hard thing to do when you are proud of your current position. You are leading the way in Seti crunching production, please help me set an example and do it within the current set of rules.

Maslatter,

You may forget that most people do not visit theses message boards. How will they ever know unless they start returning invalid results, and than how long will it take them to notice? Hundreds or maybe a few thousand visit these boards daily…not the entire SETI fleet.

Boinc was setup to be hands off software, if that is how you set it up. So if someone is set up for hands off, how would they know?

There has been NO official announcement that I can see on the Seti Home Page indicating any change to Seti@home and that people should do something different. I see no new message that MB’s have been released. Going back 1 month on the Homepage NEWs there is NO mention.

I’ve noticed that most people on these message boards will update to the next version the minute it becomes available. If 5.28 comes out on Monday, you update it. If 5.29 comes out on Thursday, you update it. If 5.30 comes out the next week, you update.

I for 1 update every few months. I’m on these boards and see what is going on. But I’m not going to update every few days, weeks or months unless I have NO choice, which has never happened.

I’m still using 5.8.16 & 5.4.11, I’m still using 2.2b (not to gain credit). I think I noticed 1 or 2 WU’s that got the old (higher) credit than the new apps would have. The reason I don’t update is BECAUSE I read these boards. I see problems people complain of with new apps and don’t want to run into these problems until they are ironed out. There was a problem with Chickens new optimizer when it 1st came out. I’ll sit back for a few weeks or maybe months until I see things are running smooth. There may be many people that feel and do the same as me. Heck, I just got matched up not to long ago on a WU where someone was using a 4.2 application? (something very old).

If amazes me that your complaint is with the USERs. Well than again it really doesn’t.

1 guess whom you should be complaining to/at/about this problem if you feel strongly enough???

~Meow~