Please take a look at workunit 219094004. Computer 2949370 (not mine) is claiming a negative credit for result 744063457, resulting a granted credit of 0.00 for this workunit.

Wouldn't it be better if results with a negative claimed credit were treated as invalid?


Michael

Please take a look at workunit 219094004. Computer 2949370 (not mine) is claiming a negative credit for result 744063457, resulting a granted credit of 0.00 for this workunit.

Wouldn't it be better if results with a negative claimed credit were treated as invalid?


Michael

It would be even better if credits claimed by out of date clients were treated as invalid.......
But it ain't gonna happen any time soon, so we all gotta take our lumps and carry on.....

I am not saying you are wrong, but I had suggested a long time ago that the validator take into account the version of the client and science app when deciding what credits to award......

It's a thorny thing, and probably not as simple to implement as some might imagine, but I suggested that in the case of an over-claiming client or app, the correct credit claimed by the current client/app would be awarded to both....
In the case of an under-claiming client/app, the older client/app would be awarded their lower claim, so as not to reward them with being paired with a current user..and the current client would be awarded his correct claim, so as not to punish the user with the current client/app because his wingman was using an under claiming client/app.

In other words, you get what you ask for, unless it is higher than what is currently correct, and if you claim a lower amount than what is currently correct, that is what you get, and the wingman is not punished.

I don't know if it is possible in the current system to award two different credit amounts for a reported result, but the scenario I have outlined should serve to quell all of the arguments about credit awarding, if it were possible to put into play......

I hope that makes sense to everybody....eh??

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

In other words, you get what you ask for, unless it is higher than what is currently correct, and if you claim a lower amount than what is currently correct, that is what you get, and the wingman is not punished.

Hmmm... So in this case, the offender would be granted -38 credits. That could create a whole new race, see who can get the most negative RAC. Could make things more interesting. LOL

---

In other words, you get what you ask for, unless it is higher than what is currently correct, and if you claim a lower amount than what is currently correct, that is what you get, and the wingman is not punished.

Hmmm... So in this case, the offender would be granted -38 credits. That could create a whole new race, see who can get the most negative RAC. Could make things more interesting. LOL

Let 'em go at it..........LOL......
At least it would give the current, updated crunchers their due........

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

In other words, you get what you ask for, unless it is higher than what is currently correct, and if you claim a lower amount than what is currently correct, that is what you get, and the wingman is not punished.

Hmmm... So in this case, the offender would be granted -38 credits. That could create a whole new race, see who can get the most negative RAC. Could make things more interesting. LOL

Let 'em go at it..........LOL......
At least it would give the current, updated crunchers their due........

CPU time -19464.251514

Hmm, even your phased quaddy isn't that fast, Mark. Maybe some tachyons got into that system, but more likely the user adjusted the clock.

                                                              Joe

but more likely the user adjusted the clock.

Darn, I did that recently (Huge time error because I had failed to set the time with a new motherboard). I wonder if it affected any results lol - Sorry if someone was affected. Oh and no that one posted was not my result, so dont blame me for that :)

CPU time -19464.251514

Hmm, even your phased quaddy isn't that fast, Mark. Maybe some tachyons got into that system, but more likely the user adjusted the clock.

                                                              Joe

I don't get it... How can adjusting the clock cause the CPU time to go negative?
Maybe it's just ET showing off.

---

[quote]I don't get it... How can adjusting the clock cause the CPU time to go negative?
Maybe it's just ET showing off.

Adjusted the time back - it was running like 6hrs fast so they put it back. The time difference between start & end time was negative 5.4hrs, thus the result. Thats a guess tho.

[quote]I don't get it... How can adjusting the clock cause the CPU time to go negative?
Maybe it's just ET showing off.

Adjusted the time back - it was running like 6hrs fast so they put it back. The time difference between start & end time was negative 5.4hrs, thus the result. Thats a guess tho.

So when daylight saving time kicks in we all get a 1 hour penalty or boost? I don't think I have ever noticed that before.

---

[quote]I don't get it... How can adjusting the clock cause the CPU time to go negative?
Maybe it's just ET showing off.

Adjusted the time back - it was running like 6hrs fast so they put it back. The time difference between start & end time was negative 5.4hrs, thus the result. Thats a guess tho.

So when daylight saving time kicks in we all get a 1 hour penalty or boost? I don't think I have ever noticed that before.

The host is running BOINC 4.19.

                                                                 Joe

but more likely the user adjusted the clock.

Darn, I did that recently (Huge time error because I had failed to set the time with a new motherboard). I wonder if it affected any results lol - Sorry if someone was affected. Oh and no that one posted was not my result, so dont blame me for that :)

