LOL I see it more like this analogy:

For the last year an employee has had his friend clock him in 3 hours before he actually got to work. Now the boss has caught on and stopped him. Does the employee have a right to complain that his fraud was stopped, or should he be grateful to still have a job???

That is a flawed analogy. If the devs had wanted to stop the optimized clients and managers they could have by simply saying they were cheating. Many of us held off optimizing our systems for quite some time waiting to see. They did not, and it became acceptable to optimize, so no one was cheating as your analogy implies. We were doing what had become "official" even if by default. To now take it away from us is a "downgrade" (or loss of wages) no matter how you look at it.

---

That is a flawed analogy. If the devs had wanted to stop the optimized clients and managers they could have by simply saying they were cheating. Many of us held off optimizing our systems for quite some time waiting to see. They did not, and it became acceptable to optimize, so no one was cheating as your analogy implies. We were doing what had become "official" even if by default. To now take it away from us is a "downgrade" (or loss of wages) no matter how you look at it.

That's certainly one way of seeing it.

I remember when they had plans to shut down classic and they kept informing people of the change, asking over and over for them to switch, Then when they had no other way to affect the change, they finally went ahead and pulled the plug. Seti seems unwilling to be confrontational, and just say/do things which might upset the user base.

Perhaps, they came out with Fpops to address the use of optimized core clients without actually saying so? Saying "hey your cheating and we're going to stop it" is confrontational. Implementing a "new way" is a more polite (if not chicken) way of doing it. Why else would Fpops counting be implemented? The only reason I can think of, is to get a better grasp on the unfair credit issues including optimized core clients.

so, why else would they switch to fpops?

LOL I see it more like this analogy:

For the last year an employee has had his friend clock him in 3 hours before he actually got to work. Now the boss has caught on and stopped him. Does the employee have a right to complain that his fraud was stopped, or should he be grateful to still have a job???

Tony, I would hope that someone of your character is not accusing anyone of cheating. My computers are not hidden. They all belong to me PERSONALLY, and are here in my home. I would NEVER cheat at this or any other project. I am hoping your comment was a joke, anyway. I'm still rather ill with a bad bacterial infection, so I may be reading more into this than I should.

But, like it or not, credits are the "wages" of the D.C. world. If participants can earn more credit from their work at a different project, then those crunching for competition will either move to a different project, or QUIT. Competition is in the human spirit. By such a drastic cut in granted credit, it will effectively eliminate competition. Under the current granted credit for enhanced, once the changeover is complete, basically all users and teams will be frozen where they are. It would take such a large investment to be competitive again, that there will no longer be an incentive to compete. If it were not for the competition, I would have quit crunching LONG ago. This is a hobby that has fueled my interests, imagination, and my competitive spirit. Take the fun out of the project, and what's left? Why do more? Why continue at all?

Regards, Daniel.

[quote]...

Well, let's see, "classic", if a fast computer used 1h/wu and a slow 6h/wu, the fast would get 24 "wu-credit"/day while the slow 4 "wu-credit"/day, meaning fast gets 6x more credit/day.

Well it depended on the benchmarks run by boinc.

Not in "classic". ;)


But anyway, in case no-one understood, just like I've "normalized" to 1h in the deadline-table, did something similar here to make the calculations "easier" to follow.
... And not to forget, I've not got a computer that uses 6x longer cpu-time than the fastest. ;)

But, 1h/wu atleast in "classic" isn't so far-off, since there was some OS/cpu-platforms that had average cpu-time close to 1h, not sure if not one of them was actually less than 1h on average, but since this table isn't there any longer can't check.

Where did you pull that 24 credits off ? Thought it was intended to be more like 32 credits per WU on average ?

Well, the quoted is "classic", but anyway:

Results from June 2005, 3 computers, removed all granted < 10 CS, "slightly-optimized" seti-application:
Table 1;
#; # results - average claimed - average granted
1; 201 results - 16.43 CS/result - 22.91 CS/result
2; 171 results - 24.60 CS/result - 25.81 CS/result
3; 139 results - 21.41 CS/result - 24.07 CS/result
Total; 511 results - 20.52 CS/result - 24.20 CS/result

