Since Poor Boy's thread has been locked, I thought I would discuss WU credits for Milkyway. It seems that if Crunch3r's application is giving valid credit, all that needs to be done is optimize the standard app and reduce the credits awarded. Credits should really be awarded by CPU cycles, so if the app is optimized (meaning if it takes less CPU cycles to do the same WU, less credits would be awarded per WU) This would be bad for people developing optimized apps, but if the app is already optimized it would only stop people from developing apps that truly cheat and gets credits for work they didn't do. I don't care if the credits per WU go down as long as credits per second stay the same or are at least in-line with other BOINC projects. I am not sure if this is feasible, but it seems that if it were a solution it would be the most fair to everyone.

Since Poor Boy's thread has been locked, I thought I would discuss WU credits for Milkyway. It seems that if Crunch3r's application is giving valid credit, all that needs to be done is optimize the standard app and reduce the credits awarded. Credits should really be awarded by CPU cycles, so if the app is optimized (meaning if it takes less CPU cycles to do the same WU, less credits would be awarded per WU) This would be bad for people developing optimized apps, but if the app is already optimized it would only stop people from developing apps that truly cheat and gets credits for work they didn't do. I don't care if the credits per WU go down as long as credits per second stay the same or are at least in-line with other BOINC projects. I am not sure if this is feasible, but it seems that if it were a solution it would be the most fair to everyone.

Neither Nate nor I have the ability (or the time) to do hand coded vectorizations for all the possible platforms out there. It's quite a lot of work and takes a bit of knowhow -- and it's also completely platform dependent.

If people would like to submit them, we'd love to have your input and test them and make them available for everyone.

I really don't mind discussing this, so long as people can keep it civil.

We'll be trying to come up with a nice logarithmic credit granting function so that the fastest crunchers will be getting the most credit, but awarded credit wont become completely meaningless for anyone not running a highly optimized app.

For some discussion, and an example; if the credit awarding scheme was:

max_credit - c1 * log^c2(c3 * compute time)

It's pretty easy to see that the fastest apps will come closest to the max credit per WU, but it will keep our slower users still getting some reasonable amount of credit. I think this is pretty fair for everyone involved. All that really needs to be tweaked are c1, c2 and c3.

---

Actually i think i screwed that function up. Don't hold it up to much scrutiny :P

---

So the faster you crunch, the more you are penalized? I don't like that in the US tax code, and I don't like it in BOINC either.

---

So the faster you crunch, the more you are penalized? I don't like that in the US tax code, and I don't like it in BOINC either.

Sadly we need to have some kind of credit speed limit -- we can keep it the way it is now, with a hard cap, or make it more of a sliding scale. I don't really care either way, but there needs to be some kind of upper limit.

---

So the faster you crunch, the more you are penalized? I don't like that in the US tax code, and I don't like it in BOINC either.

*LOL* So I can sell my new lappy and continue crunching on my oldish P4s??? I hope not...

---

Lovely greetings, Cori

*LOL* So I can sell my new lappy and continue crunching on my oldish P4s??? I hope not...

this whole "speed limit" thing is foolish. trying to inhibit progess never pays off - for noboby.

