https://boinc.bakerlab.org/rosetta/result.php?resultid=11593259

Would like to know how something like this is possible, while de computer is running 24/7 and connected all the time.
Do I have to check the queues myself everytime or what ?

The rest of the jobs in the queue are either already sent every day or can be send in on 16 march and so on. https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=88145

Furthermore I'm using a program such as boincmanager but with the possibility to auto-abort "jobs approaching/passed deadline".

So I'm rather curious to know the reason for this ?


I'm getting a bit tired of all these ????? errors.
Hope our Stampede goes to another project otherwise one can expect a lot more problems

---

Click to see the workunit results and you'll see that the person who originally had the workunit didn't report it back within the deadline limit. The workunit was sent to you, but before you finished it before YOUR deadline, the other user sent it in and was granted the credit. Then you sent it in, but your's came in second and wasn't granted any credit.

---

Thanks Megaflix .

Funny way of crunching.
I'm getting the WU and while mine is crunching it, another one sends it in before my computer is ready and so I'm crunching for nothing.
Seems like a contest.
Not my way of doing things.
Just a waste of time and demotivating.
My Cellie already over to F@h. The rest will follow.
If our Stampede is going to be R@H I'm staying for a month and then that's it.

---

That's not how Boinc and the validation system is supposed to be handling this; and it's one of the bugs they're working on tracking down and curing. Reporting the errors helps them track them down.. so continue, and you'll be helping all of us.
And the more bugs we get tracked down and removed, the more fun can be had with challenges like the DPC vs. Free-DC Gauntlet on FaD.

---

That's not how Boinc and the validation system is supposed to be handling this; and it's one of the bugs they're working on tracking down and curing. Reporting the errors helps them track them down.. so continue, and you'll be helping all of us.
And the more bugs we get tracked down and removed, the more fun can be had with challenges like the DPC vs. Free-DC Gauntlet on FaD.

As a matter of fact, this problem is a BOINC issue not a Rosetta issue. The problem has been identified, isolated, and reported to the BOINC development team for a fix. As for the deadline verses time left to crunch, this may be related to your WU time setting, and BOINC not having had time to adjust itself to the lenght of time it takes to process your queue. Whenever you abort a WU this hampers the ability of BOINC to adjust itself to your time setting.

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

It's another symptom of not using a quorum for granting credit, and screwing the user.

Add this to the overgranting of credit to PCs that are enthusiatically reporting absurd benchmarks, and the project wonders why the CPU power on the project isn't growing...

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

How can you use a quorum in a system, in which each user can set a different run time for the _same_ work unit. A quorum simply make no sense at all.

How can you use a quorum in a system, in which each user can set a different run time for the _same_ work unit. A quorum simply make no sense at all.

While it would be possible to develop a complex scheme of crediting to adjust for varying Work Unit time runs, it is in fact unnecessary. All of the complaints in this area are based on the use of so call "optimized" clients by some participants, which are in fact available to everyone equally. So the credit based argument for redundancy has no merit. Moreover, if a credit award system developed for the purpose of equalizing the difference in run length of the Work Units was put in place in a project application, people would be complaining about the fairness of that system as well. So from the project point of view it is a no win situation.

Besides being wasteful of donated resources, and serving no scientific purpose for this type of project, redundancy significantly slows the return of science data, and increases the load on the servers. For projects like Rosetta that are not highly funded or staffed this is an unnecessary overhead. While I have seen a few people claiming that the lack of redundancy will make droves of participants leave the project, the actual numbers do not bare out that argument.

So considering the wasteful nature of redundancy, the lack of any system to compensate for Work Unit variability for credit awarding, The lack of any data reflecting any significant impact on project participation, the additional cost to the project to support an infrastructure that does not provide any direct science benefit, the ready availability to the user community of an equalizing solution to the issue, and the fact that the entire BOINC credit system is about to be converted to a system that would eliminate the need to use redundancy to solve the problem, I would not look for redundancy in the Rosetta project any time soon.

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

The user-defined WU run time is another problem introduced by this project.

If the user needs a specific run time on a WU, all copies of that WU should have the same run time, meaning it needs to be controlled on the server end, not the client end.

The run time should be encoded in the WU, and not allowed to be changed once downloaded. If this means editing the WU after the first copy is downloaded, then that is something the project has to take on.

