Looks like I'll be the start.

WHY lower the credit?? This project is using the credit specified by DA himself (which was also lowered at that time). He forces other projects to lower theirs and works around constantly to get them all lowered again. If he doesn't like it now than he should have given a lower number at that time.

Lowering it ~30% will certainly run users off again.
____________
Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Looks like I'll be the start.

WHY lower the credit?? This project is using the credit specified by DA himself (which was also lowered at that time). He forces other projects to lower theirs and works around constantly to get them all lowered again. If he doesn't like it now than he should have given a lower number at that time.

Lowering it ~30% will certainly run users off again.

I'm guessing that once a cruncher hits a hundred thousand million billion credits they won't notice the difference.

I guess he is saying there is no difference between 200m and 300m credits? personally I don't get that math. :Þ

The only worth goal for doing anything with credits is to make RAC true performance-related parameter. Then it can be used for host performance tuning.
For all other - cobblestones still unconvertable in $$ ;)

Currently there is paradoxal situation aroud credits formed.
The more weak in optimization sense stock app is, the more big boost opt app will give.
Then for opt app no "fair credit issue rate among other projects" rule applies at all, all participants try to use opt app instead stock one (it's very right choice BTW ;) ) but this lead to situation when project in whole overpay credits very much.

Considering projects competition for participants it beneficial for project to have very weak stock app and good opt app - this will attract credit hunters a lot.

From other side, porting back to stock optimizations from opt app is totally unpleasable move considering project credits (although it's very profitable for project science).
Optimisation of stock app itself will lead to change in credit issue rate by project ("fair credit issue rate among other projects" applies here).
While stock users may not notice any RAC change, RAC of opt app users will drop (!). I'm sure opt app users who cares about credits will not be pleased by that.

That is, current credit system is evil but its nature.
It not stimulates progress of stock app but contradict to it.

SSDD :p
____________
Seejay **Proud Member and Founder of BOINC Team Allprojectstats.com**

How a wu taking over 8000 secs gets less credit than a wu taking 7500 secs is beyond me...Why is it that the project devs always bow to pressure from D.A. and Seti?? Tell them to get stuffed and leave the project alone. Or do the people running this show have no backbone??

I will be crunching my cache then thats it see ya... Bloody pathetic...
____________

The only worth goal for doing anything with credits is to make RAC true performance-related parameter. Then it can be used for host performance tuning.
For all other - cobblestones still unconvertable in $$ ;)

Currently there is paradoxal situation aroud credits formed.
The more weak in optimization sense stock app is, the more big boost opt app will give.
Then for opt app no "fair credit issue rate among other projects" rule applies at all, all participants try to use opt app instead stock one (it's very right choice BTW ;) ) but this lead to situation when project in whole overpay credits very much.

Considering projects competition for participants it beneficial for project to have very weak stock app and good opt app - this will attract credit hunters a lot.

From other side, porting back to stock optimizations from opt app is totally unpleasable move considering project credits (although it's very profitable for project science).
Optimisation of stock app itself will lead to change in credit issue rate by project ("fair credit issue rate among other projects" applies here).
While stock users may not notice any RAC change, RAC of opt app users will drop (!). I'm sure opt app users who cares about credits will not be pleased by that.

That is, current credit system is evil but its nature.
It not stimulates progress of stock app but contradict to it.

... or you can think of credits like politicians do with our money - '$1 Trillion, $2 Trillion, pretty soon now you'll be talking real money.'
____________
Cheers,

PeterV

.

... or you can think of credits like politicians do with our money - '$1 Trillion, $2 Trillion, pretty soon now you'll be talking real money.'

To sum it up, if improvements are ported to the stock app, the credits for the stock app will rise, all other ones are unaffected.

I find it hard to believe that some new code is about to be tested
and the only thing people are talking about is credit. I thought I
was donating computer time expecting something in return take away
from the meaning of donating. I will say credit is nice but that
should not be the main reason for donating you time. I think improving
the performance means more than credit.

How about, Thanks Cluster Physik for all your hard work.
____________

Lowering it ~30% will certainly run users off again

Lowering it ~30% will certainly run users off again

It may but there's going to be no mass exodus of Participants. Right now Milkyway has no Competition for the ATI Boys other than Collatz Project which at the moment doesn't compare to Milkyway as far as Credits for the ATI Cards goes.

That may change though soon and if the ATI Credits at Collatz are comparable to Milkyway then you might see a bigger jump of Participants to the Collatze Project since they may pay about the same.

distriubted.net has an ATI app

Speaking of credit...

Raistmer
Joined: Jun 27 09
Credit: 4,157,608
RAC: 45,743

Misfit
Joined: Aug 27 07
Credit: 494,751
RAC: 1,872

So like I said who with millions of credit will notice if the credit is reduced? That's just an extra days worth of crunching out of the year. Of course only the ATI peeps will see huge amounts of credit in just a very short period of time. I think only we non-ATI crunchers will notice the difference.
____________

The following is what I posted on seti@home.. I hope they like it...




Message 932967 - Posted 13 Sep 2009 4:00:18 UTC


Last modified: 13 Sep 2009 4:01:50 UTC

Ok now that the politics has landed on the Milky way project to make them bring their project more in line with projects like SETI. Where is the ATI application on SETI so that I can get a copy to use? I mean come on I want to use it to compare with Milky Way project.

Maybe I am mistaken and maybe SETI does not have one for this project. If not why would you bully other projects to conform to something that you don't have here. Just think about that one..

Heck you can't even keep this project running for more that two days.

SM..
____________
____________

But at seti every day is tuesday. :)
Search astrafamily for explanation.
____________
Cheers,

PeterV

.

Speaking of credit...

Raistmer
Joined: Jun 27 09
Credit: 4,157,608
RAC: 45,743

Misfit
Joined: Aug 27 07
Credit: 494,751
RAC: 1,872

So like I said who with millions of credit will notice if the credit is reduced? That's just an extra days worth of crunching out of the year. Of course only the ATI peeps will see huge amounts of credit in just a very short period of time. I think only we non-ATI crunchers will notice the difference.

I don't have anything to lose with credit being dropped. <smile>

Credit history comparisons can really only be compared between similar types of work units. Multiple trendlines can be created (cropped between credit/application/workunit changes) which shows progress clearer than examining or comparing histories of two users or projects.

Are cobblestones flawed? Maybe, but anything else that is substituted in will be just as flawed when you compare projects. FLOP comparison will never work.

There does not exist a universal currency between projects. Perhaps we should setup a credit exchange program?

If cobblestones are flawed then what is the use of milestones?
____________
A BLAST FROM YOUR PAST

I don't have anything to lose with credit being dropped. <smile>

The problem with jerking granted credit around is that new users can't be compared to older users. Instead of focusing so much on BOINC-wide values, David Anderson and the BOINC projects as a whole should totally give up on any and all ideas about making Alberts = ETs = ClimateCycles = ABCs = Cosmos = MilkyWays and just freeze BOINC-wide standings as they are today and let the stat sites come up with their own metrics, much like BOINCStats has the "World Cup" points... The cobblestone system is so hopelessly flawed in implementation that with all of the ups and downs over the years, current rankings are really meaningless from a historical standpoint, only having importance for the here and now...until the next change in the NPV of the "cobblestone".

Milkyway should add a counter for counting done Workunits - to compare users

Milkyway should add a counter for counting done Workunits - to compare users

Milkyway should add a counter for counting done Workunits - to compare users

Ahhh -

This thread explains why I have seen such a huge drop in credit.. I was just about ready to start looking for crashed boxes. But it now appears that the project staff decided to cave in and go back on their word about not lowering the credit.
Go figure.
____________
.

The following is what I posted on seti@home.. I hope they like it...




Message 932967 - Posted 13 Sep 2009 4:00:18 UTC


Last modified: 13 Sep 2009 4:01:50 UTC

Ok now that the politics has landed on the Milky way project to make them bring their project more in line with projects like SETI. Where is the ATI application on SETI so that I can get a copy to use? I mean come on I want to use it to compare with Milky Way project.

Maybe I am mistaken and maybe SETI does not have one for this project. If not why would you bully other projects to conform to something that you don't have here. Just think about that one..

Heck you can't even keep this project running for more that two days.

SM..
____________

Milkyway should add a counter for counting done Workunits - to compare users

If cobblestones are flawed then what is the use of milestones?

I basically agree that the whole comparison is flawed because someone decides that my I7 has to be the same as some 386 way back when (still ignores the 3 other cores and 4 hyperthreads). If you are going to do that then you have to counter the increased performance due mainly to CPU changes but also code or compiler changes. Personally I think GPU credits should be counted as a different from CPU partly do with to the technology but also the projects that use them.

My goals are more within a project than across them. I choose projects I am interested or in the case of GPU's something that can use it. I would do more GPUGRID but I really not appreciate the long run times with short deadlines.

Boincstats has it cup points but it is also flawed especially compared to projects that do not have continuous work. Also you have to allow those computers that are not working 24/7.

If cobblestones are flawed then what is the use of milestones?

I wish they'd use headstones on the idea of cross-project comparisons and let the rankings in each project be totally separate from one another. If this is done, "milestones" in individual projects would actually mean something. As it is now, if I did 100,000 tasks to get 1,000,000 credits (10 credits each), with credit lowering always in play, someone will have to have done MORE work for the same apparent ranking / work done metric.

What I've been in favor of for several years now is just letting each project set their own credit with BOINC no longer supporting any kind of cross-project rankings at all. If 3rd party statistics sites wish to come up with their own scheme, that's fine. It would be 3rd party and not BOINC. We could basically just go down to 1 credit for 1 completed task. If a different project decided it wanted to award 1 trillion credits for 1 completed task, that would be fine as well, since it is confined to that project and that project alone. Projects could say that there is not any intention of comparing the work done in their project vs. work done in another project and that users can take up their complaints about any cross-project comparisons with the 3rd party stat sites. This means the project staff is freed up and the BOINC staff can concentrate solely on improving the software in tangible terms, not intangible scoring metrics.

In other words, it is the attempt to equate the work done that is the root problem. If no effort is made to equate work between projects, this "problem" that the BOINC administration created would instantly be solved.

Looks as though Milkyway@Home has installed the "Restrictor Plate"(NASCAR Racing Reference) again in order to slow all of us down again. I'll be back when the pastures are greener again. Now if they would pay part of my electric bill each month then lowering the credit wouldn't be a problem, but since they don't I look to get the most bang for the "Proverbial" buck ($$$). You can't compare one project with another since the science, goals, and scientific formulas are vastly different. It's like pricing apples and peanuts, they are completely different.
____________

I have since put some machines on the seti@home project. It is my hopes that they find a smarter group of scientists out in space who will understand common sense.

And also common curtsy about using other folks equipment.

Like informing the host of credit changes far in advance before doing it. Thus giving the owner of the computer the option of pulling his machine off of that project sooner if they choose to do so.

I do remember a while back when Travis made the statement that he was following DA's formula for credits compared to cpu one, and now he has lied and gone and changed his world.

Go figure. Do you learn that sort of tactics at his university of DA?

SM...
____________

OK people, lets just please simmer down here a little bit. I really do see no point in getting all uptight about it. If you think that the credits awarded here are not to your liking, then you obviously have the option to go and crunch for another Boinc project instead.

If you feel as I do, that the project here is worth while supporting, then the credits awarded are secondary. Boinc has always had credit hounds, they come, they make a noise, and they go. Yadda yadda yadda .....

@ Starman - Hope you stay with Sicituradastra :-)
____________
Don't drink water, that's the stuff that rusts pipes

This concerns me. I am trying hard to get into thye BOINC top 100. I stand at 106 currently. Credits are not secondary. They may be for you, but they may not be for others. Thwarting achievements by manipulating credits - well, you may as well thwart continuing interest to participate in this or any project.

With respect, I join those sounding concern about the credit reductions and hope to hear what the project has to say about it soon.
____________

Others lost credit too so your place in top 100 will not change much.
If only your credit was lwered it would be different situation ;)

