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).....

From your earlier post...

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.

So if I'm reading your earlier post in this thread correctly,
If you ask for 0.0, then you get 0.0, even though the "currently correct" credit might be 50.14 and your result is used to validate your wingman who gets
the 50.14 because that is what he claimed.

What happens in the case that user one claims 25, wingman claims 102, and the currently correct credit is 63.98. Both original users validate without issue, but both have in correct credit claims?


Did I miss something?

---

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?

There is this thing called "precedent". The closure of SETI Classic and the migration to BOINC set the precedent. There were "set and forget" users then too. Since I'm sure someone will counter with the notion that "at least valid science is still being done, where SETI Classic was just repeating data, no new science", it still does not change the fact that some users were "cut off". Some of those may have simply picked up and kept going once they figured out what was going on...

So, we can continue to flog the horse, as it were, and talk about not wanting to cut anyone off, but it's been done before and the project survived...

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.....

How about a situation where 3 results were required, 1 from a "valid" 5.x.x version, one from a 4.45 version, and one from a 5.10.30 host that happened to compile a science application with the "same" version number as the "valid 5.x.x host" who was debating tinkering with the load_store_adjustment to "cheat" that ended up deciding to be honest, but mistakenly thought it was 2.58 instead of 2.85?

What about when variable multipliers are brought into the equation?

Setting the minimum version and enforcing it is far cleaner, even if it is abhorrent for some unknown reason, given the precedent...

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?

There is this thing called "precedent". The closure of SETI Classic and the migration to BOINC set the precedent. There were "set and forget" users then too. Since I'm sure someone will counter with the notion that "at least valid science is still being done, where SETI Classic was just repeating data, no new science", it still does not change the fact that some users were "cut off". Some of those may have simply picked up and kept going once they figured out what was going on...

So, we can continue to flog the horse, as it were, and talk about not wanting to cut anyone off, but it's been done before and the project survived...

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.....

How about a situation where 3 results were required, 1 from a "valid" 5.x.x version, one from a 4.45 version, and one from a 5.10.30 host that happened to compile a science application with the "same" version number as the "valid 5.x.x host" who was debating tinkering with the load_store_adjustment to "cheat" that ended up deciding to be honest, but mistakenly thought it was 2.58 instead of 2.85?

What about when variable multipliers are brought into the equation?

Setting the minimum version and enforcing it is far cleaner, even if it is abhorrent for some unknown reason, given the precedent...

Geez.......I thought my 'what--- who---when---whereararthough---logic would have served.........
obviously my coding skills have slipped.......

---

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

Bottom line...

As long as the science is valid, the credit granted is irrelevent!

And the door shuts.

---

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).....

From your earlier post...

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.

So if I'm reading your earlier post in this thread correctly,
If you ask for 0.0, then you get 0.0, even though the "currently correct" credit might be 50.14 and your result is used to validate your wingman who gets
the 50.14 because that is what he claimed.

What happens in the case that user one claims 25, wingman claims 102, and the currently correct credit is 63.98. Both original users validate without issue, but both have in correct credit claims?


Did I miss something?

No, you simply pointed out another possibilty........in this case, neither host is correct, and I would say that both get the lower of the two.........

In any case, the only losers would be the obsolete client/app users.......who would probably not recognize it anyway..........
And if they did, should open their eyes to updating.............

---

"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.......

Posing the same question you asked of me:

If they were so detached and removed from the project, then how would they "notice"?

Mark, it's not a bad idea. It would be swell if there were the time and there was someone available to do it and a sufficient test environment to test it with...but I don't think all those pieces are in place...

Additionally, if "few they would be", then why not just set the minimum version, enforce it, and let the chips fall where they may? Any "uproar" over this should be so trivial compared to the griping / sniping that happened when Classic was shut down. I would almost place a bet (if I had the money) that within the past 6-12 months someone somewhere on these message boards has griped that they liked Classic better and don't so much like this "BOINC thing"...or how that they left when Classic ended and got an email asking them to come back and they returned during a problem time and it reinforced their belief that BOINC == "junk"...

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.......

Posing the same question you asked of me:

If they were so detached and removed from the project, then how would they "notice"?