In case anyone wonders, this is weighted average, #results for each computer influences the average.


To get average cpu-time for each computer, uses a larger collection with the "standard" seti-application from January/March 2005. Note, since BOINC v4.19 and earlier with the too-high benchmark was the dominating back when, the CS/result was higher:
Table 2;
#; # results - granted CS/result - cpu/result - CS/h (granted from table-1)
1; 890 results - 29.41 CS/result - 10815 s - 7.626 CS/h
2; 796 results - 31.85 CS/result - 13763 s - 6.751 CS/h
3; 712 results - 31.40 CS/result - 16596 s - 5.221 CS/h


Seti_Enhanced, since angle-range gives much bigger variation in claimed credit, per result doesn't make much sence, so uses CS/h instead:
Table 3;
#; # results - claimed CS/h - granted CS/h - claimed variaton from v4.18
1; 9 results - 7.661 CS/h - 7.795 CS/h - +0.5%
2; 29 (22gr.) - 5.734 CS/h - 5.671 CS/h - -15%
3; 26 (19gr.) - 4.919 CS/h - 4.877 CS/h - -5.8%

Since for Seti_Enhanced the only reason for different granted credit is users running outdated BOINC-clients, used the claimed credit when comparing to "official" v4.18

One computer was dead-on, +0.5% from v4.18, while one takes roughly 6% performance-hit. The last, computer-2, has really crappy memory-bandwith, and it actually looks like it's performing worse now with 2 memory-sticks compared to only 1 last year, atleast it did take a peformance-hit in CPDN...

Now, if you looks more detailed on the different angle-ranges, CS/h is higher around ar=0.4 than on VHAR, meaning #1 switches to 7.880 CS/h and +3.3%, #2 switches to 6.011 CS/h and -11, while #3 gives 5.104 CS/h and -2.2%.


BTW, one final table at the end:
Table4; Variation in CS/h on same computer:
#; v4.18 claimed - v4.18 granted - v5.12 claimed
1; 1.60x - 3.92x - 1.63x
2; 1.82x - 5.56x - 1.29x
3; 2.28x - 3.24x - 1.30x


So yes, Seti_Enhanced isn't completely linear with different angle-range, it seems max variation is 30%, the 1.63x was due to -9 result_overflow, these is already removed from v4.18-data. But, if 90%+ is ar=0.4xx, the effectual average variation between su is likely more like 5%, and since VHAR is giving less CS/h there shouldn't be any big reason for aborting the "slow" wu since this will actually give less credit...

Also, Seti_Enhanced doesn't give exactly the same credit/hour as v4.18, but the variation seems to be within 10% in granted credit.

Now, seeing the same computer even on the same computer when relying on benchmark/cpu-time managed to give 2.28x max variation in claimed credit/hour, and max variation in granted was 5.56x, so taking a 5%-10% "credit-hit" is in my opinion a small price to pay for the huge improvement in accuracy in claimed credits under Seti_Enhanced.

Not to forget, as BOINC alpha has shown, even re-running the exact same wu on the exact same computer can give over 30% variation in reported cpu-time, so even with "perfect" benchmark or "perfectly-calibrated" BOINC-client you can have 30% variation in your claims...



So, bottom line is, for the majority of users that runs the "normal" SETI@Home v4.18-application, the impact on average CS/h when switching to Seti_Enhanced is likely less than 10%, and since all takes this "performance-hit" it's not significant. The switch from v3.00 to v3.03 in "classic" was much bigger than 10%.


The only that gets a "significant" change in CS/h is the (vocal) minority of users running highly-optimized seti-applications, that doesn't get 3x-4x more CS/h any longer.
Well, you can claim Seti_Enhanced should also give 3x-4x more CS/h to keep-up with this, but this means all seti-users will get 3x-4x more CS/h, meaning the optimizers won't get any credit-advantage over "normal" users anyway under Seti_Enhanced. Also, SETI@Home will give 3x-4x more CS/h than in any other BOINC-project, so any form of cross-project-statistics would be meaningless.