Others lost credit too so your place in top 100 will not change much.
If only your credit was lwered it would be different situation ;)

Others lost credit too so your place in top 100 will not change much.
If only your credit was lwered it would be different situation ;)

According to recent stats MW was biggest credit generator, so my assumption has some sence ;)

According to recent stats MW was biggest credit generator, so my assumption has some sence ;)

I would suggest to stop bitching about the lower credits. Just use the new 0.20 ATI version and your credits/day will be back to the values before the reduction or maybe even slightly higher :D

MW can afford to have "parity" with SETI ;)

Well, ok, I didn't check top 100 actually so I'm wrong in that part.
Still think that separate metric for each project would be much better thing.
It enables much more fair competition w/o such troubles that discussed in this thread...
Wish you to be in top 100 (or top 10, who knows ;) ) among MW crunchers :) Total credits just fiction.
They were changed many times in SETI project , they changed here and do doubts will be changed somewhere else...

The main purpose for enabling credits at all was to add some competition, sporting interest and fun.

Current credit management contradicts this purpose IMHO. And no only in MW.

I would suggest to stop bitching about the lower credits. Just use the new 0.20 ATI version and your credits/day will be back to the values before the reduction or maybe even slightly higher :D

MW can afford to have "parity" with SETI ;)

And I repeat - SSDD

Just got to look back at all the 100s (1000s?) of forum posts about credit here @ MW. Trav decides that the project is getting too much flak from DA & the other BOINC projects, so he trims the credits by 1/3.

Old story, same conclusion. At the end of the day, as has already been said here, it's impossible to compare one project's credits to another's. Chalk and cheese!

The only thing that gets me a little riled up, is the lack of discussion BEFORE the credit adjustment. As Ice says, he's got personal goals based on this project, and it's US who actually do the crunching - therefore, why doesn't the admin here give us space to express OUR opinions before making important decisions?

I know this has all been talked about many times. It just seems as though it's fallen on deaf ears...

Just my 2 EuroCents....
____________
Seejay **Proud Member and Founder of BOINC Team Allprojectstats.com**

Double post - sorry

The only thing that gets me a little riled up, is the lack of discussion BEFORE the credit adjustment.

So what is the result? One can now point every cross project parity fanatic to the credit multiplier matching the equivalent value of SETI by saying MW gets high credits on ATIs just because they are so much faster! Furthermore nothing has changed to the worse here, quite to the contrary. The app is now delivering better results even faster than before.