Mark, it's not a bad idea. It would be swell if there were the time and there was someone available to do it and a sufficient test environment to test it with...but I don't think all those pieces are in place...

Additionally, if "few they would be", then why not just set the minimum version, enforce it, and let the chips fall where they may? Any "uproar" over this should be so trivial compared to the griping / sniping that happened when Classic was shut down. I would almost place a bet (if I had the money) that within the past 6-12 months someone somewhere on these message boards has griped that they liked Classic better and don't so much like this "BOINC thing"...or how that they left when Classic ended and got an email asking them to come back and they returned during a problem time and it reinforced their belief that BOINC == "junk"...

Damn, Brian, why must you joust with me??

My chits would fall where your's might......
Yeah......I saw the posts from minimal users about minimal problems they laid down.......but you get too carried away going off to the 'dark side'.......

The kitties and I just go with the flow.............
Neither you nor I can change the way things will go...........
So....I will just try to redirect.....Mew Math......I was gonna call that a /meowur....but that would be a bad slash/dot now wouldn't it......???

---

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

The important thing is to know what you are doing..........
Rather than to get the right answer......

---

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

Damn, Brian, why must you joust with me??

Because it's fun, especially if you have lots of quarters... ;-)

...but you get too carried away going off to the 'dark side'.......

Actually, in every Star Wars game where there is a decision between Light and Dark, I always choose Light...

Neither you nor I can change the way things will go...........

That's "defeatist talk"... I told you, it's not a "bad idea", just that it's not very clean. Also, precedent is on the side of the minimum version change. It was already done once with 4.19 supposedly being a minimum version at one point in time...and then the whole shutdown of Classic, well, that likely "cut off" more people than this would...

Got another quarter? If so, just give it to me so I can play more since you will just run off the edge into the lava... ;-)

Damn, Brian, why must you joust with me??

Because it's fun, especially if you have lots of quarters... ;-)

...but you get too carried away going off to the 'dark side'.......

Actually, in every Star Wars game where there is a decision between Light and Dark, I always choose Light...

Neither you nor I can change the way things will go...........

That's "defeatist talk"... I told you, it's not a "bad idea", just that it's not very clean. Also, precedent is on the side of the minimum version change. It was already done once with 4.19 supposedly being a minimum version at one point in time...and then the whole shutdown of Classic, well, that likely "cut off" more people than this would...

Got another quarter? If so, just give it to me so I can play more since you will just run off the edge into the lava... ;-)

LOL.......
I was looking for an old juke song on youtube called Nickels, Quarters, and Dimes,...
Not the song I was looking for, but This'un 'll do jess fine......
Y'all have a nice day now.....LOL.....
All in good fun, Brian.

And do listen up, my good friend.....we have a bit o' fun on the light side......my nickel......

---

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

There's a pair of settings which can be put into the project configuration to warn users that a change in minimum allowed core client is coming. One setting says what the minimum will be, and any hosts which are running a lower version will get a message in each Scheduler reply saying:

Starting in %d days and %d hours, project will require a minimum BOINC core client version of %d.%d.0. You are currently using version %d.%d.%d; please upgrade before this time.

The %d's are of course replaced by numbers. The message is at low priority like other server messages until 3 days before the deadline, then changes to high priority so it will be shown in red.

I suspect there are many users who never look at the messages, but the feature obviously should be used, I'd think starting a month or so before. If they could send out email to affected users about the same time, that would cover about all that's possible in the way of advanced warning. Well, a news item should be placed on the project front page too.

Note the "core client version of %d.%d.0" in the message. The minimum setting works that way, they cannot specify the exact version at which fpops counting was enabled (5.2.7 ?).

                                                                 Joe

There's a pair of settings which can be put into the project configuration to warn users that a change in minimum allowed core client is coming. One setting says what the minimum will be, and any hosts which are running a lower version will get a message in each Scheduler reply saying:

Starting in %d days and %d hours, project will require a minimum BOINC core client version of %d.%d.0. You are currently using version %d.%d.%d; please upgrade before this time.

The %d's are of course replaced by numbers. The message is at low priority like other server messages until 3 days before the deadline, then changes to high priority so it will be shown in red.

I suspect there are many users who never look at the messages, but the feature obviously should be used, I'd think starting a month or so before. If they could send out email to affected users about the same time, that would cover about all that's possible in the way of advanced warning. Well, a news item should be placed on the project front page too.

