Hello to all crunchers,

I was convinced that SetiHome using flop counter to award credits was the best option...
But reality is not so simple, sometimes.

Whenever you cross your way with computers running outdated BOINC versions, and following the present rule of awarding the lowest claim, flop count loose all its sense.


One example:
http://setiweb.ssl.berkeley.edu/show_host_detail.php?hostid=3845498




A proposal:
Is there no posibility (when awarding credit) to check if the claim is done with an outdated BOINC?
(That in any case will be claiming wrong credit...)

Regards
Nikor

---

Although generally it lowers anyone credit who is paired with such a client. Until the older clients can be completely removed, the lower credit needs to be chosen to avoid invalid high claims.

The following thread is an extreme example of why it is done; but if an older client was paired and ignored both people would of got the extremely high credit claim.

Crazy Credit Claim

---

SL

Yes, I agree with your point, but... (there is always a but) :)

The reason for my question is:

It's assumed that flops count is the valid criteria to assign credit, why is the responsibility given to the application to calculate the credit?

Many times this means miss-calculated credit claims and is the reason that creates the need to control the credit claims. This is a vicious circle, or as I would say "la pescadilla que se muerde la cola" ;)

Wouldn't be easier to use flop count to validate results?

And a doubt, if flop count differs too much, is there any control currently?
(this would be a sign of problems in at least one of the results...)

What's your view?

Regards

---

It would be dangerous to use anything but the lower of two credit claims because the sky's the limit on the upside, whereas zero is the minimum. One could claim a million credits and even the average would be 500,000. If a claim were credited zero that would be just a tiny gyp compared to the grant of 500,000. No sé nada del pez mordido en la cola. Un tiburón comería el pez entero.

---

This can't be all that hard a problem to solve. Overclaiming would only be an issue in the event a result is paired with an 'invalid' credit claim. I would propose that since the WUs all fall into maybe 8-10 distinct legal credit values, anything not having that credit value, would be considered invalid.

That prevents the stupid overclaim from hell, and would also cut out most of the BS that old clients cause. I mean the odds of a malicious client being paired with an old client that claims invalidly are small. You could also establish trust ratings for each PC and ensure that a 'trusted' PC is always part of the quorom.

I mean I can literrally think of a million ways to solve this issue...

It's an intriguing prob.

Just off the top of my head - because there are always going to be 'fire & forget' crunchers - perhaps some way to pair like with like? 4's with 4's?

Just a thought.

It's an intriguing prob.

Just off the top of my head - because there are always going to be 'fire & forget' crunchers - perhaps some way to pair like with like? 4's with 4's?

Just a thought.

This has been hashed around in these forums countless times and to date, no reasonable system has been come up with. Your idea, while a good one, would require extra database searches on an already overworked database to make sure the work unit were issued to a similar application. Now if SETI could afford systems with enough throughput to handle the increased load then there are several ideas that have merit to eliminate this problem. But until they do (which with the current state of funding for this type of work is VERY improbable) we will just have to live with the possibility of getting short-changed sometimes. Just remember, *everyone* has the same probability of getting paired with one of these. They don't discriminate against just one user or one class of user. Just be glad you get at least *some* credit. There are a few computers out there which are returning valid results but claiming "0" credit!

---

Jim

Some people plan their life out and look back at the wealth they've had.
Others live life day by day and look back at the wealth of experiences and enjoyment they've had.

What's wrong with using the obvious answer??

Have the Berkeley servers enforce a minimum version Boinc of 5.XX. Anyone using an earlier version must upgrade their version of Boinc to be able to download more work.

Isn't this the easiest solution, and the best??

Have the Berkeley servers enforce a minimum version Boinc of 5.XX. Anyone using an earlier version must upgrade their version of Boinc to be able to download more work.

What about the people that are still reporting proxy issues with the 5.x series client?

---

Have the Berkeley servers enforce a minimum version Boinc of 5.XX. Anyone using an earlier version must upgrade their version of Boinc to be able to download more work.

What about the people that are still reporting proxy issues with the 5.x series client?

Proxy problems were occuring a year ago. Are you saying that those problems have never been rectified? Shame.....Shame..... that a serious problem such as this has never been fixed.

Have the Berkeley servers enforce a minimum version Boinc of 5.XX. Anyone using an earlier version must upgrade their version of Boinc to be able to download more work.

What about the people that are still reporting proxy issues with the 5.x series client?

Proxy problems were occuring a year ago. Are you saying that those problems have never been rectified? Shame.....Shame..... that a serious problem such as this has never been fixed.

I guess it's true. The developers cannot locate the problem and/or recreate the specific issue that some people are having so they cannot "fix" the code.

It happens in all software, not just BOINC.

---

Have the Berkeley servers enforce a minimum version Boinc of 5.XX. Anyone using an earlier version must upgrade their version of Boinc to be able to download more work.

What about the people that are still reporting proxy issues with the 5.x series client?

Proxy problems were occuring a year ago. Are you saying that those problems have never been rectified? Shame.....Shame..... that a serious problem such as this has never been fixed.

I guess it's true. The developers cannot locate the problem and/or recreate the specific issue that some people are having so they cannot "fix" the code.

It happens in all software, not just BOINC.

So then it's ok to let more problems pile on that are indirectly related to the first unfixable problem? Does not sound like a good plan to me!

So then it's ok to let more problems pile on that are indirectly related to the first unfixable problem? Does not sound like a good plan to me!

Do you suggest they stop all progress until one bug is fixed? Or that they exclude those users that are happy using BOINC 4.x? How happy would you be if you were one of those users?