Otherwise, the whole credit granting idea is down the drain, and with it any significant increased contribution of CPU power. I'll repeat what I've said before, and will continue to say - fair and equitable credit granting is crucial to the success of ANY DC project, BOINC or otherwise. The competition, not the science, is what brings the CPU power.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

While it would be possible to develop a complex scheme of crediting to adjust for varying Work Unit time runs, it is in fact unnecessary. All of the complaints in this area are based on the use of so call "optimized" clients by some participants, which are in fact available to everyone equally. So the credit based argument for redundancy has no merit.

That arguement only works if either EVERYONE or NO ONE is using the optimized BOINC client. It also doesn't address the ability to alter the benchmarks manually to the absurd levels that have been seen. Only a quorum that throws out the stupidly high credits will produce fairness in credit granting.

Besides being wasteful of donated resources, and serving no scientific purpose for this type of project, redundancy significantly slows the return of science data, and increases the load on the servers.

Not having participation also slows the science, doesn't it?

For projects like Rosetta that are not highly funded or staffed this is an unnecessary overhead. While I have seen a few people claiming that the lack of redundancy will make droves of participants leave the project, the actual numbers do not bare out that argument.

Not being highly funded or staffed is exactly the type of project BOINC is aimed at. That's pretty much all of them so far. Dr Baker himself has been complaining in the Science forum about the lack of incrased participation. When a reason is given that is valid in the DC community, that credit granted is hopelessly flawed in this project, the head-in-the-sand thing starts happening again - as demonstrated below:

So considering the wasteful nature of redundancy, the lack of any system to compensate for Work Unit variability for credit awarding, The lack of any data reflecting any significant impact on project participation, the additional cost to the project to support an infrastructure that does not provide any direct science benefit, the ready availability to the user community of an equalizing solution to the issue, and the fact that the entire BOINC credit system is about to be converted to a system that would eliminate the need to use redundancy to solve the problem, I would not look for redundancy in the Rosetta project any time soon.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

... I'll repeat myself again - ...

Frequently used technique for a hollow argument or gratutious assertion.

I can't help but notice that while I see many posts from you complaining about this issue, AND even a few saying you would leave the project, You seem to still be here, and you seem to still be running WUs. These facts kind of make your argument seem like baseless table pounding.

---

We Must look for intelligent life on other planets as,
it is becoming increasingly apparent we will not find any on our own.

... I'll repeat myself again - ...

Frequently used technique for a hollow argument or gratutious assertion.

I can't help but notice that while I see many posts from you complaining about this issue, AND even a few saying you would leave the project, You seem to still be here, and you seem to still be running WUs. These facts kind of make your argument seem like baseless table pounding.

Ignoring the part of the redundant redundancy, I'm not actually running any Rosetta WUs today, one box may have accidently grabbed some last week, and I certainly am not putting the 70+/- GHz on it that I once did.

Oh - and I didn't see a requirement to be actively crunching to be able to post here...

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

Angus, forgive me for being blunt, but frankly this constant bitching and moaning is getting a bit old. And counter-productive. Especially since you are twisting the facts IMHO.

The user-defined WU run time is another problem introduced by this project.

The variable-runtime-WU solution was actually the best possible solution, to solve Rosetta's pressing "1GByte per P4 per month" Internet traffic issue, an insurmountable hurdle for dialup contributors and people with traffic quotas and a big burden for multi-PC crunching-farm-at-home people like NightOwl.

Only a quorum that throws out the stupidly high credits will produce fairness in credit granting.

Quorum would immediately slash effective "science" TeraFLOPS to 1/3th (or even less). For those BOINC projects I checked, using redundancy slashes effective TFLOPS to 1/4th) of "raw" TeraFLOPS. Unless there were a valid "science" reason, do you really think that implementing quorum would attract 3x or 4x as many participants, to compensate for the loss?

I agree that the possibility of claiming higher credits is a nuisance. But so are other issues, e.g. the fact that standard Linux BOINC underestimates credits by almost 50%. And if more and more users migrate to optimizing BOINC clients, the whole point will be moot, unless you suggest to further increase quorum, to by chance include some non-opt BOINCs in the mix. Where would it all end?

Don't get me wrong, I'm also in favor in 100% fair credits for all BOINC projects. But IMHO there are other options that R@h can do wrt credits, without adverse impact on effective TFLOPS. Like running the CPU benchmark on the science app itself. Like assigning a credit to each model/step.