Note at the end, have no idea how Seti_Enhanced performs on Intel-cpu's, there's maybe a completely different result here... :)

That's certainly one way of seeing it.

I remember when they had plans to shut down classic and they kept informing people of the change, asking over and over for them to switch, Then when they had no other way to affect the change, they finally went ahead and pulled the plug. Seti seems unwilling to be confrontational, and just say/do things which might upset the user base.

Perhaps, they came out with Fpops to address the use of optimized core clients without actually saying so? Saying "hey your cheating and we're going to stop it" is confrontational. Implementing a "new way" is a more polite (if not chicken) way of doing it. Why else would Fpops counting be implemented? The only reason I can think of, is to get a better grasp on the unfair credit issues including optimized core clients.

so, why else would they switch to fpops?

So that a workunit claimed X amount of credit, no matter what machine it is processed on. And that is fine. I think it's great. But to do that, then also slash the amount of credit granted by each workunit is WRONG. At least running v5.11, the granted credit WAS close to the break-even point. But when each one of us looks at what they have accomplished here, then sees that accomplishment cut by a factor of THREE, then what do we have to look forward to?

Regards, Daniel.

How about this...........

The company has a few employees that are extremely efficient in their work. These employees are less than 1% of the work force but they perform their work 3 to 4 times faster on any given day. These employees are rightfully rewarded for their efficiency with an RAC that is higher and also earning more credits during their shift than the other 99% of employees. One production manager was heard to say of these workers "I wish I could clone them."

Now suddenly the company has changed it's mission statement and wishes to make a more detailed examination of all work. Quality is now more important than quantity. There is no discrimination to those former 1% of the employees. They are simply being integrated back into the mainstream with the rest of the employees and they must expect to be compensated exactly like the rest of the employees. Of course they are free to explore other avenues of employment but they will always remember their good times at Seti.

The playing field is level again as it should be!

---

Boinc....Boinc....Boinc....Boinc....

Seti seems unwilling to be confrontational, and just say/do things which might upset the user base.

And yet, apparently, this move is upsetting a large portion of their user base. Hmmm, kind of contradicts what you said.

Perhaps, they came out with Fpops to address the use of optimized core clients without actually saying so? Saying "hey your cheating and we're going to stop it" is confrontational. Implementing a "new way" is a more polite (if not chicken) way of doing it. Why else would Fpops counting be implemented? The only reason I can think of, is to get a better grasp on the unfair credit issues including optimized core clients.
so, why else would they switch to fpops?

If the previous credit system was so unfair, why have I not seen discussions to that affect? Everybody appeared to be rocking along quite happy with the previous system. Contention only became apparent with the new system, which leaves me to conclude that it is the one that is unfair.

---

I would guess the amount of credit that the enhanced application claims has been tuned in a way that seti stays fair w.r.t. credit/cpu hour when compared to the other boinc projects.

There has been a big advantage with the optimized standard clients.

I more or less expected the credits to go down like this.


Regards Hans

---

Tony, I would hope that someone of your character is not accusing anyone of cheating. .

I certainly wasn't naming any names, especially you. But my comment wasn't a joke.

Some windows based optimized core clients are based to claim nearly 32.29 credits per wu. This assigns an arbitrary value to a wu which is not intended by the developers of boinc. 32.29 credits was the idealized value of a "reference" result. This WU "picked from a hat" (as it were) happens to be 25% longer than the average wu. Since the formula for claimed credits (using benchmarks) is based on "benchmark times cpu time", the value of an average WU is between 24-25. Any optimized core client claiming more as a standard is violating the intent of the developers and is IMO cheating.

This use of optimized core clients has spread to other projects. Except for Trux's client, they are wreaking havoc there. Every forum is filled with comments about this. Even users of those projects who have NO valid reason for using the optimized core clients are doing so, just to claim more than they deserve, and that is cheating. There only justification is to say "hey, If I'm going to compete, I have to", or "everyone else is doing it"