;-) ..with my current computer I do more science by reading
your posts than by crunching WU`s.. ;-D So please continue to
discuss what ever you may think of. lol
____________

I would suggest to stop bitching about the lower credits. Just use the new 0.20 ATI version and your credits/day will be back to the values before the reduction or maybe even slightly higher :D

MW can afford to have "parity" with SETI ;)

I would suggest to stop bitching about the lower credits. Just use the new 0.20 ATI version and your credits/day will be back to the values before the reduction or maybe even slightly higher :D

I have put two machines on it now and we will see tomorrow what kind of a daily I get before I speculate any of loss or gain with the new and improved v. 2.


____________

I would suggest to stop bitching about the lower credits. Just use the new 0.20 ATI version and your credits/day will be back to the values before the reduction or maybe even slightly higher :D

MW can afford to have "parity" with SETI ;)

If you go to the optimize web site there is one for the non gpu..
http://www.arkayn.us/milkyway/index.html

OK?
____________

Are the new 64 SEE 3 faster than the old 19 SEE 4.1, and are the new 20 SEE 3 faster than the old 19 SEE 3?

because my RAC is dropping like a rock and I know other projects would give me more.... just a little pissed that the ATI thing has effected the CPU only crowd... I believe we were here first, and are now being treated like someones old gum that I stepped in walking down the street on a hot day.. ewwwww

Are the new 64 SEE 3 faster than the old 19 SEE 4.1, and are the new 20 SEE 3 faster than the old 19 SEE 3?

because my RAC is dropping like a rock and I know other projects would give me more.... just a little pissed that the ATI thing has effected the CPU only crowd... I believe we were here first, and are now being treated like someones old gum that I stepped in walking down the street on a hot day.. ewwwww

Last night, latish, I swapped my CPU only rig from the opti client 0.19 to 0.20.

It looks like the new client is faster.

But, I an getting zero credit awarded as this example of the results shows.
____________
Go away, I was asleep

Are the new 64 SEE 3 faster than the old 19 SEE 4.1, and are the new 20 SEE 3 faster than the old 19 SEE 3?

Double post ... delete please

Last night, latish, I swapped my CPU only rig from the opti client 0.19 to 0.20.

It looks like the new client is faster.

But, I an getting zero credit awarded as this example of the results shows.

I'm taking a look at the server right now and seeing what's up with the WUs that are being flagged as invalid. Hopefully I can get it sorted out soon.

The only thing that gets me a little riled up, is the lack of discussion BEFORE the credit adjustment.

If that is any relief to you, I have discussed with Travis about that reduction. I think it is pure concidence that the reduction is completely compensated by the new ATI version ;)

So what is the result? One can now point every cross project parity fanatic to the credit multiplier matching the equivalent value of SETI by saying MW gets high credits on ATIs just because they are so much faster! Furthermore nothing has changed to the worse here, quite to the contrary. The app is now delivering better results even faster than before.

;-) ..with my current computer I do more science by reading
your posts than by crunching WU`s.. ;-D So please continue to
discuss what ever you may think of. lol

The only thing that gets me a little riled up, is the lack of discussion BEFORE the credit adjustment. As Ice says, he's got personal goals based on this project, and it's US who actually do the crunching - therefore, why doesn't the admin here give us space to express OUR opinions before making important decisions?

Actually, if you were following the news posts, a month or so ago I did post that we would be lowering credits sometime in the near future. No one just got up and complained about it until I actually did the lowering.

If you look at previous news posts, on July 21st:

July 21, 2009
I'll be updating the server daemons tonight with better result verification and updated particle swarm and genetic searches. There will probably be some downtime while I get everything up and running correctly. We've also been examining some issues we're having with our fitness calculation, so we'll be releasing a new application and its code to deal with that as well. It also seems we're having some excessive credit issues again so things are going to have to be tweaked (have fun flaming our forums :P).

So it's not really fair to say I didn't warn you. You had over a month to gripe about it :)

Last night, latish, I swapped my CPU only rig from the opti client 0.19 to 0.20.

It looks like the new client is faster.

But, I an getting zero credit awarded as this example of the results shows.

I'm taking a look at the server right now and seeing what's up with the WUs that are being flagged as invalid. Hopefully I can get it sorted out soon.

Travis Tweaks with a sledge hammer
____________

To go back to the the same RAC you had before the sledgehammer was used, just install the new optimised v0.20 app from CP...OMG, my little 3850 should actually increase its RAC!

Either way MW is still the best CPU paying project around at the moment - maybe only until AQUA gets going again though.