I really have a hard time understanding why any project would want to penalize people who improve an application to the point that it can do more science in a shorter amount of time. Looks like this will be another project I will have to stay away from once the team project of the month is completed. That is unless the entire team decides to boycott it (which is highly possible). :(

I really have a hard time understanding why any project would want to penalize people who improve an application to the point that it can do more science in a shorter amount of time. Looks like this will be another project I will have to stay away from once the team project of the month is completed. That is unless the entire team decides to boycott it (which is highly possible). :(

Well the problem here is that one application is getting dramatically more credit than the rest of them. i could just keep credit fixed and reduce the amount of credit everyone else is getting by 20-30x. The optimizations Crunch3r did are really for a specific processor, it's not like we can just take his code and it'll work anywhere.

So for the time being, either everyone gets their credit reduced so that the project isn't outputting way too much credit, or we have a speed limit. If everyone was using an optimized app, the amount of credit per WU would be reduced anyways, to keep it in line with what other projects are awarding.

---

*LOL* So I can sell my new lappy and continue crunching on my oldish P4s??? I hope not...

this whole "speed limit" thing is foolish. trying to inhibit progess never pays off - for noboby.

We're not trying to inhibit progress, just keep the awarded credit in line with what other projects are doing.

---

Uff, I really think all this talk about credits etc should come to an end here now, so that the project admins can return to the more important things around MW, and not having to state the same facts over and over again :/

The optimizations Crunch3r did are really for a specific processor, it's not like we can just take his code and it'll work anywhere.

So for the time being, either everyone gets their credit reduced so that the project isn't outputting way too much credit, or we have a speed limit. If everyone was using an optimized app, the amount of credit per WU would be reduced anyways, to keep it in line with what other projects are awarding.

This should say it all, if the optimized application would work for everyone this well, it should have been made public (if it returns usable data for the project) and ofc the credits would have shriked then by a LOT. Some guys really expect to get 260 credits for some minutes of work it looks like :S


Long story short: I think this issue was handled very well, thumbs up Travis!

So we are at the same standstill.


Kind of reminds me of politics putting a ceiling on advancement and improvement.

Ahh well I guess it is what it is, and no matter how valid the science is that is getting done, the credit for doing the science is being limited.


I will leave a single core AMD on it to help my team, but nothing more.

We will see how this goes, if things can change to be fair to those that deserve fairness, then I might come back.

Thanks for the fish.

So we are at the same standstill.


Kind of reminds me of politics putting a ceiling on advancement and improvement.

Ahh well I guess it is what it is, and no matter how valid the science is that is getting done, the credit for doing the science is being limited.


I will leave a single core AMD on it to help my team, but nothing more.

We will see how this goes, if things can change to be fair to those that deserve fairness, then I might come back.

Thanks for the fish.

If you want to provide us with optimised apps for every CPU/OS combination out there or pay Crunch3r to do it for us, feel free. That would be the ideal solution, but we're not living in a perfect world.

So we are at the same standstill.


Kind of reminds me of politics putting a ceiling on advancement and improvement.

Ahh well I guess it is what it is, and no matter how valid the science is that is getting done, the credit for doing the science is being limited.


I will leave a single core AMD on it to help my team, but nothing more.

We will see how this goes, if things can change to be fair to those that deserve fairness, then I might come back.

Thanks for the fish.

Well you know what they say about a good compromise -- it leaves nobody satisfied.

I tried to keep as many people happy as possible, but some people are going to be upset no matter what.

1. The speed limit is fairly higher than the max speed our stock app gets on the fastest machine running the project. This means people who take the time to optimize an app and run it will be getting the most amount of credit from the project, be on the top of the lists and get the limelight for being a fast cruncher. The speed limit also is quite generous in terms of the amount of credit per cpu time, in my opinion and compared to other projects.

2. The average milkyway user doesn't see the credit they've been getting decreased, or have it made meaningless by a couple people running optimized apps getting extreme (like the mountain dew commercials) amounts of credit.

3. We keep the amount of credit our project is awarding in line with what other projects are doing and don't ruffle any feathers or make our project look bad.

Now lets be honest about this being about science -- if it was about the science the optimized code would be openly available so other people with a similar processor could use it and help the project get results faster. As it stands, a couple thousand volunteered hosts are helping the project a whole lot more than a single optimized host; so it's the sciences best interest to keep them happy. Complaining and dropping the project because a host can't get 200+ credit for a few minutes of work doesn't seem to me like science is the issue here.

Additionally, the project really isn't in a phase where optimization is really all that helpful. We're still examining how our searches run with a very heterogeneous variety of hosts, and getting the application to be doing everything it should be correctly. The rate we're getting results at currently is good enough for what we're trying to do. This is still an alpha project, with good reason.

Once we get a good application that is crunching over very large portions of the sky with complicated models (and have it fully debugged) -- then optimization is going to be a lot more important for the science. Right now it's a happy community, getting results back and a reasonable rate, and being able to debug our application on a wide range of platforms.

---

I'm still here. Yay me!

---

me@rescam.org

Additionally, the project really isn't in a phase where optimization is really all that helpful. We're still examining how our searches run with a very heterogeneous variety of hosts, and getting the application to be doing everything it should be correctly. The rate we're getting results at currently is good enough for what we're trying to do. This is still an alpha project, with good reason.

Once we get a good application that is crunching over very large portions of the sky with complicated models (and have it fully debugged) -- then optimization is going to be a lot more important for the science. Right now it's a happy community, getting results back and a reasonable rate, and being able to debug our application on a wide range of platforms.

Thanks Travis, those last paragraphs put it into better perspective.

UncleVom

Well you know what they say about a good compromise -- it leaves nobody satisfied.

I tried to keep as many people happy as possible, but some people are going to be upset no matter what.

1. The speed limit is fairly higher than the max speed our stock app gets on the fastest machine running the project. This means people who take the time to optimize an app and run it will be getting the most amount of credit from the project, be on the top of the lists and get the limelight for being a fast cruncher. The speed limit also is quite generous in terms of the amount of credit per cpu time, in my opinion and compared to other projects.

2. The average milkyway user doesn't see the credit they've been getting decreased, or have it made meaningless by a couple people running optimized apps getting extreme (like the mountain dew commercials) amounts of credit.

3. We keep the amount of credit our project is awarding in line with what other projects are doing and don't ruffle any feathers or make our project look bad.

Now lets be honest about this being about science -- if it was about the science the optimized code would be openly available so other people with a similar processor could use it and help the project get results faster. As it stands, a couple thousand volunteered hosts are helping the project a whole lot more than a single optimized host; so it's the sciences best interest to keep them happy. Complaining and dropping the project because a host can't get 200+ credit for a few minutes of work doesn't seem to me like science is the issue here.

Additionally, the project really isn't in a phase where optimization is really all that helpful. We're still examining how our searches run with a very heterogeneous variety of hosts, and getting the application to be doing everything it should be correctly. The rate we're getting results at currently is good enough for what we're trying to do. This is still an alpha project, with good reason.

Once we get a good application that is crunching over very large portions of the sky with complicated models (and have it fully debugged) -- then optimization is going to be a lot more important for the science. Right now it's a happy community, getting results back and a reasonable rate, and being able to debug our application on a wide range of platforms.

Hmmm...

Well, it seems to me we're losing sight of the forest for the trees here (and running into that oak tree).

The question isn't how fast any given machine can run the application, the question is how much work is in any given task.

For example, for every search my hosts have run, the runtimes for the tasks are very consistent. This implies the amount work contained in them from task to task is very similar.

Therefore, if the basic stock app is using plain vanilla math, then straight BM-T on a host calibrated to the reference computer ought to be able to let you set the basis fairly accurately.

Hosts running optimized should not get a premium just because they can execute the task faster than a host which doesn't have the advanced capabilities can. The amount of work done is the same.

They get their advantage from the fact they can run more tasks in any given time interval.

Alinator

I'm still here. Yay me!

So says I......

I'll be losing a dual core that the son is taking back to college this weekend and I'll have the remaining 3 computers running 1 project each again so that all my projects are getting about equal treatment.

---

We're not trying to inhibit progress, just keep the awarded credit in line with what other projects are doing.

if that's your primary goal and not the progress of your project, you'll also be fine with the kind of progress MW will make in the stats over the next weeks.

too many guys competing in this ass-kicking-contest who shot off their own leg at the knee. you're not the first, you won't be the last.

at least someone can add another trophy to his collection.

Hey I'm late to this talk-fest but where's the optimized application so everyone can use it? Otherwise ban it.

---