Enhanced 5.12 FpOps claimed quite exactly what the CC 4.19 time/benchmark based credits would have claimed, 5.13 claims only 50%

4.19 CC?
AFAIK 4.18 was the most recently released Core Client.
From memory (what's left of it) 4.19 was the last of the 4.x series BOINC Managers & was known for claiming credits way too high.

---

Grant
Darwin NT

Enhanced 5.12 FpOps claimed quite exactly what the CC 4.19 time/benchmark based credits would have claimed, 5.13 claims only 50%

Looking at the two results currently showing for your systems, I think you'll find that Crunch3r's 5.11 (which you are currently using) claims double what it should, and 5.12/5.13 - whether stock or Crunch3r - all claim the same as each other.

Enhanced 5.12 FpOps claimed quite exactly what the CC 4.19 time/benchmark based credits would have claimed, 5.13 claims only 50%

Looking at the two results currently showing for your systems, I think you'll find that Crunch3r's 5.11 (which you are currently using) claims double what it should, and 5.12/5.13 - whether stock or Crunch3r - all claim the same as each other.

You looked at the wrong project ;-)

This would have been the place :

http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=4105

An example for 5.12 claiming the same by FpOps and by Benchmark would be here - with one 5.13 result claiming only 50% :

http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=183789

An example for 5.13 claiming only half is here :

http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=184243

In Beta I am using only "stock" programs as I want to see what's going on.

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.

Enhanced 5.12 FpOps claimed quite exactly what the CC 4.19 time/benchmark based credits would have claimed, 5.13 claims only 50%