Or, in addition to "top predictions", maybe do a rank of how many of one's models were "close" (as percentile) to native. etc etc

the lack of incrased participation.

I often take a peek at the BOINC stats and "hosts added last day". I have run practically all BOINC projects and the fact is that with exception of CPDN, Rosetta is the heaviest one on a system's resources (still is on memory and until very recently on Internet bandwidth). Plus the extra requirements, like "leave app in mem" etc. And the 1% etc issues some PCs have.

Here we have a project doing some potentially groundbreaking science. A responsive science team, giving daily feedback to the "troops". And fixing things like bandwidth requirements etc.

So, let's not miss the forest for the trees.

---

Best UFO Resources
Wikipedia R@h
How-To: Join Distributed Computing projects that benefit humanity

Nobody in this thread said that there weren't other issues keeping people from jumping into Rosetta with both feet.

This was a thread on validation and credit granting.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

All of the complaints in this area are based on the use of so call "optimized" clients by some participants, which are in fact available to everyone equally.

While I don't want to get in the middle of the personal dispute going on here, I kind of have some lingering doubt as to whether all the complaints are really pointing at legitimately optimized clients.

I use an optimized client myself (the one made by Harold Naparst and available to anyone), but some of the benchmarks I've seen don't appear to be coming from any legitimate optimized clients.

Now, I'm as far as could possibly be from being a computer programmer - and I couldn't interpret a single line of code if my life depended on it. That said, it took me well under 2 minutes to find a way to alter the code to get bogus benchmarks. This host is the one I created, with no difficulty whatsoever, with bogus benchmarks. Since I altered the code, I did let it run a single work unit for one hour (the shortest time possible) just to make sure the client really did still work properly and return results that would validate. The benchmarks on that host came from my first guess at making changes, and I didn't do too good as my whetstone is lower than a legitimate optimized client. But my dhrystone is much higher than legitimate. The end result was that my system that normally claims 10.125 cs/hour with a legitimate optimized client claimed 33 cs/hour after my changes - changes that are now built into the code so it will rebenchmark this way every time. THESE CHANGES ARE CLEARLY CHEATING, and I made these changes by doing nothing more than altering 1 single item in 2 files, but without some kind of a sanity check from rosetta ANYONE can cheat like this.

And to show how completely absurd it can get, I then decided to go even further and see what it would give. I won't attach it unless there is some compelling need to prove the benchmarks it gives me now - as I would have to trash the work unit that would be initially assigned. However, here's the output from executing the absurd version (and there appears to be no limit on how far it can go if I just change it even more than I did):

platinum client # ./boinc
2006-03-11 18:46:55 [---] Starting BOINC client version 5.2.14 for i686-pc-linux-gnu
2006-03-11 18:46:55 [---] libcurl/7.15.2 OpenSSL/0.9.7i zlib/1.2.3
2006-03-11 18:46:55 [---] Data directory: /home/darren/extract/boinc/client
2006-03-11 18:46:55 [---] Processor: 2 GenuineIntel Intel(R) Pentium(R) 4 CPU 3.06GHz
2006-03-11 18:46:55 [---] Memory: 883.68 MB physical, 494.18 MB virtual
2006-03-11 18:46:55 [---] Disk: 13.80 GB total, 7.96 GB free
2006-03-11 18:46:55 [---] No general preferences found - using BOINC defaults
2006-03-11 18:46:55 [---] Remote control not allowed; using loopback address
2006-03-11 18:46:55 [---] Primary listening port was already in use; using alternate listening port
2006-03-11 18:46:55 [---] This computer is not attached to any projects.
2006-03-11 18:46:55 [---] There are several ways to attach to a project:
2006-03-11 18:46:55 [---] 1) Run the BOINC Manager and click Projects.
2006-03-11 18:46:55 [---] 2) (Unix/Mac) Use boinc_cmd --project_attach
2006-03-11 18:46:55 [---] 3) (Unix/Mac) Run this program with the -attach_project command-line option.
2006-03-11 18:46:55 [---] Visit http://boinc.berkeley.edu for more information
2006-03-11 18:46:57 [---] Running CPU benchmarks
2006-03-11 18:47:56 [---] Benchmark results:
2006-03-11 18:47:56 [---] Number of CPUs: 2
2006-03-11 18:47:56 [---] 39714 double precision MIPS (Whetstone) per CPU
2006-03-11 18:47:56 [---] 2310738 integer MIPS (Dhrystone) per CPU
2006-03-11 18:47:56 [---] Finished CPU benchmarks
2006-03-11 18:47:57 [---] Resuming computation and network activity
2006-03-11 18:47:57 [---] request_reschedule_cpus: Resuming activities