It seems to me that litlle if any prior planning went into the thought process while creating an optimized core client as to what impact it would have on boinc as a whole, and was solely limited to "get me as much credit as possible". It's boincs intention (and certain Dr. Andersons') that the most important thing is "parity" between projects when it comes to boinc.

One thing that's bothering me is why hasn't seti set the data table to only ship work to CC's with a min value of 5.2.6.

How about this...........

The company has a few employees that are extremely efficient in their work. These employees are less than 1% of the work force but they perform their work 3 to 4 times faster on any given day. These employees are rightfully rewarded for their efficiency with an RAC that is higher and also earning more credits during their shift than the other 99% of employees. One production manager was heard to say of these workers "I wish I could clone them."

Now suddenly the company has changed it's mission statement and wishes to make a more detailed examination of all work. Quality is now more important than quantity. There is no discrimination to those former 1% of the employees. They are simply being integrated back into the mainstream with the rest of the employees and they must expect to be compensated exactly like the rest of the employees. Of course they are free to explore other avenues of employment but they will always remember their good times at Seti.

The playing field is level again as it should be!

I find it extremely funny that you put it that way. The reason: A local company did just that (only I think it was more like 5% of their workers). After being told their wages were being decreased, the 5% left the company for greener pastures. The company implemented their plan and within 1 year they were in Chapter 11.

The reason: Not only did their plan reduce quantity, but the quality also fell off by a considerable margin. Turned out that the 5% that left were not only the highest in production but were also turning out the highest quality of work.

---

One thing that's bothering me is why hasn't seti set the data table to only ship work to CC's with a min value of 5.2.6.

Tony...I think this is probably not far in the future.

---

Boinc....Boinc....Boinc....Boinc....

I, for one, don't even think the idea of needing an optimized "windows" core client has any merit. However, designed or implemented. It's the intention of boinc that claimed credit be entirely dependent on how fast a machine you have period. the formula put forth and adopted by boinc is "claimed credit = ([whetstone]+[dhrystone]) * wu_cpu_time_in_sec / 1728000". There's nothing there that states a wu has a standard value at all. It's intent was to reward users based upon "how fast a machine" time "how long it worked".

This "Idea" that a wu should have a certain value is wrong. It's a paradigm in users minds based upon prior methods (read classic- 1 wu = 1 credit}. If users use an optimized application, that's fine (if it's results are scientifically valid/useful), but any wu done ISN'T, and shouldn't be viewed as having the same value as one crunched without an optimized app, because Boinc doesn't place a standard value on any wu. It's simply benchmark times work time. I.E if you use an optimized app, then you've done less work as measured by time (not WU count), and should be claiming less, not using some third party software to impart someone elses idea of WU values.

Under the original boinc intended system your computer would be claiming exactly the same credit, without regard to project (except CPDN). It's Parity between projects which is the goal of boinc.

In this post by Crunch3r he states:

I would max. the benchmarks out a bit more but it looks like that it's not possible to get any further improvements.

Does it look like he cares what the intent of Boinc or seti are? It's all about credits.

You looked at the wrong project ;-)

Sorry, but you posted here and I was looking here, so it seemed the obvious place to start....!

Seriously, that sounds like somebody finger-fumbled when compiling the beta 5.13 - and BETA is exactly the right place to make those finger-fumbles, that's what it's there for - so mistakes can be made in (semi) private, without frightening the masses.

I hope you've reported in the (apparent) bug - not being a 'volunteer tester' myself, it's not so easy to check.

To clarify:

The Windows Beta build of 5.12 had an unintended fpops multiplier of 7, other platforms had the intended 3.35.

All Release builds of 5.12 have the intended 3.35 multiplier, as do the Beta 5.13 and 5.14 builds.

IOW, the credit claims in Beta from a Windows system running Beta 5.12 are slightly more than twice what is intended.

                                                                         Joe