Note the "core client version of %d.%d.0" in the message. The minimum setting works that way, they cannot specify the exact version at which fpops counting was enabled (5.2.7 ?).

                                                                 Joe

Joe.....I am sorry, but how is that going to reach the 'set and forget' crowd?
It's all well and good to broadcast the news to those who want to hear it..
But you have read about things falling on deaf ears?

I suspect that many old users....if confronted by a strange message popping up on their computer...would simply say...oh crap, I forgot I had that ***** (supply your own expletive) program running.......and stuff it......

---

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

There's a pair of settings which can be put into the project configuration to warn users that a change in minimum allowed core client is coming. One setting says what the minimum will be, and any hosts which are running a lower version will get a message in each Scheduler reply saying:

Starting in %d days and %d hours, project will require a minimum BOINC core client version of %d.%d.0. You are currently using version %d.%d.%d; please upgrade before this time.

The %d's are of course replaced by numbers. The message is at low priority like other server messages until 3 days before the deadline, then changes to high priority so it will be shown in red.

I suspect there are many users who never look at the messages, but the feature obviously should be used, I'd think starting a month or so before. If they could send out email to affected users about the same time, that would cover about all that's possible in the way of advanced warning. Well, a news item should be placed on the project front page too.

Note the "core client version of %d.%d.0" in the message. The minimum setting works that way, they cannot specify the exact version at which fpops counting was enabled (5.2.7 ?).

                                                                 Joe

Joe.....I am sorry, but how is that going to reach the 'set and forget' crowd?
It's all well and good to broadcast the news to those who want to hear it..
But you have read about things falling on deaf ears?

I suspect that many old users....if confronted by a strange message popping up on their computer...would simply say...oh crap, I forgot I had that ***** (supply your own expletive) program running.......and stuff it......

Mark... It my understanding that there will not be any "strange message popping up" on anybodys computer, rather a subtle message in the log, viewable under the "Messages" tab of the Boinc Manager, and probably unnoticed by the most of those receiving said message. (Joe please correct me if I am wrong).

Joe... What happens when the elapsed time passes and the "minimum version" is enforced? Are WU's blocked from being sent to clients not meeting the minimum BOINC version criteria? Thus not "wasting" cycles on a host working on a result that would ignored upon completion anyway. It is my opinion that this is the most elegant and non-intrusive solution.

My main concern is that of impact to the projects data throughput. Can we quantify the amount of work that would be lost by those exiled (for lack of a better term) hosts?

Regards,
John

---

There's a pair of settings which can be put into the project configuration to warn users that a change in minimum allowed core client is coming. One setting says what the minimum will be, and any hosts which are running a lower version will get a message in each Scheduler reply saying:

Starting in %d days and %d hours, project will require a minimum BOINC core client version of %d.%d.0. You are currently using version %d.%d.%d; please upgrade before this time.

The %d's are of course replaced by numbers. The message is at low priority like other server messages until 3 days before the deadline, then changes to high priority so it will be shown in red.

I suspect there are many users who never look at the messages, but the feature obviously should be used, I'd think starting a month or so before. If they could send out email to affected users about the same time, that would cover about all that's possible in the way of advanced warning. Well, a news item should be placed on the project front page too.

Note the "core client version of %d.%d.0" in the message. The minimum setting works that way, they cannot specify the exact version at which fpops counting was enabled (5.2.7 ?).

                                                                 Joe

Joe.....I am sorry, but how is that going to reach the 'set and forget' crowd?
It's all well and good to broadcast the news to those who want to hear it..
But you have read about things falling on deaf ears?

I suspect that many old users....if confronted by a strange message popping up on their computer...would simply say...oh crap, I forgot I had that ***** (supply your own expletive) program running.......and stuff it......

I wasn't really advocating that approach, just showing what the BOINC developers have provided and how it might be used. I suspect the project has already reviewed their options and decided to live with the complaints from the tiny percentage of participants who use these boards.

Your ideas and others about modifying the granting of credit are certainly technically feasible, but would require changes to BOINC. An independent and well-funded project might do that kind of modification, but I don't think this project is likely to. With David Anderson being the director of SETI@home it may not be possible at all.