Notice the benchmarks, and just imagine what kind of credit that would claim.

But, my whole point here is that there needs to be some kind of a sanity check put in place by rosetta. If nothing else, a script that runs every day or so that just looks for totally out of whack benchmarks when compared to the cpu they were run on - then adjusts and recalculates the granted credit to those hosts that are too far from reasonable.

OK, stepping off of my soapbox now...

---

All of the complaints in this area are based on the use of so call "optimized" clients by some participants, which are in fact available to everyone equally.

While I don't want to get in the middle of the personal dispute going on here, I kind of have some lingering doubt as to whether all the complaints are really pointing at legitimately optimized clients.

... But, my whole point here is that there needs to be some kind of a sanity check put in place by rosetta. If nothing else, a script that runs every day or so that just looks for totally out of whack benchmarks when compared to the cpu they were run on - then adjusts and recalculates the granted credit to those hosts that are too far from reasonable.

OK, stepping off of my soapbox now...

The Rosetta project does not now and never has recommended the use of optimized clients. However, the reality is that people do use them, and they are available to everyone. There is nothing the project can do about that. The project certainly does not condone the editing of the BOINC file system to make false credit claims, or for any other reason. But I would point out that changing the files distributed by Rosetta will NOT inflate your credit claims. So the problem you have pointed out is a BOINC problem.

Despite this simple reality, and the resulting credit claims made by some systems, this does not equate to an extinction level event (ELE), or a crisis of global import, despite argument to the contrary. However, some of the science that the project is trying to pursue could prevent just such an ELE by finding cures for a broad range of current and future biological pathologies. While I have no doubt that some people will ignore the value of the research and leave the project because they think the credit system is unfair or bad, a lot of people simply do not care about credits and they will stay. The credits are a game between some participants, the science is life and death for everyone.

While clearly a few people are concerned with credit awards to the exclusion of all else, the awarding of credits is not the primary purpose of ANY of the BOINC projects. Certain projects have the time, resources and inclination to put credit awards, and the perceptions of unfair credit awards ahead of their science goals. That is their choice.

Rosetta has chosen to bring the issue to the BOINC developers, and recommend changes to the BOINC client that will accommodate the needs of projects like Rosetta that wish to keep science as their primary concern. The BOINC developers have listened and said that there are changes coming to deal with issues such as variable Work Unit run length, and non redundant processing. Additional changes are designed to patch the "cheating" holes in the BOINC system. This is the correct approach to repair the problem.

Some people still want the issue handled right now, and will raise the issue with great fervor at any opportunity. I would encourage them to attach to the BOINC development site and post heavily to the BOINC forums on that issue. But frankly, Rosetta is not currently planning to institute redundancy, and I have heard of no plans to develop a new credit system unique to Rosetta.

That position does not constitute hiding from the issue, or ignoring the users, it constitutes fixing the problem at the source. The benchmark system is controlled by BOINC, the credit claims are calculated by BOINC, the ability to hack certain important BOINC files is a BOINC security issue, and the lack of support for non redundant projects is a BOINC problem. Therefore the fix lies with some future version of the BOINC client package, and that is precisly what the project is trying to get.

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

...So the problem you have pointed out is a BOINC problem.

Well, I only partly agree with that. Having been with boinc since it was in beta testing, boinc addressed this from the very beginning. You have not seen me reccommend redundancy here - and you won't see it - but that is the built in method that boinc uses to prevent people from claiming falsely high credit. It is ROSETTA that chooses not to run their project in a way that allows the boinc software to prevent this as it was intended. The problem that I mention does not occur on other projects - it is unique to rosetta. Boinc released the software as open-source knowing it could be manipulated, then implemented redundancy to negate any benefit anyone would gain from making those manipulations. Again, I don't advocate redundancy here (or on most projects for that matter) - just some simply sanity check to detect falsely high credit claims.


...melodramatic stuff edited out...

While clearly a few people are concerned with credit awards to the exclusion of all else, the awarding of credits is not the primary purpose of ANY of the BOINC projects.