---

It seems to me that the proxy bug is causing more problems each and every day. It's ramificatioins are becoming more and more pronounced with each work unit that is paired with a 4.45 client. The recomended version of Boinc as of now is 5.10.20. That is a far cry from 4.XX and it's time to force an upgrade or make a concentrated effort to find and fix the proxy error.

Just my opinion and I'm sure many agree.

It seems to me that the proxy bug is causing more problems each and every day. It's ramificatioins are becoming more and more pronounced with each work unit that is paired with a 4.45 client. The recomended version of Boinc as of now is 5.10.20. That is a far cry from 4.XX and it's time to force an upgrade or make a concentrated effort to find and fix the proxy error.

Just my opinion and I'm sure many agree.

I'm sure many vocal users do. How many users that don't post here are you attempting to speaking for? It seems to me that SETI@Home is all about getting as many crunchers as possible without excluding anybody (hence a base system of a Pentium 60MHz is capable of running the project in as little as 32MB of RAM). I cannot speak for the project Admins, but my guess is that they feel it would be wrong to block some users from participating and providing valid science at the cost of some cobblestones.

Of course, those who are screwed out of credits will rightly complain loudly. From their perspective it's not very fair for all the work they're doing. But what about from a scientist's point of view? Which is more valuable to you, the science or the credits? Of course, an argument can be made that it could cost them even more if people quit over it (then again, we've been down that road before).

Who knows? For all I know they're (the Admins) already considering changing the min version allowed but are waiting for a few other things to fall in place first. All I'm pointing out is that each decision can have far reaching consequences that may affect the project and the project Admins need to focus on what's best for their needs - hopefully without the bickering of a vocal minority and any threats of quiting.

My personal opinion? It doesn't really matter to me. v5.10.20 works fine. But I wouldn't be one of the users affected by this. If I were, I'd be pretty upset.

---

It seems to me that the proxy bug is causing more problems each and every day. It's ramificatioins are becoming more and more pronounced with each work unit that is paired with a 4.45 client. The recomended version of Boinc as of now is 5.10.20. That is a far cry from 4.XX and it's time to force an upgrade or make a concentrated effort to find and fix the proxy error.

Just my opinion and I'm sure many agree.

I'm sure many vocal users do. How many users that don't post here are you attempting to speaking for? It seems to me that SETI@Home is all about getting as many crunchers as possible without excluding anybody (hence a base system of a Pentium 60MHz is capable of running the project in as little as 32MB of RAM). I cannot speak for the project Admins, but my guess is that they feel it would be wrong to block some users from participating and providing valid science at the cost of some cobblestones.

Of course, those who are screwed out of credits will rightly complain loudly. From their perspective it's not very fair for all the work they're doing. But what about from a scientist's point of view? Which is more valuable to you, the science or the credits? Of course, an argument can be made that it could cost them even more if people quit over it (then again, we've been down that road before).

Who knows? For all I know they're (the Admins) already considering changing the min version allowed but are waiting for a few other things to fall in place first. All I'm pointing out is that each decision can have far reaching consequences that may affect the project and the project Admins need to focus on what's best for their needs - hopefully without the bickering of a vocal minority and any threats of quiting.

My personal opinion? It doesn't really matter to me. v5.10.20 works fine. But I wouldn't be one of the users affected by this. If I were, I'd be pretty upset.

Ozzfan: I'd be more inclined to side with your 'side' of this 'arguement' if the science were actually being done. Right now all that's happening is WU results are logged into a big old database. AFAIK there is no code which exists to even mine the data we've been crunching, so in effect, at this point in time, the science arguement is pretty irrelevant and it's all about the stats.

Now I know this isn't the end goal of the project, but as of today, SETI is solely about crunching for all practical purposes. As such the credit issue needs resolution one way or the other.

AFAIK there is no code which exists to even mine the data we've been crunching, so in effect, at this point in time, the science arguement is pretty irrelevant and it's all about the stats.

But the opposite is just as true. As far as you know, code exists to mine the data we've been crunching. To say that the science argument is irrelevant is to dismiss the reason for the crunching, whether there's a method in place currently to use the data or not. It's only about the stats for the users, not the project Admins.

---

AFAIK there is no code which exists to even mine the data we've been crunching, so in effect, at this point in time, the science arguement is pretty irrelevant and it's all about the stats.

But the opposite is just as true. As far as you know, code exists to mine the data we've been crunching. To say that the science argument is irrelevant is to dismiss the reason for the crunching, whether there's a method in place currently to use the data or not. It's only about the stats for the users, not the project Admins.

No users, no project :) As I said the long-term goal is not about stats, but really the stats problems should be addressed... SETI and many other BOINC projects are purely about the stats for a LOT of users.

For me it's about the science and if someone owns a computer that will locate ET I want it to be my computer. The stats are secondary to me and I very rarely look at them.

But.....If admin would ever get the client stats page working again we would know how many are still using 4.XX Boinc clients and then could talk about it more intelligently.

[edit]and I still say it would be beneficial to fix the bugs![/edit]

Here's a subversive suggestion: Announce that support for BOINC 4.XX will be withdrawn on, say, 30 November 2007 - and also that, prior to the final switch-off, there would be a trial period of say 7 days when no new work would be issued to 4.XX clients to assess the response and impact on the project. (No prior warning to be given of the trial period, of course - it would invalidate the trial if anyone started fiddling with their cache sizes).

Maybe that would concentrate some minds - actually track down what the bug is, get people to report their error messages and details of their proxy servers, that sort of thing.

Or maybe not - only dreaming!