4.19 CC?
AFAIK 4.18 was the most recently released Core Client.
From memory (what's left of it) 4.19 was the last of the 4.x series BOINC Managers & was known for claiming credits way too high.

4.19CC (core client) - Boinc Core Client - boinc.exe (like 4.45, 5.2.6 and so on)
4.18 (science application)- setiathome executable (like 4.11, 5.12 and so on)

The older CC's (before 5.2.6) claim credit with benchmarking and time used (by science app) to finish a workunit, no matter which science app is used.

The newer CC's (5.2.6 and newer) do the same thing for the old science applications (4.11/4.18), but for the 5.* (enhanced) science app they claim credit by looking at the flop count of the science application.

Greetings,
Sander

---

... Seriously, that sounds like somebody finger-fumbled when compiling the beta 5.13 ...

Dang, you're right, I assumed that the binaries are identical in both projects as that's how we work in our company : The latest successfully tested beta binary goes directly into production, without compiling it again.

The binaries are not identical between Beta and the main project so maybe not fully comparable. Sorry :-/


p.s.: the reason why I'm still using CC4.19 on some boxes is the squid/auth that 5.x cannot handle - or could not handle, the latest core client has some changes there so it might go through the firewall.

Once people have migrated to the latest managers & core client, things should start to level out.
Of course the mix of optimised managers & non optimised core clients, optimised core clients & non optimised managers, optimised core clients & optimised managers will cause it's own hiccups, but over time things will become more equitable.

So a whole line of decisions were made that discourage migration and consolidation?

43 years of using, working with, fixing and designing new computers and their software has taught me that just because something is "new and better" does not mean people will migrate to it, or should. They have to have a good reason to make the change from the old and comfortable. Force (as in "you don't get no more WU's if you don't upgrade to the newest version") is not a very acceptable incentive. Causes "migration" to other hobbies. I know people who still use WP 5.1 for DOS on their Windows 98/ME systems. I still use a text editor written for use with DOS 1.1 as it does things I use that the best Windows applications will not do. That and a few other old DOS programs are more useful to them and me than anything Windows XP or VISTA can offer to replace them. No incentive to migrate, and the old programs usually don't work!

And who wants to crash their smooth working Seti setup (and system) with something some people are having trouble with? And that will Grant them less satisfaction than they have, after the time and effort spent obtaining what they have. They migrated to optimized applications and then optimized managers due to an incentive. And now you want them to give those up for what they perceive is less? One stock application instead optimized MMX/SSE/SSE2 versions for their different machines?

In a world of fast computers, broadband response times and instant gratification, Enhanced WU crunch times of what were originally projected would have caused me, and I suspect others also, to shut down the systems when we were not actually using them, instead of leaving them on 24/7.

43 years of using, working with, fixing and designing new computers and their software has taught me that just because something is "new and better" does not mean people will migrate to it, or should.

Because something is new isn't a reason to move to it.
If it is better then they should.

Force (as in "you don't get no more WU's if you don't upgrade to the newest version") is not a very acceptable incentive.

Nor is supporting 12 previous versions of software (and hardware) just to keep those that are happy as things stand isn't acceptable either.

I know people who still use WP 5.1 for DOS on their Windows 98/ME systems.

I know people that use homeopathy.

I still use a text editor written for use with DOS 1.1 as it does things I use that the best Windows applications will not do.

Right tool for the right job. If it's not broken, then don't fix it.
Seti classic was broken, hence the BOINC version came about.
There were perceived problems with it, and over time they have been addressed. This present change addressess one of the longest running & more contentious issues.

They migrated to optimized applications and then optimized managers due to an incentive. And now you want them to give those up for what they perceive is less? One stock application instead optimized MMX/SSE/SSE2 versions for their different machines?

I have read & read & reread what i previously posted & can't for the life of me see where you came up with the idea that i'm advocating people give up their optimised software.
All i said was that mix will mean it will take longer for things to settle down. It would have been nice if they had waited a month or so before releasing them (or however long it took for things to stabilise). I didn't say anywhere that they should never have released them or that they should be blocked.

In a world of fast computers, broadband response times and instant gratification, Enhanced WU crunch times of what were originally projected would have caused me, and I suspect others also, to shut down the systems when we were not actually using them, instead of leaving them on 24/7.

Your choice.
I expect many people did the same thing when Seti classic crunch times were increased dramatically by a new client.
However i personally don't see the need for instant gratification. Some things are not only worth waiting for, the wating makes them so much better.

---

Grant
Darwin NT

It would be nice if the forum software didn't put spaces in after the quoted text.
:~|

---

Grant
Darwin NT

"Is Enhanced Credit Fair?"

The New Seti Boinc Enhanced has doubled my WU processing time and cut in half my claimed Credit (using the stock client).

Yes, on many machines it will reduce your claimed credit. The question is "Does it reduce your granted credit?"

I tried my best to make the answer to the second question be "No" on average at least.

Eric

Currently, all the enhanced workunits sent to me are being granted around 62 credits, or about twice the credit for a regular workunit. But even with the fastest optimized enhanced apps, it is taking SIX times longer to process a workunit. Simple math will tell you that granted credit will now be only ONE THIRD of what we were getting. My Pentium D 950, running x86_64 Linux, with the x86_64 optimized enhanced app takes ~2 hours and 10 minutes per workunit, per thread, running 2 threads. For standard workunits, the same machine took 21 minutes per workunit, per thread, running 2 threads. So, it takes 3.25 times LONGER to produce the same amount of credit. It is the same on my Dual Opteron 248 WinXP machine. That box took ~40 minutes 20 seconds per workunit, per processor to crunch standard workunits. Now, it takes FOUR HOURS per workunit, per processor to crunch enhanced, using Crunch3r's optimized enhanced app. That box now takes 3.0 times LONGER to produce the same amount of credit. So, "Does it reduce your granted credit?" YES, by a factor of THREE, in fact.

I have been crunching Seti for SEVEN years now. I have donated financially to this project. I have spent tens of thousands of dollars on ever faster computers, not to say anything about the high electric bills. Yes, I crunch for the science, but also, I crunch for the competition. The competition is what feeds my interest to do more science. The devs recieve the benefits of all this crunching power, and all I expect in return is to have fair credit granted for the work I do. This huge reduction in granted credit feels like a slap in the face after all the time, effort and money I have devoted to this project. I am realizing now the frustration that drove Paul D. Buck to pull the plug on BOINC. I'm guessing that there will be a very large number of the top 1000 crunchers here that will also be leaving for greener pastures or shutting down entirely.

Regards, Daniel.

... <snip> ... but also, I crunch for the competition. ... <snip> ... I'm guessing that there will be a very large number of the top 1000 crunchers here that will also be leaving for greener pastures or shutting down entirely.

Chill, man.

This credit change isn't aimed at you personally. Every one of those top 1000 crunchers will be claiming, and receiving, 3x fewer credits than before - as will the rest of us. The competition between you remains on a level playing field.

It's like hyperinflation / revaluation. There's no point in earning 1,000 times more or fewer brass washers per hour, if you have to exchange the same 1,000 times more or fewer brass washers for a pint of beer!

Currently, all the enhanced workunits sent to me are being granted around 62 credits, or about twice the credit for a regular workunit.

?
For me Regular Work Units were generally being granted around the 15-20 mark, although using the official manager & core client my machines were claiming around 30. With Enhanced for around the same processing time i'm getting around 22 credits, so it's slightly more. Once again using the official software.

But even with the fastest optimized enhanced apps, it is taking SIX times longer to process a workunit. Simple math will tell you that granted credit will now be only ONE THIRD of what we were getting.

So what it boils down to is those that have been using optimised applications are upset that Seti has put effort into optimising their client, and that their new optimised clients aren't giving them the throughput that they're used to.

I have spent tens of thousands of dollars on ever faster computers, not to say anything about the high electric bills. Yes, I crunch for the science, but also, I crunch for the competition.

It appears to me that a lot of people have lost sight of what Seti is all about, and with it their perspective.
Seti classic was about using unused processor time to try & find Extra Terrestrial Intelligece. Note the bit about unused processor time.
If you decided to spend bucket loads of money of computer systems & power bills, well that was your choice. It may well have been better for the project if you had just donated the money directly to Seti, or now BOINC. But you chose to go the harware route & that's fine. But it was your choice to do so, and to get all worked up because you're no longer getting the credits you once did because the project is actually doing more science is just so childish i can't find the words to describe it.

I'm guessing that there will be a very large number of the top 1000 crunchers here that will also be leaving for greener pastures or shutting down entirely.

It would be a shame if that were the case, but then it's their decision to do so.


The allocation of credit has been one fo the longest running sorepoints for many people with BOINC. That problem has now been fixed, and people are all upset because it has been fixed.
It beggars beleif.

---

Grant
Darwin NT

Once people have migrated to the latest managers & core client, things should start to level out.
Of course the mix of optimised managers & non optimised core clients, optimised core clients & non optimised managers, optimised core clients & optimised managers will cause it's own hiccups, but over time things will become more equitable.

So a whole line of decisions were made that discourage migration and consolidation?

43 years of using, working with, fixing and designing new computers and their software has taught me that just because something is "new and better" does not mean people will migrate to it, or should.

Totally agree

They have to have a good reason to make the change from the old and comfortable.

They do the new software is more sensitive meaning that there is more chance of detecting ET, if they are there.

Force (as in "you don't get no more WU's if you don't upgrade to the newest version") is not a very acceptable incentive.

Why shouldn't the boffins insist that you use this better package?

Causes "migration" to other hobbies.

People come and go, it is their choice, nobody is forcing anybody to stay.

I know people who still use WP 5.1 for DOS on their Windows 98/ME systems. I still use a text editor written for use with DOS 1.1 as it does things I use that the best Windows applications will not do. That and a few other old DOS programs are more useful to them and me than anything Windows XP or VISTA can offer to replace them. No incentive to migrate, and the old programs usually don't work!

Of course if isn't broke and it does the job why change. I'm quite happy with WP5 didn't like the upgrade to 5.1, but if you, like me, have to produce output for clients then you have to use a package capable of producing output to their specification, even if their choice is wrong, or you don't get paid.

And who wants to crash their smooth working Seti setup (and system) with something some people are having trouble with?

And why should it crash your system, if it does then from my limited experience, with 8 computers, there is something wrong with your system(s).

And that will Grant them less satisfaction than they have, after the time and effort spent obtaining what they have. They migrated to optimized applications and then optimized managers due to an incentive. And now you want them to give those up for what they perceive is less? One stock application instead optimized MMX/SSE/SSE2 versions for their different machines?

Nobody is stopping the programmers out there from producing improved clients and apps again, you just seem to want it all now. Due to lack of manpower and funds, and the wishes of the community to support obselete systems, Berkeley produces one Seti application per general OS. If you want a version tailored to your specifications the source is open and you can compile your own. Don't you think that Eric K could have been more worthwhile employed since the release of 5.12 than to go chasing timer problems for an OS that the 'owner' no longer supports.

In a world of fast computers, broadband response times and instant gratification, Enhanced WU crunch times of what were originally projected would have caused me, and I suspect others also, to shut down the systems when we were not actually using them, instead of leaving them on 24/7.

Exactly why you should be grateful to the optimisers like TMR and Joe et al, who shared their knowledge and expertise to bring 5.12 with processing times that are acceptable to you, without waiting for the optimisers to do there stuff.

Andy

Suppose you show up at work tomorrow. Your boss tells you that he is cutting your wages by a factor of three. He tells you that you shouldn't feel bad about this, because everyone else at that company is also getting their wages cut. So, you think about all the years you spent at college training for your career, and all the years of service you've put in, only to suddenly recieve a severe wage cut for your troubles. So, will you and the rest of the workers at your company stay and deal with it? Sure, there will be some who stay. But when a "company" (project) slashes their "workers" (volunteer participants) "wages" (credits), most of the "workers" will either leave for a different "company", or for those that can afford to, just outright QUIT. We can live without Seti, but the project cannot exist without US. And what about all the other projects that would not even be here, if not for the success of Seti. Like it or not, credits are the "wages" of the D.C. world.

I don't know the exact statistics, but there is a very large percentage of hosts are either owned or controlled by a very small number of volunteers. If you start alienating those people who crunch for the competition, then what happens to the project? When you start seeing everyting you've worked to produce start crumbling before your eyes, it is difficult not to become frustrated. Just because an injustice happens to "everyone" does not make it right. More later, when I have the time.

Regards, Daniel.

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

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.