And it should not be, but neither should it be totally ignored. I really don't care about credits myself. I've participated in projects knowing credit would be lost, such as boinc beta. Yeah, I post my credits in my signature, but they're just numbers - they have no value and I know that. However, they are the only thing that crunchers get in exchange for their participation. And as that, the project should demonstrate some degree of respect for them rather than a "we don't care if people cheat" attitude. The primary purpose of the Olympics is not awarding medals, but the Olympic committees ensure that the ones actually awarded were really earned.

...But frankly, Rosetta is not currently planning to institute redundancy, and I have heard of no plans to develop a new credit system unique to Rosetta.

Again, I've never suggested that. The most I've suggested is a script to trigger an automated process of "correcting" credit claims that are clearly abnormal.

That position does not constitute hiding from the issue, or ignoring the users, it constitutes fixing the problem at the source. The benchmark system is controlled by BOINC, the credit claims are calculated by BOINC, the ability to hack certain important BOINC files is a BOINC security issue, and the lack of support for non redundant projects is a BOINC problem. Therefore the fix lies with some future version of the BOINC client package, and that is precisly what the project is trying to get.

Again, only half credit here. Boinc is designed to operate a certain way, it is Rosetta that does not conform to that standard. Now, I fully hope that boinc is successfully modified to support everything Rosetta wants (and any other project that wants to use boinc), but this adamant "it all boinc and no rosetta" to blame is really astounding. As it is rosetta that is deviating from the boinc norm, rosetta does have some obligation in addressing the issue.

---

...So the problem you have pointed out is a BOINC problem.

...That position does not constitute hiding from the issue, or ignoring the users, it constitutes fixing the problem at the source. The benchmark system is controlled by BOINC, the credit claims are calculated by BOINC, the ability to hack certain important BOINC files is a BOINC security issue, and the lack of support for non redundant projects is a BOINC problem. Therefore the fix lies with some future version of the BOINC client package, and that is precisely what the project is trying to get.

Again, only half credit here. Boinc is designed to operate a certain way, it is Rosetta that does not conform to that standard. Now, I fully hope that boinc is successfully modified to support everything Rosetta wants (and any other project that wants to use boinc), but this adamant "it all boinc and no rosetta" to blame is really astounding. As it is rosetta that is deviating from the boinc norm, rosetta does have some obligation in addressing the issue.
[/quote]

Most people who look at this objectively would agree that redundancy, while a nice patch for a design flaw, is not the best solution for the validation issue if the only purpose for using it is credit granting. If I read you correctly, you see it that way as well. In certain cases redundancy is required to validate the quality of the science, but Rosetta is not one of those cases. While a number of projects do use redundancy, it is a significant waste of resources unless it serves the project.

Your position that Rosetta has somehow violated the intent of BOINC by requesting improvements to the Client, is just not correct. If it were we would all be flying in Wright flyers and driving black model "T" fords. Growth, change and improvement are a natural part of a successful world.

You have correctly pointed out that BOINC redundancy was instituted to solve known weaknesses in the BOINC credit system. So in truth BOINC is forcing the projects to give up between 1/2 and 3/4 of the available project computing power to fix a problem in the BOINC infrastructure and design concept.

Rosetta has not violated any part of the BOINC concept in requesting changes to BOINC that would allow for non-redundant projects, or variable length Work Units, any more than asking for a change from the current credit system to a flops counting system violates that concept. The fact that Rosetta is working with the BOINC team, and that the two teams are working on this tells the COMPLETE story. If the BOINC folks did not think non redundant projects were a good idea, they would have simply ignored the request.

If we are to expect no changes in BOINC that are driven by the needs of the projects, then all of the projects should conform to the original SETI standard when BOINC was first released. Instead, most people recognize that BOINC itself is actually in a state of development. Not just as a software program, but as a concept as well. Rather than non conformance, what Rosetta is doing is helping to make BOINC a better product for a broader range of scientific research, by working to add features and broaden the capabilities of the system. Moreover, those requests for change are driven by the concerns of the Rosetta user community for a better project.

Can anyone honestly say that BOINC should NOT be improved? Is it so perfect in concept and current implementation that change is unnecessary? Should BOINC NOT be able to accommodate fair credit awards without wasting 3/4 of the computing resources available? Is it reasonable for a scheduling client to demand that all projects conform to a one size fits all Work Unit structure when it doesn't have to be that way?