Wouldn't dream of blaming you. We always Blame Misfit!

Please take a look at workunit 219094004. Computer 2949370 (not mine) is claiming a negative credit for result 744063457, resulting a granted credit of 0.00 for this workunit.

Wouldn't it be better if results with a negative claimed credit were treated as invalid?


Michael

It would be even better if credits claimed by out of date clients were treated as invalid.......
But it ain't gonna happen any time soon, so we all gotta take our lumps and carry on.....

I am not saying you are wrong, but I had suggested a long time ago that the validator take into account the version of the client and science app when deciding what credits to award......

It's a thorny thing, and probably not as simple to implement as some might imagine, but I suggested that in the case of an over-claiming client or app, the correct credit claimed by the current client/app would be awarded to both....
In the case of an under-claiming client/app, the older client/app would be awarded their lower claim, so as not to reward them with being paired with a current user..and the current client would be awarded his correct claim, so as not to punish the user with the current client/app because his wingman was using an under claiming client/app.

In other words, you get what you ask for, unless it is higher than what is currently correct, and if you claim a lower amount than what is currently correct, that is what you get, and the wingman is not punished.

I don't know if it is possible in the current system to award two different credit amounts for a reported result, but the scenario I have outlined should serve to quell all of the arguments about credit awarding, if it were possible to put into play......

I hope that makes sense to everybody....eh??

So.....has anybody given any thought (Matt....Eric) about the theory I have posed here? Could this be done?

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

So.....has anybody given any thought (Matt....Eric) about the theory I have posed here? Could this be done?

I know this is "old ground" being covered, but.........

My opinion is that the proper way to deal with the issue is to enforce the minimum version to be what it needs to be so that the issue goes away without having to spend development time to address a support issue.

That approach seems to be a "non-starter", as there is this fear that doing so will "cut off" some users, although there has been no scientifically valid study conducted to assertain whether or not the individuals / entities using the older BOINC versions have a current and valid issue with the newer version(s) that is not something that could be overcome by reconfiguring their side. Right now, the "some users might get cut off" talk is all hyperbole and FUD...

I'd like to take a moment to remind people that closing SETI Classic was far more drastic than simply requiring a flops-counting BOINC version...

So.....has anybody given any thought (Matt....Eric) about the theory I have posed here? Could this be done?

I know this is "old ground" being covered, but.........

My opinion is that the proper way to deal with the issue is to enforce the minimum version to be what it needs to be so that the issue goes away without having to spend development time to address a support issue.

That approach seems to be a "non-starter", as there is this fear that doing so will "cut off" some users, although there has been no scientifically valid study conducted to assertain whether or not the individuals / entities using the older BOINC versions have a current and valid issue with the newer version(s) that is not something that could be overcome by reconfiguring their side. Right now, the "some users might get cut off" talk is all hyperbole and FUD...

I'd like to take a moment to remind people that closing SETI Classic was far more drastic than simply requiring a flops-counting BOINC version...

But Brian, my friend.....if my solution were implimented, it would solve all of the credit claiming issues, would it not? Without cutting any of the old 'set and forget' clients off at the knees, and without the continuing nibbling at the credits of those who are using current clients and apps....

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

But Brian, my friend.....if my solution were implimented, it would solve all of the credit claiming issues, would it not? Without cutting any of the old 'set and forget' clients off at the knees, and without the continuing nibbling at the credits of those who are using current clients and apps....

The project can attempt to address the "set and forget" types by sending an email to their address on file as well as a PM to their userID here. If the project shows a "good faith effort", then there is nothing wrong with moving forward. This was done with SETI Classic. Users were given ample warning, then the cutoff happened.

Adding code could indeed perhaps keep the "set and forget" types around, but it would add complexity to the validator / whatever piece grants credit. Since code will be added, proper procedures would require testing of unknown duration.

The minimum version mechanism is already there and would take care of this situation without any of that added complexity and testing. It would have the added bonus of pushing the issue of NTLM proxies to the forefront. If it really is indeed a major issue, then perhaps having it up towards the top would get BOINC development efforts focused on this rather than social networking...

Finally, every time I've contacted someone who was running older BOINC clients, they have told me that they just didn't know there was something newer and/or knew and just hadn't updated because they didn't know about the credit issues. If "cutting off" users is so distasteful to the project, then perhaps they could at least send the emails and PMs that I mentioned earlier and see if they can coax some people to update.

But Brian, my friend.....if my solution were implimented, it would solve all of the credit claiming issues, would it not? Without cutting any of the old 'set and forget' clients off at the knees, and without the continuing nibbling at the credits of those who are using current clients and apps....