All the credit related code is in BOINC. Most of the Validator is too, the project-specific part is simply told to check two or more results and can only return a very limited set of responses like valid, not valid, no consensus, or validate error.

                                                                 Joe

There's a pair of settings which can be put into the project configuration to warn users that a change in minimum allowed core client is coming. One setting says what the minimum will be, and any hosts which are running a lower version will get a message in each Scheduler reply saying:

Starting in %d days and %d hours, project will require a minimum BOINC core client version of %d.%d.0. You are currently using version %d.%d.%d; please upgrade before this time.

The %d's are of course replaced by numbers. The message is at low priority like other server messages until 3 days before the deadline, then changes to high priority so it will be shown in red.

I suspect there are many users who never look at the messages, but the feature obviously should be used, I'd think starting a month or so before. If they could send out email to affected users about the same time, that would cover about all that's possible in the way of advanced warning. Well, a news item should be placed on the project front page too.

Note the "core client version of %d.%d.0" in the message. The minimum setting works that way, they cannot specify the exact version at which fpops counting was enabled (5.2.7 ?).

                                                                 Joe

Joe.....I am sorry, but how is that going to reach the 'set and forget' crowd?
It's all well and good to broadcast the news to those who want to hear it..
But you have read about things falling on deaf ears?

I suspect that many old users....if confronted by a strange message popping up on their computer...would simply say...oh crap, I forgot I had that ***** (supply your own expletive) program running.......and stuff it......

The message does not "pop up". It is displayed just like any other server message in BOINC. You have to go to the messages tab to see it. Thus, the only ways to see it are either to actively be running a manager or to be browsing the text file.

Again, precedent is on the side of doing this... The closure of SETI Classic was done the exact same way. Those that didn't install BOINC were left behind. I'd be willing to bet (again, if I had the money) that there were more people left behind due to that than there are even people affected by this situation.

As long as the project shows that it made an effort to contact people, I do not see a problem with moving ahead. As stated, if the NTLM issue is really a bugger, then it will be moved up the priority tree ahead of Social Networking.

I suspect the project has already reviewed their options and decided to live with the complaints from the tiny percentage of participants who use these boards.

If the sabre rattling about credit parity happens again, how can one demand that other projects use this project as a reference when there are problems with the credit system?

Personally, I'd choose Einstein instead as the reference... You have server-side fixed credit. A 4.45 client would not do squat to its' own granted credit or to the granted credit of a 5.10.30 client. They have tried to keep parity with SETI, but since they appear to target the stock application, despite their application having a better degree of optimization (not quite there yet with S5R3, but it was there with S4 and S5R1), when they recalibrate to SETI, they devalue their work, as I can then pick up the app that you and others worked on for here and get higher cr/sec than there.

Right now, my cr/sec values over there are at about 0.007354, where here BOINCstats reports it as 0.007904. That is up a LONG way from where it used to be (0.006ish). Windows users had a penalty for quite some time there vs. Linux. Despite the claim at Boinc Combined Statistics that Einstein is giving more, for me it wasn't true until the latest Power Users application. Up until the 4.26 version there that has the VC++ G7 option enabled, I was seriously lagging behind what I could get here using the app you worked on. The 4.32 Windows version there appears to match or beat average cr/sec of version 2.4 here. However, since it has SSE, it can't go out to the public. Only x87 can go out generally, unless they get feature detection working. Please correct me if I'm wrong about that (x87 only in the stock application)... When the recalibration happens, and it will, then if we really want to talk about credit equality, then if they keep the "power users" apps going, it will need to generally match 2.4/2.6 (or whatever the next version is) here, as well as the stock apps will need to match...

Anyway, this may seem "OT", but it's not. David Anderson, as well as others, seem to think that SETI made significant strides in the realm of credit-granting. I'm pointing out that Bruce and Bernd have done a good job as well, and their project doesn't suffer from this tiresome noise that nobody on the project team here will just deal with officially... Silence is not "dealing with it"...

Brian

Personally I don't see the problem with setting a minimum version... I speak as a former 'set and forget' user and yes I know, not all 'set and forget' types are the same. Email(s) moved me from classic to Boinc. I'm not sure what caused me to upgrade Boinc occassionally, although last year it was no work from Predictor due to them setting a new minimum version, which meant I wasn't getting any work from them. Yep, if I remember correctly I swore each and every time, but change I did. :)