If it makes you guys feel any better, Dave Anderson wanted our credit multiplier to be down to 2.7 (the same as SETI's), but I held my ground on 5.4 for our double precision work :P

Travis Tweaks with a sledge hammer

Just wanted to say hello. I just join MW. I've had a mild interest in the project for some time. The fact that an effort is being made to achieve credit parity is one of the reasons I decide to add the project to my list at this time. My contribution may be miniscule compared to others, but I thought that the effort should be rewarded.
____________
Questions? Answers are in the BOINC Wiki.

Boinc V7.0.27
Win7 i5 3.33G 4GB, GTX470

If it makes you guys feel any better, Dave Anderson wanted our credit multiplier to be down to 2.7 (the same as SETI's), but I held my ground on 5.4 for our double precision work :P

As I've said repeatedly, changing the credit around removes all capability of accurate intra-project metrics between participants. If I started out a year ago and got an average of 50 cr/hr and put in 2000 hours, I'd have 100,000 credits. If someone starts now and averages 25 cr/hr and puts in 2000 hours in the next year, they show as having 50,000 credits. Technically both users put in the same amount of time, but the appearance is that the person with the 100,000 credits "did more work".

You're trying to make credits out to be something like "time spend doing work" when it's really not that simple. Credits are awarded for the amount of work done (100 points = 86400e9 single precision floating-point operations AFAIK). Better hardware makes for better credit rates. Also, the amount of calculation done by the milkyway application has been decreasing over time as it gets more and more optimized. A user can definitely put in more time, but do less work. And in your example, due to the optimizations in the milkyway application, the older user most likely did do more work.

If it makes you guys feel any better, Dave Anderson wanted our credit multiplier to be down to 2.7 (the same as SETI's), but I held my ground on 5.4 for our double precision work :P

Figures, any Project that gives out more Credit than SETI is on DA's Hit list to try and lower them to SETI Standards. But on the other hand they don't try to raise the Projects that give out less than SETI ... Go Figure

I just want to emphasize this:

So what are we doing? We take our stock application, get a general idea of how many flops it will take from the code, (and now after the credit change) we're applying that to the supposedly standard credit multiplier, modified for double precision work.

What do you suggest we should do?

If we never lowered our credit from when the project first came out, each WU would be at about 20,000 credit. That's pretty ridiculous.

look at this..

http://boinc.netsoft-online.com/e107_plugins/boinc/get_cpcs.php
____________

196) Message boards : Number crunching : credit change -- 2/16/2009 (Message 12196)
Posted 205 days ago by Profile Travis

I hope GPU won't be penalized. A crunched WU is worth the same credit whether crunched by stock, optimized or GPU. If you can turn 'em around quicker, you get credits quicker, be it becuase you have a faster machine or a number of machines, or a way of crunching them quicker. And optimized/GPU shouldn't be throttled either IMHO



While the credit for the workunits may go up or down as a whole (right now it may be a little low but I want to see how things work out), the GPU app will get the same amount of credit for a workunit as anything else because they're doing the same amount of work. That's going to be our policy on this one, so you don't have to worry about GPUs being specifically targeted for a credit reduction.

The workunits we're running are a deterministic amount of credit so they will all be awarded the same amount of credit regardless of what's crunching them.
____________

Me thinks that the GPU has been targeted... humm.
____________

Well I guess I might as well throw in my two cents worth in also.

My personal feeling is one of...Why lower the credit? Why not all the other projects raise there's to fall more in line with MW?

I see it somewhat like this...if you have a fast computer with all the bells and whistles, you can crunch a crap load of work in no time at all (figuratively speaking anyway). If you have a slow dog computer, then you get crappy credit for endless hours of work being done. Generally, this is the way it works, which is all good and fine.

What this means to me is that the ratio of credit for all project should (and likely needs to) be standardized based on throughput of WUs vs the amount of time spent on any project. This evens the playing field for everyone for any project.

It also means that because people are credit hungry, some will leave, some will stay. I think people all have a basic competitive nature about them and when they do something, practically anything, that gives them some form of reward, they tend to strive harder and do more to get an edge over others doing the same thing. Tiger Direct knows that I've spent $1200 on a new core-i7 box just for this reason, more credit as fast as possible. There are many people running "farms" of boxes just to try to get to the top of the hill and maybe even take down those Big Guys with a gazillion credits.

My point being with this, is that a lot of people will likely tend to go where ever they can to get the most credit as they can, whether or not they may or may not think the particular project they abandon or join is worthwhile in any other sense.

This may sound as though, those people that are in that competitive mode, are heartless towards anything but the credit. Some may see that as true, but guess what?! Those people that are going for the highest paying credit projects are still doing the favor of (whatever) the project, the crunching to get the work done. And though it may not be MW or SETI, they will find a nitch somewhere that they are happy. With that in mind, it really doesn't matter what project they are doing so long as it makes them happy and the work gets done. The heartless people are the ones that get pissed over everything and quit Boinc altogether because of something like a lowering of credit that just displeases them to no end.

Those people that are credit hungry (like me) also tend to spend money on faster and more computers to get the job done. This is over all a good thing for everyone. It stimulates the economy a little (for, computer purchases, shippers that deliver the computers and you know the electric company just loves it, ISPs aren't complaining either and don't forget the projects are getting worked on more and more because of it) and so it's all a good overall thing I think. If nothing else, you get a kickass computer to play with!!!

Me personally, I like WUs that go fast and don't take FOREVER to do. This is one of the reasons I chose MW as a place to get some work done. I have another box crunching GPUGrids, but to me they are so painfully long and time consuming, I can't bare to even look at the manager screen other than to just simply make sure the project is still running properly. Recently they did a nerf to their project, but not by lowering the credit, but by making the WUs longer. I was pissed, but I didn't leave the project and the work is still getting done.

MW pisses me off with this, but guess what?...I'm still here :)

At least, that's my two cents worth.


Yo-

If we never lowered our credit from when the project first came out, each WU would be at about 20,000 credit. That's pretty ridiculous.

I extreemly doubt that.

Also the amount of data being done per wu is 100's more than initially. Every time a slight or large gain was made in speeding up the app it was credit chop time within days.

I give it another few months and another credit cut will happen

One possibility on a better comparison between projects is to base the credits on each calculation done. It would be a better showing of how much work has been done.

I just want to emphasize this:

So what are we doing? We take our stock application, get a general idea of how many flops it will take from the code, (and now after the credit change) we're applying that to the supposedly standard credit multiplier, modified for double precision work.

What do you suggest we should do?

If we never lowered our credit from when the project first came out, each WU would be at about 20,000 credit. That's pretty ridiculous.

I extreemly doubt that.

I don't.
The current ATI app calculates on a HD4870 about 15,000 times (yes, fifteen thousand times) faster than the old 1.22 version (which was already a bit faster than the very first one) on a 3GHz Core2.
And even the CPU apps got faster by a factor of several hundreds. As the CPU apps still pay roughly the same per day as those old ones (factor of 2 wouldn't matter for the argument), you can think about what the current apps would be worth in those old credits. 20,000 is quite a good guess I think (50 credits now, factor 400 speedup).

Also the amount of data being done per wu is 100's more than initially. Every time a slight or large gain was made in speeding up the app it was credit chop time within days.

All reasons making Travis number of about 20,000 "old credits" more likely, don't you think?

I give it another few months and another credit cut will happen

That may happen if/when new optimizations are implemented, reducing the amount of work necessary to process a WU.

One possibility on a better comparison between projects is to base the credits on each calculation done. It would be a better showing of how much work has been done.

That is a really good idea! Why nobody have thought of it before?
Wait! That's exactly how the credits are derived here at MW (and SETI and GPUGrid, too)!
One FLOP is a floating point operation, i.e. an calculation. For each trillion double precision calculations (1 TeraFlop = 1,000,000,000,000 floating point operations) you get 5.4 credits here. For each trillion single precision operations at SETI or GPUGrid you get 2.7 credits. It is a really simple system!

The operative words from Travis..

That's going to be our policy on this one, so you don't have to worry about GPUs being specifically targeted for a credit reduction.




But they are being targeted. The faster you make them go the more the credits will be lowered.



____________

So what are we doing? We take our stock application, get a general idea of how many flops it will take from the code, (and now after the credit change) we're applying that to the supposedly standard credit multiplier, modified for double precision work.

I have a PM from you from months back that you said your determination for credit was based on the stock MW app as compared to SETI stock app.

Now after some months you have gone back and modified that position.

I propose that the stock app to stock app the credit per hour was nearly the same. Now however, I can only suppose that SETI will be higher.

But really why would you want to compare your credit to SETI? Really? Why? Because that is just the way it is done?
Is this a science project or a DA project? Just asking.

The best thing for all of you that head up the various projects to do is to freeze the current credit system stats and start over with the "1 credit for 1 completed task" methodology, followed by official announcements by all of the projects as well as the BOINC staff that comparing projects is no longer supported by the BOINC platform and that the ONLY rankings that are supported are those within a single project. Each project is its' own entity, sharing only a common software framework. From that point on, if BOINCStats, BOINC Combined Statistics, All Project Stats, Knights Who Say Ni, or any of the other stat sites decide that they want to try to make an exchange system, IT IS ON THEM AND NO LONGER ON YOU, THE PROJECT, TO TRY TO KEEP UP WITH...

But not all of our tasks take the same amount of work (compare 1 stream to 2 stream to 3 stream), does 1 credit for 1 completed task really make sense for that?

I honestly don't know what you want from us. People always complain about credit but never offer any suggestions. I personally don't have a solution.

And contrary to Brian's thought, there is no inherent reason that cross-project parity could not be made a reality. There is just no will to do so.

And contrary to Brian's thought, there is no inherent reason that cross-project parity could not be made a reality. There is just no will to do so.

My point is that it would be such a major undertaking involving so many people that it is just not worth the effort when a far easier option is to remove the comparisons between projects out of anything that BOINC officially supports.

And contrary to Brian's thought, there is no inherent reason that cross-project parity could not be made a reality. There is just no will to do so.

My point is that it would be such a major undertaking involving so many people that it is just not worth the effort when a far easier option is to remove the comparisons between projects out of anything that BOINC officially supports.

Forgive me for being hung up on original design intent. But, cross-project credit parity and accumulation was one of the few original design intents for BOINC. In that the beta site is long gone and I can't find it in any time-machine I cannot demonstrate this well ... but ... one of the main points was to get away from the one credit per task because there are flaws in historical comparisons there too ...

Hmm, yes, well ...

FLOP counts ... well, there are problems there too ...

Which FLOP gets counted how?

Just as an example ... the MW tasks are MW tasks are MW tasks ... yet how many FLOPS does it take? The CPU non-optimized application takes "x" FLOPS, the optimized apps take something less and the GPU apps are in a whole 'nother country ... and you can't necessarily compare apples to peaches there either because if the apps are truly matched to the GPU they will not necessarily have any relationship to each other ...

All I have been saying is that there is no need to jettison the original design intent. Yes, according to your lights it would be justifiable and perhaps worth it. Perhaps just as many of us disagree with your desire. Just because UCB is too lazy to solve the problem and too self-centered and controlling to let others solve issues does not mean the problem is unsolvable ...

In your approach no one would be able to trust the system either and the accounting and conversions would become another nightmare that is as unneeded as a facebook interface to BOINC...

And just because you don't use the current system (flawed as it is) to measure and contrast progress vis a vis various projects does not mean others do not ... flawed as they are the stats are still the only tool I have to help me decide allocations of work effort amongst the projects... I grant you that the fact that the system is so flawed and that there is no interest in fixing it does not help, but, it is the only yardstick I have ... so it is the one I will use ...

So, I see the trees of the 50+ projects I contribute too, and I look at the forest even though it is on fire ... so I could suggest that you do the same looking for the forest instead of only looking at the leaf on one tree ... :)

Another adage that comes to mind is about babys and bath water ... though I have to admit that the bath water has always sounded more attractive to me ...

I will just answer explaining some technical details for the case of MW here.

Hmm, yes, well ...

FLOP counts ... well, there are problems there too ...

Which FLOP gets counted how?

Just as an example ... the MW tasks are MW tasks are MW tasks ... yet how many FLOPS does it take? The CPU non-optimized application takes "x" FLOPS, the optimized apps take something less and the GPU apps are in a whole 'nother country ... and you can't necessarily compare apples to peaches there either because if the apps are truly matched to the GPU they will not necessarily have any relationship to each other ...

Tested the CPU version 0.20_X87 against 0.19_SSE on MP2200:

0.19_SSE - 3h 35m
0.20_X87 ~ 7h (stopped after 42m at 10%)

Back to 0.19_SSE
Any chance for a 0.20_SSE that runs in the time range of the 0.19_SSE?

Top-posting this, because it's no use in going point-by-point....

As I said, you complain about being so readily dismissed, yet your post is just sweeping aside nearly everything I said very quickly and without much thought... Perhaps CPs explaination of how things are tightly grouped together here will help, or perhaps not...

I would suggest that David Anderson isn't the only one who isn't open to new ideas... Instead of babies and bathwater, it seems as though someone is willing to go down with the sinking ship...

Hmm, yes, well ...

FLOP counts ... well, there are problems there too ...

Which FLOP gets counted how?

Just as an example ... the MW tasks are MW tasks are MW tasks ... yet how many FLOPS does it take? The CPU non-optimized application takes "x" FLOPS, the optimized apps take something less and the GPU apps are in a whole 'nother country ... and you can't necessarily compare apples to peaches there either because if the apps are truly matched to the GPU they will not necessarily have any relationship to each other ...

All I have been saying is that there is no need to jettison the original design intent. Yes, according to your lights it would be justifiable and perhaps worth it. Perhaps just as many of us disagree with your desire. Just because UCB is too lazy to solve the problem and too self-centered and controlling to let others solve issues does not mean the problem is unsolvable ...

In your approach no one would be able to trust the system either and the accounting and conversions would become another nightmare that is as unneeded as a facebook interface to BOINC...

And just because you don't use the current system (flawed as it is) to measure and contrast progress vis a vis various projects does not mean others do not ... flawed as they are the stats are still the only tool I have to help me decide allocations of work effort amongst the projects... I grant you that the fact that the system is so flawed and that there is no interest in fixing it does not help, but, it is the only yardstick I have ... so it is the one I will use ...

So, I see the trees of the 50+ projects I contribute too, and I look at the forest even though it is on fire ... so I could suggest that you do the same looking for the forest instead of only looking at the leaf on one tree ... :)

Another adage that comes to mind is about babys and bath water ... though I have to admit that the bath water has always sounded more attractive to me ...

Tested the CPU version 0.20_X87 against 0.19_SSE on MP2200:

0.19_SSE - 3h 35m
0.20_X87 ~ 7h (stopped after 42m at 10%)

Back to 0.19_SSE
Any chance for a 0.20_SSE that runs in the time range of the 0.19_SSE?

Top-posting this, because it's no use in going point-by-point....

As I said, you complain about being so readily dismissed, yet your post is just sweeping aside nearly everything I said very quickly and without much thought... Perhaps CPs explaination of how things are tightly grouped together here will help, or perhaps not...

I would suggest that David Anderson isn't the only one who isn't open to new ideas... Instead of babies and bathwater, it seems as though someone is willing to go down with the sinking ship...

Actually, I did find the original design proposal/criteria/transition plan.

A portion (without the formatting, not going to spend the time):

Why is SETI@home switching to BOINC?

Several reasons:
BOINC transparently and securely downloads new application versions. This lets us upgrade and extend SETI@home without requiring you to download and install new software. It will make it easy for us to integrate new algorithms, such as analyzing our 8 bit/sample reobservation data, or looking for other types of radio signals such as short broadband pulses.
BOINC has a more flexible data architecture than SETI@home Classic. Data can be transferred to and from multiple servers, and can remain resident on PC disks. In the future, we'll use these capabilities to search for ET signals in a much larger radio frequency range.
BOINC distributes work based on host parameters. Work units requiring 512 MB of RAM, for example, will only be sent to hosts having at least that much RAM. This lets us use BOINC for a wider range of computations than the 'one size fits all' SETI@home Classic.
Other distributed computing projects are also using BOINC, and you can share your computer time among projects of your choosing.
Can I run both versions at once?

No; if you do this, SETI@home/BOINC won't get any CPU time because it runs at a lower priority. You must uninstall SETI@home Classic before running SETI@home/BOINC.

What will happen to my workunit totals?

BOINC projects can have workunits of many different lengths, so BOINC keeps track of your computer's work in terms of actual computation performed rather than number of workunits.

Because of this change, SETI@home accounts will have separate old and new work totals. The old total is the workunit total from the current SETI@home. It won't change, and a section of our web site will show the final leaderboards based on old work totals. New work unit totals will start from zero.

Each project gives you credit for the computations your computers perform for it. BOINC's unit of credit, the Cobblestone 1, is 1/100 day of CPU time on a reference computer that does

1,000 double-precision MIPS based on the Whetstone benchmark.
1,000 VAX MIPS based on the Dhrystone benchmark.
Eventually, credit may reflect network transfer and disk storage as well as computation.
How credit is determined

When your computer completes a result, BOINC determines an amount of claimed credit in one of two ways:
In general, the claimed credit is the result's CPU time multiplied by the CPU benchmarks as measured by the BOINC software. NOTE: the BOINC software is not optimized for specific processors. Its benchmark numbers may be lower than those produced by other programs.
Some applications determine claimed credit themselves, and report it to BOINC. This would be the case, for example, with applications that use graphics coprocessors or other non-CPU hardware.
Claimed credit is reported to a project when your computer communicates with its server. The granted credit that you receive may be different from the claimed credit, and there may be a delay of a few hours or days before it is granted. This is because some BOINC projects grant credit only after results have been validated.

Recent Average Credit

Projects maintains two counts of granted credit:

Total credit: The total number of Cobblestones performed and granted.
Recent average credit: The average number of Cobblestones per day granted recently. This average decreases by a factor of two every week, according to the algorithm given below.
Both quantities (total and recent average) are maintained for each user, host and team.

As best I can see all you are suggesting is a variation of one MW task equals one credit in isolation from all other projects.

BOINC was supposed to be different. Not 50 isolated projects with isolated goals and accounting and random assignments of awards ... but one system where the participant could join multiple projects and would have a fair assignment of award for effort provided regardless of the project to which that effort would be provided.

Just as I am wedded to the original design goal that you should be able to run multiple projects on BOINC; yes, I am wedded to a fair, equitable, and cross-project credit system.

Back to part of your new and improved system your proposal is that the stat sites should be the ones that would create the "exchange" rates ... so now we take unconstrained project awards with multiple multipliers pass the numbers on to multiple stat sites that will each decide how to report and coalesce the values to come up with cross-project equivalence? How does that make things simpler and easier to understand?

Now we also need stat site correction factors because sure as there are little green apples the exchange rates will be different across the stat sites ...

That's no longer the problem of BOINC or the ******SCIENCE PROJECTS*******

When you figure out that I'm sick and tired of scientists trying to mediate squabbles over intangible "warm fuzzy" credit issues, diverting their time and energy away from actual science, let me know...

That's no longer the problem of BOINC or the ******SCIENCE PROJECTS*******

When you figure out that I'm sick and tired of scientists trying to mediate squabbles over intangible "warm fuzzy" credit issues, diverting their time and energy away from actual science, let me know...

And that is the point you miss. You conflate the UCB team as scientists doing research. Heck they are not even researching BOINC and how it works ... Though DA has roots in the scientific community he is no longer acting as a scientist doing research. A critical point you ignore.

You apparently missed the word "or" in my sentence... The remaining part of the sentence referred to, in the case of this project, Travis, Dave, and anyone else at RPI, not the people at UCB. In the case of Einstein, it would be referencing Bruce Allen, Bernd Machenschalk, etc... Only when it came to SETI would it have anything to do with the people at UCB.

Again, dismissing out of hand...

The projects would only be responsible for their own project. The BOINC developers would only be responsible for developing the BOINC software. It does put a bit more responsibility on the projects, as they would need to allocate more database space to house the credit tables, which would include categories such as "cummulative", "Generation 1", "Generation 2", etc... Each time a new application would be released, the project would freeze credit for that generation, reset credit, start a new generation, including figuring out the normalization factor for the current generation so that the cummulative bucket goes up appropriately.

After that, all that is needed is for the projects to issue their statistics dumps like they do today, with whatever modifications are needed to give the statistics sites the ability to come up with the exchange rates for both current and cummulative... If one wanted to go really wild and crazy, projects could also issue dumps for each generation. Stat sites could then provide far greater detail on how a particular individual performed within each credit generation, or just go for the cummulative stats. Cummulative would be the direct equivalent to / replacement of the current BOINC-wide value.

What I'm saying should actually be a statistician's dream, but you're fighting it tooth and nail...

You apparently missed the word "or" in my sentence... The remaining part of the sentence referred to, in the case of this project, Travis, Dave, and anyone else at RPI, not the people at UCB. In the case of Einstein, it would be referencing Bruce Allen, Bernd Machenschalk, etc... Only when it came to SETI would it have anything to do with the people at UCB.

Which are the very people I agree should not be in the business of doing credit nonsense. But the point you did not read is that I don't agree that it should absolve DA and Rom and anyone else core to the development of BOINC ... which is not doing any science at all ... these are the people I am reffering to ... UCB is not SaH and SaH is not UCB ...

Which design you just explain puts burden back on the projects. First for more space, second for updates each and every time they change the application. Not an insignificant burden. Instead of centralizing the credit fix you have just made it a long term maintenance task for each and every project in isolation removing one of the benefits of BOINC, centralized development of the core features ...

What I'm saying should actually be a statistician's dream, but you're fighting it tooth and nail...

In that I am not a statistician, though I like my credit scores as much if not more than the next guy does not mean that I cannot see that this proposal would not help the situation become less complicated and more fair. It would, indeed, likely please some that are super hung up on stats, but the point of BOINC is to bring it into the reach of the common guy ... not stat freaks ...

Frankly, I like you Paul, I really do, but this is starting to sound like you believe that your ideas and your ideas alone are worthy of consideration...

On that note, I will not have anything further to say to you if you respond...so the last word is yours if you wish to take it...

Tested the CPU version 0.20_X87 against 0.19_SSE on MP2200:

0.19_SSE - 3h 35m
0.20_X87 ~ 7h (stopped after 42m at 10%)

Back to 0.19_SSE
Any chance for a 0.20_SSE that runs in the time range of the 0.19_SSE?

Strange thing that. I've tested it only on a Phenom up to now and the 0.20_x87 app is about 19% faster as the old 0.19_SSE variant on this CPU. But I just started it on a AthlonXP 1800+ and the 0.20_x87 really takes twice as long as 0.19_SSE app. Really strange that.
...

...
In the end, that version is ending up 13% faster on the AthlonXP than the old 0.19 version, completely in line with all the other 0.20 compilations. The sacrifice is a tiny bit of accuracy. It still generates the exact same output as all the other versions on the short WUs I used to test it on, so it should be okay. But a slight bitter taste remains, as with larger WUs there could be some (minor) deviations to the output of the other 0.20 versions.

For any one solution to have an effect would take all of the projects (and most likely Boinc staff) to make or add the changes. To me any change could only be in addition to the current system, since many like/want the credits. It would be nice to know in comparison how much actual work was done to compare to other users. The closest thing now is the credits which can be used within a project to have a rough comparison.


credit lowering: I gave a couple wu's a try yesterday. My XP p4 using sse2 went from 80 to 75 min, a 9% increase. It is nice, but doesn't equal the large drop in credits.
____________
Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

this is what i see.first if i was them id what the biggest fastest comp out thier,and anything that slows the wu,s up gets less credit.example,less then 24hr internet time,surfing the net,not dedicated computer,up time,ect.they go from 74,54,39 depending on how much of it is thiers to use.the time it takes to do a wu is not whats its about but the speed it takes to do it,just my opinion.thanks

David Anderson is trying to adhere to something that is fundamentally flawed, and so are you by following him. You people from the project side need to step up and tell him that he's got no clothes on...

-Brian

Frankly, I like you Paul, I really do, but this is starting to sound like you believe that your ideas and your ideas alone are worthy of consideration...

On that note, I will not have anything further to say to you if you respond...so the last word is yours if you wish to take it...

And I have a high regard for you ...

I am saddened that this is your take away ... because I mislike a bad idea of yours suddenly I am the only source of good ideas? Well, so be it ...

It is not that I am the only one with good ideas, it is that this one is not a good idea or a solution.

Historically there have been several proposals to repairing this issue, and there have been several ideas about fixes that I could support, mine with the calibration concepts that addresses more than just the credit problems; the original system, fixed to make it work; and a couple of others that I would have to chase about to nail down the specifics again.

If you do come up with an idea that is worthy of consideration I would be more than happy to support it ... this one just isn't it.

Oh, and I do agree that DA and company should not be trusted with a wet paper bag full of garbage. BUT, like it or not, for the moment DA has a stranglehold on BOINC development. Which is one of the reasons I have been so critical of his "leadership" ... I mean face it, even if your idea was a good one it too would not be implemented even if you wrote the code to make it work ... he would not allow it to be incorporated into the baseline ... I asked and considered writing a rebuttal letter to his latest submission for a grant but I knew in the end that he does not have the intellectual honesty to include such in his package so in the end did not ... but the best thing for the long term health of BOINC would be for it to get out from under his grip ... then the projects would have to cooperate in getting a rational development process ...

So just to chime in here with a question, what is preventing a Fork of the BOINC project itself? If the credit parity and the critical but ignored bugs could be fixed, projects and stat sites could move over to the BBOINC (Better BOINC) project. The grip of DA would be gone and he would be free to be king of his BOINC project and its only citizen. I mean there would have to be a compelling benefit to the science projects to get critical mass. This would be much like a merging of ideas, return to the original ideas of BOINC and remove responsibility from DA.

If I remember correctly, Seti Classic started in 1999, Boinc started in 2002, and Seti migrated to Boinc in 2004. Seti proved to Berkeley that the concept of distributed computing utilising the general public was a viable proposition, and the point of Boinc was to consolidate and build upon that, and develop a common infrastructure for any project to use.

Looking at it from that point of view, as an overall umbrella, Boinc has been quite a success. The problem seems to me to be one of where having proved it all works, the developers seem to have lost interest in the fine tuning to finish it all off.

If I remember correctly, Seti Classic started in 1999, Boinc started in 2002, and Seti migrated to Boinc in 2004. Seti proved to Berkeley that the concept of distributed computing utilising the general public was a viable proposition, and the point of Boinc was to consolidate and build upon that, and develop a common infrastructure for any project to use.

Looking at it from that point of view, as an overall umbrella, Boinc has been quite a success. The problem seems to me to be one of where having proved it all works, the developers seem to have lost interest in the fine tuning to finish it all off.

This could be where the needed improvements in the Boinc Manager will be done and distributed by outside sources such as Crunch3r and others.
____________
Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

This could be where the needed improvements in the Boinc Manager will be done and distributed by outside sources such as Crunch3r and others.

How could UCB stop it from downloading work? As long as the program is project approved i don't see how they could block it.
I may be wrong but i just don't see how. I know they could block it froms SETI which is run by UCB but I don't see all the others. Especially if the program was better developed and maintained
____________

4870 GPU
4870 GPU

This could be where the needed improvements in the Boinc Manager will be done and distributed by outside sources such as Crunch3r and others.

Well, if people developed 3rd party versions of the Boinc Manager in the way you suggest, would Berkeley allow them to download work? Would they be blocked?

I am not saying that it could not be done ... but just as a practical matter you would need 10-20 really good people to make a go of it ... and they would have to be really into it ... it is not just that BOINC is so big, but that there is so much that is messed up ...

I notice now that the current wu's are requesting 11 credits for myself. The ones before this last cut were 7-8 credits. The de_s222 are running the same time with the .20 app. So that means we are now doing even more work for even less credits. So this was a 2-part credit cut without saying that the second part would happen. It would be nice if someone would have the guts to own up to these things before they happened.
____________
Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

I notice now that the current wu's are requesting 11 credits for myself. The ones before this last cut were 7-8 credits. The de_s222 are running the same time with the .20 app. So that means we are now doing even more work for even less credits. So this was a 2-part credit cut without saying that the second part would happen. It would be nice if someone would have the guts to own up to these things before they happened.

Yes -- I pointed that out over there as well.

Don't feel bad... GPU Grid's tasks used to take 6-6:30 with an occasional outlier at 7 some hours ... now the outliers are at 6:30 and many are taking up to 9 hours ... GDF gave a mushy reply when I pointed this out ... so credit deflation marches on ...

Well I see it is not only me that is currently going what the flying F--k.
I got two new cards expecting my credits to go to 220,000-250,000 a day...
Yeah right...
It seems that my two 4850's are going to level off at 80-90K a day and my 4870 is going to be somewhere around 40-45K a day. What the hell, it should be double that...

What the frak happened? If the credits being granted fall in line with the math for the work what is the big deal?

Maybe ALL PROJECTS NEED TO BE TELLING SETI THAT THEY DO NOT RUN OTHER PROJECTS.

All projects have a standard to follow for granting credit. STICK THE HELL TO IT. This is damned ridiculous. Just because people are getting faster computers, and even faster video cards that can crunch does not mean that the slower people can tell the faster ones that they should be getting less credit for doing more work.

If this shit does not change I am done.

You want an idea to base credit on.
Ok fine... the simplist way possible...

You give out a 5000 sec long work unit.
The cruncher gets credit for doing a 5000 second work unit.
The actual time it took the crunchers system to do it does not matter, they still did a 5000 second work unit correct?
The computer that did it in what ever time still gave a valid calculation or response correct? Why should it matter if it was CPU or GPU, or opti-app based?
The project sets the work unit lengths. The projects decide on a value of credit per work unit second.

Is this not the simplest solution for all projects?
They all agree on a baseline of credit for a per work unit second.
So then the projects would be very inclined to create optimized apps. They would grant credit on a work unit length based standard.

Seems pretty damned straight forward and simple to me...
____________

>You give out a 5000 sec long work unit
Try CPDN - 4,000 hour WUs available there.
____________
Cheers,

PeterV

.

>You give out a 5000 sec long work unit
Try CPDN - 4,000 hour WUs available there.

Indeed, if they gave out longer work units the time spent on each by systems relative to each other wouldn't change. The granulity of mutations would change though, but I'm not sure what effect that would have. (the validator would have to let more finished WUs build up on average to generate the larger WUs, but that shouldn't lead to problems as long as it can handle it)

What I'd rather see is them using more advanced methods to analyse the data, though. Precision has been tweaked as much as possible to ensure errors for the current model are minimized - which means the model itself is now the bottleneck. I wonder how much of a difference it would make to look at strips of the sky as strips of a globe instead of a cylinder?

Well I see it is not only me that is currently going what the flying F--k.
I got two new cards expecting my credits to go to 220,000-250,000 a day...
Yeah right...
It seems that my two 4850's are going to level off at 80-90K a day and my 4870 is going to be somewhere around 40-45K a day. What the hell, it should be double that...

What the frak happened? If the credits being granted fall in line with the math for the work what is the big deal?

Maybe ALL PROJECTS NEED TO BE TELLING SETI THAT THEY DO NOT RUN OTHER PROJECTS.

All projects have a standard to follow for granting credit. STICK THE HELL TO IT. This is damned ridiculous. Just because people are getting faster computers, and even faster video cards that can crunch does not mean that the slower people can tell the faster ones that they should be getting less credit for doing more work.

If this shit does not change I am done.

You want an idea to base credit on.
Ok fine... the simplist way possible...

You give out a 5000 sec long work unit.
The cruncher gets credit for doing a 5000 second work unit.
The actual time it took the crunchers system to do it does not matter, they still did a 5000 second work unit correct?
The computer that did it in what ever time still gave a valid calculation or response correct? Why should it matter if it was CPU or GPU, or opti-app based?
The project sets the work unit lengths. The projects decide on a value of credit per work unit second.

Is this not the simplest solution for all projects?
They all agree on a baseline of credit for a per work unit second.
So then the projects would be very inclined to create optimized apps. They would grant credit on a work unit length based standard.

Seems pretty damned straight forward and simple to me...

So move then, Beserk, and stop clogging up this board whingeing about it.
____________
Cheers,

PeterV

.

It's better to stop crunching MW an move to Collatz.

>You give out a 5000 sec long work unit
Try CPDN - 4,000 hour WUs available there.

So move then, Beserk, and stop clogging up this board whingeing about it.

So move then, Beserk, and stop clogging up this board whingeing about it.

i moved on days ago.

So move then, Beserk, and stop clogging up this board whingeing about it.

i moved on days ago.

So move then, Beserk, and stop clogging up this board whingeing about it.

i moved on days ago.

And get even LESS credit. Talk about cutting your nose off to spite you face....go figure.

So move then, Beserk, and stop clogging up this board whingeing about it.

i moved on days ago.

And get even LESS credit. Talk about cutting your nose off to spite you face....go figure.

By utilising CPs latest ap, you are getting MORE credit than you were before.

I still say credit parity across projects for standard apps is a valid goal for the BOINC devs. Yeah it sucked a bit when the credit was reduced, but then within days CP released another app and bingo actual credit per unit time went up!

You really are crying about spilt milk.

By utilising CPs latest ap, you are getting MORE credit than you were before.

By utilising CPs latest ap, you are getting MORE credit than you were before.

Not with the sse2 app, only ~8-9% faster. Good but doesn't compensate.

Fair enough. I wasn't thinking about cpu's. My bad. But it is still more than what you'd get on SETI with a lunatics opt ap.....

By utilising CPs latest ap, you are getting MORE credit than you were before.

Not with the sse2 app, only ~8-9% faster. Good but doesn't compensate.

After a Google search of "how to determine CPU flop count", some time doing research and testing, this was not a consistent way to judge computer performance. With such a wide variance in calculating FLOPS to award credit for work preformed, a slower computer could get more credit than a faster computer. So the best way would be to make all work units the same size, calculate the flops for the work unit and award credit for this calculation. No matter how fast, or slow, the computation was, credit would be the same. This is the best and most fair solution. I think this is being done by some project already. My two cents worth.
____________

After a Google search of "how to determine CPU flop count", some time doing research and testing, this was not a consistent way to judge computer performance. With such a wide variance in calculating FLOPS to award credit for work preformed, a slower computer could get more credit than a faster computer. So the best way would be to make all work units the same size, calculate the flops for the work unit and award credit for this calculation. No matter how fast, or slow, the computation was, credit would be the same. This is the best and most fair solution. I think this is being done by some project already. My two cents worth.

For a scholarly discussion of credits for GPU projects and for those who haven't seen it previously:

http://www.gpugrid.net/forum_thread.php?id=776&nowrap=true#7556

Makes a lot of sense to me.

The hard part is, some projects are not able to make their wu's the same size due to them either finishing early as they've hit a predetermined cut off, or just due to the fact different wu starting parameters give different wu lengths.

After a Google search of "how to determine CPU flop count", some time doing research and testing, this was not a consistent way to judge computer performance. With such a wide variance in calculating FLOPS to award credit for work preformed, a slower computer could get more credit than a faster computer. So the best way would be to make all work units the same size, calculate the flops for the work unit and award credit for this calculation. No matter how fast, or slow, the computation was, credit would be the same. This is the best and most fair solution. I think this is being done by some project already. My two cents worth.

it will give the same amount of credit, independently if it needs only a minute on a GPU or two hours on a CPU.

Perhaps time to upgrade the PII? :)
____________
Cheers,

PeterV

.

Hmmmm...

Very interesting results.... http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=107881&offset=0&show_names=0&state=3
____________
A proud member of the Polish National Team

COME VISIT US at Polish National Team FORUM

Hmmmm...
Very interesting results.... http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=107881&offset=0&show_names=0&state=3

Hmmmm...
Very interesting results.... http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=107881&offset=0&show_names=0&state=3

You are right. "Very interesting" times for two RV 670...

He is running a script that alters the WUs after downloading. He reduces the number of iterations calculated in the WUs resulting in a massive speedup. And I can prove it. I will notify Travis/Anthony of this cheater. In my opinion this guy should be banned.

Hmmmm...
Very interesting results.... http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=107881&offset=0&show_names=0&state=3

You are right. "Very interesting" times for two RV 670...

He is running a script that alters the WUs after downloading. He reduces the number of iterations calculated in the WUs resulting in a massive speedup. And I can prove it. I will notify Travis/Anthony of this cheater. In my opinion this guy should be banned.

He is running a script that alters the WUs after downloading. He reduces the number of iterations calculated in the WUs resulting in a massive speedup. And I can prove it. I will notify Travis/Anthony of this cheater. In my opinion this guy should be banned.

Maybe there could be a validator check to make sure the number of iterations is correct (320?).

Hmmmm...
Very interesting results.... http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=107881&offset=0&show_names=0&state=3

You are right. "Very interesting" times for two RV 670...

He is running a script that alters the WUs after downloading. He reduces the number of iterations calculated in the WUs resulting in a massive speedup. And I can prove it. I will notify Travis/Anthony of this cheater. In my opinion this guy should be banned.

If it is real cheat, he should not only be banned but also it is necessary to get his all points back

WTF, i don't know what is going on....

See this..... :(
http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=71433&offset=0&show_names=0&state=3

Maby BOINC is not reporting correct times.... or maby not....
____________
A proud member of the Polish National Team

COME VISIT US at Polish National Team FORUM

WTF, i don't know what is going on....

See this..... :(
http://milkyway.cs.rpi.edu/milkyway/results.php?hostid=71433&offset=0&show_names=0&state=3

Maby BOINC is not reporting correct times.... or maby not....

If it is real cheat, he should not only be banned but also it is necessary to get his all points back

I think it is rather sad that some people feel it necessary to behave like that, but it is good that they were fairly quickly found out. I'm sure the admins here will deal with it appropriately.

I think it is rather sad that some people feel it necessary to behave like that,

but it is good that they were fairly quickly found out. I'm sure the admins here will deal with it appropriately.

Sometimes it is done not to increase personal and/or team credit but to cause trouble for the target project for a number of different reasons.

Other times the cheating method gets passed from one team member to another and is only used for short periods and/or not in such an extreme form until someone gets too greedy and overdoes it so that it can be much more easily noticed.

Sometimes it is done not to increase personal and/or team credit but to cause trouble for the target project for a number of different reasons.

Other times the cheating method gets passed from one team member to another and is only used for short periods and/or not in such an extreme form until someone gets too greedy and overdoes it so that it can be much more easily noticed.

Looks like they are all hiding computers as well, except for the first user.
____________