The project can attempt to address the "set and forget" types by sending an email to their address on file as well as a PM to their userID here. If the project shows a "good faith effort", then there is nothing wrong with moving forward. This was done with SETI Classic. Users were given ample warning, then the cutoff happened.

Adding code could indeed perhaps keep the "set and forget" types around, but it would add complexity to the validator / whatever piece grants credit. Since code will be added, proper procedures would require testing of unknown duration.

The minimum version mechanism is already there and would take care of this situation without any of that added complexity and testing. It would have the added bonus of pushing the issue of NTLM proxies to the forefront. If it really is indeed a major issue, then perhaps having it up towards the top would get BOINC development efforts focused on this rather than social networking...

Finally, every time I've contacted someone who was running older BOINC clients, they have told me that they just didn't know there was something newer and/or knew and just hadn't updated because they didn't know about the credit issues. If "cutting off" users is so distasteful to the project, then perhaps they could at least send the emails and PMs that I mentioned earlier and see if they can coax some people to update.

If they are so distant from the project (and I am not saying that is a bad thing....) that they are not aware that there is an updated client or app...what makes you think they will see or respond to a PM?

My solution should not take too much code to implement, or cost much in terms of validator cpu time........a simple if/then/else/less than/equal to/doesn't match/what the heck's up/ok then/the heck with it/logic loop....LOl........
It could work........I used to program.....

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

If they are so distant from the project (and I am not saying that is a bad thing....) that they are not aware that there is an updated client or app...what makes you think they will see or respond to a PM?

I've a feeling than in addition to those who set-it/forget-it, there are those mom & pop types that are only running SETI because junior installed it while at home on spring break, or something similar. Years pass and never an update to BOINC, though SETI updates the crunching application automatically as new versions become available.

What if SETI were to install a "do nothing" application, like a detatch from project, to those volunteers systems that haven't a minimal version of BOINC installed. Something along these lines would attack the problem at the source, WU's never get DL'd to those out of date systems so there isn't an issue with credit handling after processing.

Seems to me that since the mechanism is already in place to update the application as needed, the framework would already be in place to implement this approach.

Of course, we'll be losing production capacity in a time that the project is in need of more crunching power, not less. I wonder what the impact to the project would be.

Now I'll run and duck for cover;-)

---

If they are so distant from the project (and I am not saying that is a bad thing....) that they are not aware that there is an updated client or app...what makes you think they will see or respond to a PM?

I've a feeling than in addition to those who set-it/forget-it, there are those mom & pop types that are only running SETI because junior installed it while at home on spring break, or something similar. Years pass and never an update to BOINC, though SETI updates the crunching application automatically as new versions become available.

What if SETI were to install a "do nothing" application, like a detatch from project, to those volunteers systems that haven't a minimal version of BOINC installed. Something along these lines would attack the problem at the source, WU's never get DL'd to those out of date systems so there isn't an issue with credit handling after processing.

Seems to me that since the mechanism is already in place to update the application as needed, the framework would already be in place to implement this approach.

Of course, we'll be losing production capacity in a time that the project is in need of more crunching power, not less. I wonder what the impact to the project would be.

Now I'll run and duck for cover;-)

Don't run off now.......
My proposition would not disturb any crunching......
Just the way credits are awarded.....
Nobody would be disturbed from their slumber.......
The only ones who would take notice would be those who were running old underclaiming clients or apps.......
And few they would be.......

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Don't run off now.......
My proposition would not disturb any crunching......
Just the way credits are awarded.....
Nobody would be disturbed from their slumber.......
The only ones who would take notice would be those who were running old underclaiming clients or apps.......
And few they would be.......

I have issue with the proposition of granting differing credits... seems a bit dishonest, like taking advantage of a cashiers mistake when they give you too much change. If there are really that few of the 4.xx BOINCers taking part, just eliminate them to appease the masses.

---

Don't run off now.......
My proposition would not disturb any crunching......
Just the way credits are awarded.....
Nobody would be disturbed from their slumber.......
The only ones who would take notice would be those who were running old underclaiming clients or apps.......
And few they would be.......

I have issue with the proposition of granting differing credits... seems a bit dishonest, like taking advantage of a cashiers mistake when they give you too much change. If there are really that few of the 4.xx BOINCers taking part, just eliminate them to appease the masses.

It's no deception if one advises all current users what is why it is being done....damn........I never said that the 4.xx users should be penalized, just that they should be awarded what they have earned......read my lips..(posts).....

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster