LOL ... funny Kevint, I thought you'd be out Editing your Benchmarks Higher at the Non-Fixed Credit projects this early in the Morning ... :)

Already have taken care of that. DA

LOL ... funny Kevint, I thought you'd be out Editing your Benchmarks Higher at the Non-Fixed Credit projects this early in the Morning ... :)

Already have taken care of that. DA

That's what I figured Kevint ... :)

Just an update to everything.

We haven't tested Crunch3r's app -- so I'm not sure if it's even generating correct results. While I think it's great that he's taken the time to compile his own app and client so he can run our project very fast, I can't really approve of the way he's gone about doing this. Especially starting something like this up during summer downtime without talking to any of us here. While Crunch3r might have talked to Dave about this (who is gone working at a summer internship), I didn't hear about this until contacting Crunch3r after all your complaints, and did not receive particularly satisfying information from him.

I'm all for having highly optimized applications and this is something we'd like to work on -- especially once we get the latest version of our application up and running; but having certain users getting extreme amounts of credit with a version of an application that isn't publicly available seems to go against the purpose of BOINC and doesn't seem particularly fair to me. Additionally, If we're going to have optimized applications, Nate and I really need to make sure that they're computing correct results.

At any rate, this has at least shown us one vulnerability of the BOINC system in that anyone can use any application with our project (even if we haven't signed off on it); and use that kind of app maliciously to gain more credit than we intend our project to give out. To address this issue (see the latest news) I've put in an internal speed limit to the projects validator, which limits the amount of credit any host can gain in a given amount of time. This shouldn't effect the vast majority of our users because the speed limit is quite high, and it should keep the amount of credit awarded realistic.

---

That's exactly what I was waiting to hear after reading this long thread, the fact if crunch3r's app is generating correctly validated science results for this project, or just spitting out a bunch of numbers....

It would be great if the project devs could make the time to get some testing done on his app to find out. Want to announce a time-line for testing project dev's?

Just an update to everything.

We haven't tested Crunch3r's app -- so I'm not sure if it's even generating correct results. While I think it's great that he's taken the time to compile his own app and client so he can run our project very fast, I can't really approve of the way he's gone about doing this. Especially starting something like this up during summer downtime without talking to any of us here. While Crunch3r might have talked to Dave about this (who is gone working at a summer internship), I didn't hear about this until contacting Crunch3r after all your complaints, and did not receive particularly satisfying information from him.

I'm all for having highly optimized applications and this is something we'd like to work on -- especially once we get the latest version of our application up and running; but having certain users getting extreme amounts of credit with a version of an application that isn't publicly available seems to go against the purpose of BOINC and doesn't seem particularly fair to me. Additionally, If we're going to have optimized applications, Nate and I really need to make sure that they're computing correct results.

At any rate, this has at least shown us one vulnerability of the BOINC system in that anyone can use any application with our project (even if we haven't signed off on it); and use that kind of app maliciously to gain more credit than we intend our project to give out. To address this issue (see the latest news) I've put in an internal speed limit to the projects validator, which limits the amount of credit any host can gain in a given amount of time. This shouldn't effect the vast majority of our users because the speed limit is quite high, and it should keep the amount of credit awarded realistic.

Misfit and Poorboy.

Please, if you have your differences, I think all the people of the furum will appreciate you will discussed it in private.

Best regards.

Yeah and if he has differences with Crunch3r then he should have kept it in private. But since he'd rather cry like a newborn he doesn't deserve any quarter.

For boycotting a project notice how he's still around. WHAAAAH!

---

me@rescam.org

At any rate, this has at least shown us one vulnerability of the BOINC system in that anyone can use any application with our project (even if we haven't signed off on it); and use that kind of app maliciously to gain more credit than we intend our project to give out. To address this issue (see the latest news) I've put in an internal speed limit to the projects validator, which limits the amount of credit any host can gain in a given amount of time. This shouldn't effect the vast majority of our users because the speed limit is quite high, and it should keep the amount of credit awarded realistic.

To maliciously gain more credit? As long as his results equal the results from non-optimized apps out to whatever decimal point you require the results are equal and valid. I think you are mixing up an optimized client with an optimized app.

---

me@rescam.org

We haven't tested Crunch3r's app -- so I'm not sure if it's even generating correct results.

I thought that's what the validator is for...



mic.

---

mic.

We haven't tested Crunch3r's app -- so I'm not sure if it's even generating correct results.

I thought that's what the validator is for...

mic.

Possibly it just checks to see if the result has been modified.

It should be checked and verified, and if it is found to work that much better/faster than it should be distributed to everyone. The project will benefit by getting that many more results.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

At any rate, this has at least shown us one vulnerability of the BOINC system in that anyone can use any application with our project (even if we haven't signed off on it); and use that kind of app maliciously to gain more credit than we intend our project to give out. To address this issue (see the latest news) I've put in an internal speed limit to the projects validator, which limits the amount of credit any host can gain in a given amount of time. This shouldn't effect the vast majority of our users because the speed limit is quite high, and it should keep the amount of credit awarded realistic.

To maliciously gain more credit? As long as his results equal the results from non-optimized apps out to whatever decimal point you require the results are equal and valid. I think you are mixing up an optimized client with an optimized app.

We don't do any redundancy checking here -- so there's no way for us to know if his results are correct or not. In the future we plan on doing some server-side rechecking of weird looking results, but this isn't a big priority because it doesn't really effect the science we're trying to do.

We really want to stay away from using redundancy because it's really not required (if we get bad results our search methods basically ignore them), and if we even bump redundancy up to 2, we're basically halving the amount of work that gets done, and doubling the time it takes to get results.

Optimized applications are great in my opinion -- if you guys can get our work done faster thats great. But when they're being used to generate way more credit than this project (or any other one) should be giving out that's something we need to address. My fix doesn't prevent people from making their own optimized versions of the milkyway code, it just prevents them from getting way too much credit from them.

The next version of the astronomy code will be open to the public so you guys will be able to optimize it all you want, and hopefully we can work together on making it faster. Optimization isn't really my specialty so it's something we'll need community help on.

---

We haven't tested Crunch3r's app -- so I'm not sure if it's even generating correct results.

I thought that's what the validator is for...

mic.

Possibly it just checks to see if the result has been modified.

It should be checked and verified, and if it is found to work that much better/faster than it should be distributed to everyone. The project will benefit by getting that many more results.

If we knew the correct answer for a workunit before we sent it out -- there wouldn't be any reason for you guys to crunch it now would there?

Other projects use redundancy to make sure if the result from a WU is correct -- but we really want to avoid this due to the major overhead it incurs. Our validator checks to see if the WU is in the right ballpark for what a result should be; it can't check to see if it's exactly right. The search methods we use naturally remove incorrect or bad results, so redundancy is overkill.

---

We don't do any redundancy checking here -- so there's no way for us to know if his results are correct or not. In the future we plan on doing some server-side rechecking of weird looking results, but this isn't a big priority because it doesn't really effect the science we're trying to do.

So anyone can pump in whatever looks like a result and get credit for it??

We really want to stay away from using redundancy because it's really not required (if we get bad results our search methods basically ignore them), and if we even bump redundancy up to 2, we're basically halving the amount of work that gets done, and doubling the time it takes to get results.

using redundancy + using Crunch3r's code still makes at least 5x more science done.
(given the results are valid)

---

mic.

We don't do any redundancy checking here -- so there's no way for us to know if his results are correct or not. In the future we plan on doing some server-side rechecking of weird looking results, but this isn't a big priority because it doesn't really effect the science we're trying to do.

So anyone can pump in whatever looks like a result and get credit for it??

If they want to waste their CPU cycles doing nothing, I guess that's their prerogative. It wont hurt the science, but it won't help it either. Why even bother signing up for BOINC then? The credit monopoly money? However, with the new changes they won't be getting excessive amounts of credit for it.

We really want to stay away from using redundancy because it's really not required (if we get bad results our search methods basically ignore them), and if we even bump redundancy up to 2, we're basically halving the amount of work that gets done, and doubling the time it takes to get results.

using redundancy + using Crunch3r's code still makes at least 5x more science done.
(given the results are valid)

Or we could use optimized apps and get 10x science done. Either way, the focus right now isn't to get the apps running as fast as possible - we're still working on the next iteration of the application which will allow us to get more science done and model more complicated pieces of the galaxy. We'd rather have the code doing what it's supposed to be doing then optimize it, then spend time optimizing old code which will just be thrown out in the next version of the application. There's only two of us working on the code right now (Nate and myself), and there are only so many hours in the day; so we have to prioritize.

That being said, in the next week or so we should have a new application out (it would have been sooner but I had to deal with this mess), and it will be openly available for everyone to optimize if they want to. Hopefully if people do that they'll share their work with us so we can make it freely available to everyone and test it to make sure it's running correctly.

---

We don't do any redundancy checking here -- so there's no way for us to know if his results are correct or not. In the future we plan on doing some server-side rechecking of weird looking results, but this isn't a big priority because it doesn't really effect the science we're trying to do.

So anyone can pump in whatever looks like a result and get credit for it??

If they want to waste their CPU cycles doing nothing, I guess that's their prerogative. It wont hurt the science, but it won't help it either. Why even bother signing up for BOINC then? The credit monopoly money? However, with the new changes they won't be getting excessive amounts of credit for it.

We really want to stay away from using redundancy because it's really not required (if we get bad results our search methods basically ignore them), and if we even bump redundancy up to 2, we're basically halving the amount of work that gets done, and doubling the time it takes to get results.

using redundancy + using Crunch3r's code still makes at least 5x more science done.
(given the results are valid)

Or we could use optimized apps and get 10x science done. Either way, the focus right now isn't to get the apps running as fast as possible - we're still working on the next iteration of the application which will allow us to get more science done and model more complicated pieces of the galaxy. We'd rather have the code doing what it's supposed to be doing then optimize it, then spend time optimizing old code which will just be thrown out in the next version of the application. There's only two of us working on the code right now (Nate and myself), and there are only so many hours in the day; so we have to prioritize.

That being said, in the next week or so we should have a new application out (it would have been sooner but I had to deal with this mess), and it will be openly available for everyone to optimize if they want to. Hopefully if people do that they'll share their work with us so we can make it freely available to everyone and test it to make sure it's running correctly.

Thank-you Travis for this important information....IMHO your comments are the only thing worthwhile in this whole thread :D

Thank-you Travis for this important information....IMHO your comments are the only thing worthwhile in this whole thread :D

Which of course means that even this last posting of yours is not worthwhile... :D :D :D

Chuckling regards
Rod

Thank-you Travis for this important information....IMHO your comments are the only thing worthwhile in this whole thread :D

Which of course means that even this last posting of yours is not worthwhile... :D :D :D

Chuckling regards
Rod

But our posts are because his opinion only covered up to his posting.

---

me@rescam.org

Hopefully if people do that they'll share their work with us so we can make it freely available to everyone and test it to make sure it's running correctly.

..but if not there's the danger of not getting any good results at all - except from those running the stock app.

I don't think that steamroller tactics with not giving out too much credit via a validator restriction is future-proof.
I think some validation mechanism should be established - it does not make sense to hand out credit for work which is worthless for science.

If you don't want redunancy, what about somehow putting some kind of signature to approved apps (and their results)...?

---

mic.

Optimized applications are great in my opinion -- if you guys can get our work done faster thats great. But when they're being used to generate way more credit than this project (or any other one) should be giving out that's something we need to address. My fix doesn't prevent people from making their own optimized versions of the milkyway code, it just prevents them from getting way too much credit from them.

That statement is completely baffling to me.

1 job in 10 minutes awarding 1 point total

10 jobs in 10 minutes awarding 10 points total

The second example is in no way "too much", as both award at exactly the same rate! Or are you saying that Crunch3r's app is awarded credit at a higher rate somehow?

---

We haven't tested Crunch3r's app -- so I'm not sure if it's even generating correct results. While I think it's great that he's taken the time to compile his own app and client so he can run our project very fast, I can't really approve of the way he's gone about doing this.

Now that would be a problem. Not having your system set up with check's and balances to prove a valid WU, and that valid science is being done. I would hope that the work that is being done by Crunch3r's app is valid and if it is - then your limiting the amount of work a host can do in one day is not valid, and certainly not scientific.

I'm all for having highly optimized applications and this is something we'd like to work on -- especially once we get the latest version of our application up and running; but having certain users getting extreme amounts of credit with a version of an application that isn't publicly available seems to go against the purpose of BOINC and doesn't seem particularly fair to me.

BOINC = the second word = OPEN. That would mean that the source code "should" be open. I know there are some projects that don't have open source, but if you do, and if you plan on doing so, then what would prohibit some smart programmer dude to optimize your app to run a valid WU in 2 seconds, return a valid result, do valid science. Should this person not get credit for his work? Why is this "unfair"? Unfair because he spent the time and energy to find an easier quicker way to do the same amount of work? This would be like saying that Jet travel is unfair because it is not a horse and carriage.

Additionally, If we're going to have optimized applications, Nate and I really need to make sure that they're computing correct results.

True and correct.

At any rate, this has at least shown us one vulnerability of the BOINC system in that anyone can use any application with our project (even if we haven't signed off on it);

This is a the projects failing for not having to proper checks and balances built in the system. But again, if it "is" producing valid science, then why are you being un-scientific and limiting it? Bah!

To address this issue (see the latest news) I've put in an internal speed limit to the projects validator, which limits the amount of credit any host can gain in a given amount of time. This shouldn't effect the vast majority of our users because the speed limit is quite high, and it should keep the amount of credit awarded realistic.

Go ahead, and put training wheels on an F16 Fighter Jet. Limiting the amount of credit a host producing valid science is - errr, scientific. Is it? Neither is it fair.

From what I have gathered from this thread, there are only a very very few.... like 1 participant that has really openly complained, most here are supporting what Crunch3r has done. And most don't really care. If Crunch3r's optimized app is producing valid science, I really don't see the point in limiting his contributions.





And,,, Travis - while you are at it why not let us know what restrictive made up value you have placed on what a host can claim. At least this way I will know what slow boxes to attach to your project and keep the faster boxes on projects that don't adhere to this type of (cough cough) science?

We haven't tested Crunch3r's app -- so I'm not sure if it's even generating correct results. While I think it's great that he's taken the time to compile his own app and client so he can run our project very fast, I can't really approve of the way he's gone about doing this.

Now that would be a problem. Not having your system set up with check's and balances to prove a valid WU, and that valid science is being done. I would hope that the work that is being done by Crunch3r's app is valid and if it is - then your limiting the amount of work a host can do in one day is not valid, and certainly not scientific.

Here's the thing -- I could spend the rest of my PhD thesis trying to come up with a "foolproof" method to make sure people are giving us correct answers, or I could work on the milkyway@home project. No matter how much time i put into trying to make sure everyone is playing fair, someones going to figure out a way around it. I'd rather spend my time doing the science that the project is for, to be honest. The problem was that a certain computer was being awarded 200+ credits for 3 minutes of work. This is extremely excessive and more than we want the project to be putting out to anyone. It makes the project look bad and belittles what the rest of you all are doing.

I'm all for having highly optimized applications and this is something we'd like to work on -- especially once we get the latest version of our application up and running; but having certain users getting extreme amounts of credit with a version of an application that isn't publicly available seems to go against the purpose of BOINC and doesn't seem particularly fair to me.

BOINC = the second word = OPEN. That would mean that the source code "should" be open. I know there are some projects that don't have open source, but if you do, and if you plan on doing so, then what would prohibit some smart programmer dude to optimize your app to run a valid WU in 2 seconds, return a valid result, do valid science. Should this person not get credit for his work? Why is this "unfair"? Unfair because he spent the time and energy to find an easier quicker way to do the same amount of work? This would be like saying that Jet travel is unfair because it is not a horse and carriage.

That person should be getting credit, however there should some kind of upper limit to the amount of credit any host should get over any period of time, to make credit have any value at all. The problem here was that a certain machine was getting FAR too much credit than should be awarded. In fact, the results are coming back so fast I have serious doubts about their validity.

At any rate, this has at least shown us one vulnerability of the BOINC system in that anyone can use any application with our project (even if we haven't signed off on it);

This is a the projects failing for not having to proper checks and balances built in the system. But again, if it "is" producing valid science, then why are you being un-scientific and limiting it? Bah!

This is really an issue with BOINC (or any open computing platform). If you have a real solution for it feel free to go get a few PhDs.

The fact of the matter is, one or two bad eggs out there really isn't limiting the science we're doing -- it really doesn't have any effect because bad results are naturally filtered out by what we're doing. The only real problem arises in terms of credit being awarded for fake work. If people really want to spend that much time trying to break our system and get credit for whatever reason, they can go right ahead. This is a volunteer computing project, so i'm hoping most people are here because they find the science we're doing interesting and would like to help make the most accurate map of the milkyway galaxy possible. I really don't want to waste my time on the bad guys out there when the rest of people would hopefully rather see some real and good science being done here.

To address this issue (see the latest news) I've put in an internal speed limit to the projects validator, which limits the amount of credit any host can gain in a given amount of time. This shouldn't effect the vast majority of our users because the speed limit is quite high, and it should keep the amount of credit awarded realistic.

Go ahead, and put training wheels on an F16 Fighter Jet. Limiting the amount of credit a host producing valid science is - errr, scientific. Is it? Neither is it fair.

From what I have gathered from this thread, there are only a very very few.... like 1 participant that has really openly complained, most here are supporting what Crunch3r has done. And most don't really care. If Crunch3r's optimized app is producing valid science, I really don't see the point in limiting his contributions.

The speed limit on credit doesn't limit his contributions, he can still use his optimized app and our assimilator will still use his results. The only thing it limits is the excessive amount of credit being awarded, and in this case it really was pretty extreme and more credit than we want the project to be awarding. Like i said before, it makes the project look bad, and belittles the CPU time the rest of you are putting onto the project.

And,,, Travis - while you are at it why not let us know what restrictive made up value you have placed on what a host can claim. At least this way I will know what slow boxes to attach to your project and keep the faster boxes on projects that don't adhere to this type of (cough cough) science?

The speed limit is very high -- none of you should see any effect. It's around the neighborhood of 3 credit per cpu minute per workunit.

---

Optimized applications are great in my opinion -- if you guys can get our work done faster thats great. But when they're being used to generate way more credit than this project (or any other one) should be giving out that's something we need to address. My fix doesn't prevent people from making their own optimized versions of the milkyway code, it just prevents them from getting way too much credit from them.

That statement is completely baffling to me.

1 job in 10 minutes awarding 1 point total

10 jobs in 10 minutes awarding 10 points total

The second example is in no way "too much", as both award at exactly the same rate! Or are you saying that Crunch3r's app is awarded credit at a higher rate somehow?

There are two problems:

1. We haven't tested his app to make sure the results are correct.

2. He was getting something along the lines of 200+ credit for around 3-4 minutes of work.

The problems with the first are obvious and if you don't think the second has anything fishy about it... well i don't know i can say to convince you otherwise. Personally, I think that's way more credit than any project should be awarding, so I took some steps to make sure something like this wont happen in the future.

---