---

Happy birthday Calm Chaos!!! Terrible twos?


Calm Chaos... are you feeling it yet?

Again, precedent is on the side of doing this... The closure of SETI Classic was done the exact same way. Those that didn't install BOINC were left behind. I'd be willing to bet (again, if I had the money) that there were more people left behind due to that than there are even people affected by this situation.

There's one major difference that you're not pointing out: SETI@Home Classic had to shut down due to lack of funding. If they didn't make the change, there would be no SETI@Home.

Forcing people to upgrade their version of BOINC != as shutting down Classic. And yes, they lost a lot of people during the transition. Why would they potentially want to lose more? To solve the complaints of a few percent on the boards here? Eric has stated he does not want to lose anymore users than what has already been lost to Classic. There's no point in making the situation worse by cutting off all those old clients, who are still providing valid science by the way.

I do not accept that shutting down Classic would be akin (and is precedence for) mandating a minimum BOINC version.

As long as the project shows that it made an effort to contact people, I do not see a problem with moving ahead.

I think sending out a friendly email reminding people that BOINC is an ever-changing, ever-evolving piece of software and that upgrades are available would be a fine option.

But what to sell them on? I can guarantee you these set-it-and-forget-it types don't care about credit, otherwise they'd be checking closely and complaining like everyone else. No, these types wanted to be part of the science and installed an app to donate CPU time and forgot about the rest.

Many people would probably upgrade if simply made aware that there are newer versions (as has been said before, once contacted they usually respond with "I didn't know there was a newer version"). Others, however, cannot be bothered unless there's some killer reason to do so. Beyond that, it's simply more headaches to upgrade when something is already working. The current "stable" version has problems of it's own (not related to the NTML issue).

At the least, an email would be nice though. No minimum version should be set just yet, to see what the outcome is of people upgrading after a reminder.

---

Brian,
You say there are problems with the credit system here but you do not present any meaningful evidence.
Yes some users use old clients and claim low, but that is balanced by the few people that use optimised apps and claim more credits per hour.
But really credits do not matter to the projects they just want units crunched, and the more the merrier.
If BOINC could be more like windows, and other software, so that it could be made auto update, download and update later, or do it manually. And with an option to revert to last version, if it goes base over apex, then we might get somewhere.
But you do seem to be trudging a lonely furrow in not having Seti as the baseline for credits. It can't be Einstein at the moment with its cyclic cr/hr, I would object strongly, my slow machine has just done four straight units at the top of the curves and getting very low cr/hr there. CPND does its own thing and has historically granted slightly more than average, probably to encourage people to tackle the very long units. Personally I found it too much effort to keep doing backups, so that if it did crash, and it did occasionally, the unit could be restored from the backup. Only did do one unit to the end, although about 5 were started.
Rosetta, from my experience some time ago, cannot even be considered. And I have no knowledge of WCG, and no wish to.
The only other project that can have any claim is Predictor as it was the first BOINC project, but they shot themselves in the foot and are supposedly moving.

Any other suggestions I can shoot down? ;-)

Andy

Why would they potentially want to lose more? To solve the complaints of a few percent on the boards here? Eric has stated he does not want to lose anymore users than what has already been lost to Classic. There's no point in making the situation worse by cutting off all those old clients, who are still providing valid science by the way.

I'll accept the notion about funding, but I ask that you consider this:

There is a minimum version that was already supposed to have been 4.19. Tony proved before his departure that the minimum version wasn't being enforced. If it was set up to 4.19 at one point in time, then one has to ask if the pre-4.19 clients are still "providing valid science". If they are, then the fact that they were cut off at one point in time IS precedent.

Additionally, inaction on the subject may eventually have the identical cummulative effect of losing people, as newer people with newer clients who do care about credit may also chose to not participate in the project because of this issue. Let's not live in a dream world - credits do matter, else David Anderson wouldn't have did what he did lately.

At the least, an email would be nice though. No minimum version should be set just yet, to see what the outcome is of people upgrading after a reminder.

At least it would show some kind of official action, other than inaction.