Frankly, the new time feature in Rosetta is a quite elegant and simple solution to a range of problems beyond simple bandwidth reduction that face all BOINC projects. For example how about allowing slower machines to run the projects and still meet the reporting deadlines.

What Rosetta is asking of BOINC is precisely what the BOINC environment is all about. Flexibility, creativity, science. innovation, and reaching for more. I am sorry you feel that all of this is melodramatic. But the fact is, the BOINC world is about expanding the range of human knowledge for the sake of mankind. A fairly simple concept that is often lost in the shuffle.

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

Most people who look at this objectively would agree that redundancy, while a nice patch for a design flaw, is not the best solution for the validation issue if the only purpose for using it is credit granting. If I read you correctly, you see it that way as well. In certain cases redundancy is required to validate the quality of the science, but Rosetta is not one of those cases. While a number of projects do use redundancy, it is a significant waste of resources unless it serves the project.

That is my exact take on redundancy. On some projects it serves a scientific need and should exist. On most it doesn't and should not exist. That is why I made it perfectly clear that I do not think rosetta should implement redundancy.

Your position that Rosetta has somehow violated the intent of BOINC by requesting improvements to the Client, is just not correct.

I don't think I have in any way implied such a position.

You have correctly pointed out that BOINC redundancy was instituted to solve known weaknesses in the BOINC credit system. So in truth BOINC is forcing the projects to give up between 1/2 and 3/4 of the available project computing power to fix a problem in the BOINC infrastructure and design concept.

But as everyone knows, you're not forced to use the redundancy concept that boinc has integrated. However - and this is a big however - when you decide NOT to use it, you should have a viable alternative in its place. Right or wrong, good or bad - it does serve a purpose. Considering that, it shouldn't simply be discarded unless an alternative is put in its place. Your database is under your control, not Berkeley's. When rosetta decided not to implement the boinc solution at the boinc level, an alternative solution should have been put in place at the rosetta level. Not to say that suggestions (very forceful ones if necessary) shouldn't be presented to Berkeley to improve the boinc program overall, until that happens it's still rosetta that chose no redundancy therefore it's still rosetta's responsibility to have a (hopefully temporary) alternative in place.

If we are to expect no changes in BOINC that are driven by the needs of the projects, then all of the projects should conform to the original SETI standard when BOINC was first released. Instead, most people recognize that BOINC itself is actually in a state of development. ... Can anyone honestly say that BOINC should NOT be improved? Is it so perfect in concept and current implementation that change is unnecessary?

I'm not a boinc cheerleader - I think boinc (the program, not the concept) still needs a lot of improvement. In my mind, though, that still doesn't equate to a project just ignoring one of the "less-than-desirable" aspects of boinc without somehow compensating for the lost function that is introduced by ignoring that bad aspect (in this case, fair credit). Again, it goes back to right or wrong, good or bad, that less-than-desirable aspect does still serve a purpose.

Frankly, the new time feature in Rosetta is a quite elegant and simple solution to a range of problems beyond simple bandwidth reduction that face all BOINC projects. For example how about allowing slower machines to run the projects and still meet the reporting deadlines.

While my machine is not overly slow, this one thing was the sole trigger for me deciding to allocate much more of my machine to rosetta. I currently run them for 48 hours, and plan to increase to 96 very soon. I guess I'm a little backwards from most crunchers in that aspect - I prefer long work units over short ones.

What Rosetta is asking of BOINC is precisely what the BOINC environment is all about. Flexibility, creativity, science. innovation, and reaching for more. I am sorry you feel that all of this is melodramatic.

Well, that was not the melodramatic part of your post. The melodramatic part was the implication that the human race may become extinct if the project were to devote just a bit of attention to fixing a problem its own design caused instead of devoting every minute towards the science, which "is life and death for everyone".

Not that the science is not extremely important - I think it is. But I guess having been a paramedic for 23 years, my definition of "life and death for everyone" is a bit different from that of a rosetta scientist.

---

Darren said -

Mod9 said - Your position that Rosetta has somehow violated the intent of BOINC by requesting improvements to the Client, is just not correct.

I don't think I have in any way implied such a position.

but Darren said earlier -

...Again, only half credit here. Boinc is designed to operate a certain way, it is Rosetta that does not conform to that standard........

Which says to me that Darren did imply that Rosetta had violated the intent of Boinc!

---