In this post by Crunch3r he states:

I would max. the benchmarks out a bit more but it looks like that it's not possible to get any further improvements.

Does it look like he cares what the intent of Boinc or seti are? It's all about credits.

Hi Tony.

Please don't be so hard on us optimizers :o)

The standard app gained quite a bit of speed trough optimisation, and a lot of the changes have found their way into the enhanced app.

Without these, the enhanced crunching times would easily be 3-4 times longer...

Regards Hans

P.S:
The post you quoted addressed getting the optimized app to claim the same amount of credit than the standard app.
This horse has been beaten to death already ....

Crunch3r puts a lot of effort into releasing only valid apps.

---

Hans, I have NO issues with optimized applications. Everything I've said is in relation to the Boinc Core Clients (optimized for windows). I use an optimized app my self, or I did until enhanced was released.


Yes, beaten to death by us old timers, but SargeD stated he hadn't seen it discussed before, and some new people out there don't understand it. So it seems we must discuss it yet again to catch up the people who weren't here when Windows optimization started with TMR.

It's been many many months since I've had to pick up this stick again. I've remained quiet, biting my lip for many many months. It isn't easy, you know?.

regards
tony

Hans, I have NO issues with optimized applications. Everything I've said is in relation to the Boinc Core Clients (optimized for windows). I use an optimized app my self, or I did until enhanced was released.

regards
tony

Hmm. OK

I'm in the process of dropping seti 4.x completely from my hosts because of the credit muddle.

IMO the non-enhanced seti app has become obsolete.

Regards Hans

---

I've got it out of my system now, I feel better. The pent up stress level has diminished. I shall drop it again.

Ingleside

I really do appreciate the time you are taking... Realistically, I am PRO Enhanced!

The hours spent moving back an forth between here and Beta have show that we are getting close... Credits and Win 9x were the final issues to be resolved...

Currently all we are doing is airing our opinions... Those opinions are based on our own "small look" at the seti credits world...

So as I have said, we need to get Enhanced Transitioned and stable for the daily output to all machines... Only then can we have a true before and after comparison...

...
Well, let's see, "classic", if a fast computer used 1h/wu and a slow 6h/wu, the fast would get 24 "wu-credit"/day while the slow 4 "wu-credit"/day, meaning fast gets 6x more credit/day.

Well it depended on the benchmarks run by boinc.

Not in "classic". ;)

But anyway, in case no-one understood, just like I've "normalized" to 1h in the deadline-table, did something similar here to make the calculations "easier" to follow.
... And not to forget, I've not got a computer that uses 6x longer cpu-time than the fastest. ;)

But, 1h/wu atleast in "classic" isn't so far-off, since there was some OS/cpu-platforms that had average cpu-time close to 1h, not sure if not one of them was actually less than 1h on average, but since this table isn't there any longer can't check.
Heavy Snipping...

---

Please consider a Donation to the Seti Project.

Sorry about the work stuff, It was going to be deleted, The 1:1 was meant of course. Right now It's more work and less credit, What next forbid overclocked computers from running Boinc??? Whole teams are running that way.

I think I have more grey hairs than You, Junior.

Along with the grey hairs, I would have expected a little more common sense.

I'm not running optimized clients at this time. Not opposed to optimized clients, and yes, they are faster. I don't know how much better the optimized enhanced clients run.

What I do know is that 4.18 claims about 11 credits an hour, and I'm usually granted about 9.2 (averaged over four work units).

Across four 5.12 work units, I requested and was granted 7.4.

So, yeah, credit is a little lower based on my sample. Is it more accurate? Seems to be.

The sample is kind-of small -- it should be averaged over a few dozen work units of each type.

Someone else pointed out pinball machines -- how the maximum score used to be 9,999 and is now in the millions. All SETI has to do is double the credits, then everyone who is complaining will be excruciatingly happy.

... and then Einstein will tweak their application to request more credits, and next thing you know, we'll be griping about "credit inflation."

---