A quick test reveals Rosetta@home still haven't fixed their broken upload-server:

08.10.2011 14:33:09 | rosetta@home | [fxd] starting upload, upload_offset -1
08.10.2011 14:33:09 | rosetta@home | Started upload of place_CwEfDw_20111005_EBOV_GP3_1jl1_ProteinInterfaceDesign_05Oct2011_33944_360_0_0
08.10.2011 14:33:09 | rosetta@home | [file_xfer] URL: http://srv6.bakerlab.org/rosetta_cgi/file_upload_handler
08.10.2011 14:33:18 | rosetta@home | [file_xfer] http op done; retval 0 (Success)
08.10.2011 14:33:18 | rosetta@home | [file_xfer] parsing upload response: <data_server_reply>    <status>0</status>    <file_size>0</file_size></data_server_reply>
08.10.2011 14:33:18 | rosetta@home | [file_xfer] parsing status: 0
08.10.2011 14:33:18 | rosetta@home | [fxd] starting upload, upload_offset 0
08.10.2011 14:33:27 | rosetta@home | [file_xfer] http op done; retval 0 (Success)
08.10.2011 14:33:27 | rosetta@home | [error] Error reported by file upload server: invalid signature
08.10.2011 14:33:27 | rosetta@home | [file_xfer] parsing upload response: <data_server_reply>    <status>-1</status>    <message>invalid signature</message></data_server_reply>
08.10.2011 14:33:27 | rosetta@home | [file_xfer] parsing status: -128
08.10.2011 14:33:27 | rosetta@home | [file_xfer] file transfer status -128 (permanent upload error)
08.10.2011 14:33:27 | rosetta@home | Giving up on upload of place_CwEfDw_20111005_EBOV_GP3_1jl1_ProteinInterfaceDesign_05Oct2011_33944_360_0_0: permanent upload error

Can the project administrators please disable the upload certificates on this project as was asked by David Anderson? This helps us who test the newer 6.13 clients as now all work we do for you project will get a validate error stamped on it, while the work is otherwise correct.

"Upload certificates" are a mechanism that keeps bad guys from DoS'ing your upload servers
(note: such an attack has never happened, as far as I know).

We're changing the format of upload certificates, and we're starting to test a version of the client for which old-format certificates won't work. Volunteers testers won't be able to upload completed jobs, and they may complain to you.

I suggest that all projects disable upload certificates. To do so, add the following to your config.xml file:

<dont_generate_upload_certificates/>
<ignore_upload_certificates/>

To resume using upload certificates, if you wish:

1) upgrade to the current server source code (from trunk)
2) wait for all jobs with old-format certificates to be dispatched
3) re-enable certificates by removing the above lines.

Let me know if any questions.

-- David

With thanks.

The team BOINC Synergy has selected Rosetta to be its project of the month for May! I hope the extra computing helps with CASP.

I have noticed that on my faster machine, the limit of 99 decoys is usually reached before the 12-hour expected runtime I've requested. You might want to check the report visible on the Rosetta@home of how well the workunit succeeded to see if your workunits also often stop at the 99 decoys limit instead of near the requested run time.

The workunits ending before the selected run-time get to a stop at 100 decoys, whereas the one recent workunit which made it to the selected 16 hours stopped at 88 decoys. Is there anything I can do to adjust this or is it a lucky-dip?

I've noticed this too. As far as I can tell, it's a "lucky-dip" as you so accurately describe it. Also known as a crap-shoot in other parts of the world. ;)

In another thread, I suggested increasing the maximum number of decoys from 100 to something higher, but that idea was rejected. I still find the reason for staying with the 100 decoy max totally counter-intuitive, and in fact I'm not at all sure the reasoning given is correct.

That said, I'll make the suggestion again to increase the max decoys to 200 (or even higher), and see where the suggestion goes. For those of us with fast machines, willing to do long run times it will reduce the load on the servers. I admit it will change the "shape" of the uploaded data, but it will not change the amount - this last point is the one where I think people haven't thought the problem through correctly.

my first confusion is the name. Wth? Is that just dished out at random, or does the name actually mean something (like does that name somehow equal the Ubiquitin-protein ligase as an example)?

Then there is the "stderr out" bar that then goes on to list a whole bunch of text that at first glance seems like a whole bunch of blah. Second glance did not change my view:

Finally (while I am here), I noticed that the homepage of Rosetta@home says that R@home is not for profit. But I then read on Dr David Bakers journal (which I skimmed and some parts are a great read!) and he mentioned something about manuscripts (which I assume means, publishing articles in scientific journals). Dont those articles go on to be published for a profit (correct me if I am wrong here)? Or does the heading mean that all the data is released in the public domain, and then you can use the data however way you wish (i.e. publish the data into results, make money etc etc?)
Cheers!

Cenit....You are trying to compare apples to oranges with your question.
Using SMP in a multi-core computer would indeed solve a workunit very fast. Much faster than applying a single core to a workunit. SMP is actually the prefered method of crunching a workunit at folding@home. It is thier belif that using muliple cores on just one workunit is more efficent than applying say 4 workunits to 4 cores.

BOINC does not use SMP. BOINC is the middleware that runs rosseta@home. It will apply say the 4 cores to 4 workunits. Rosseta@home has nothing to do with how the proccessors crunch the workunit.

Fundamentally, the Rosetta team has elected to use an architecture and technique where there is no need for the nodes to communicate.

I pulled up a random pdf file and after skimming thru it didn't see any mention of the Distributed Computing contributions to the paper. Is this on purpose or did I just pick a paper that did not have it in there? I am curious because maybe if the DC contributions were acknowledged in official releases to Scientists perhaps they could see the results possible and maybe more would jump on board and encourage others to do the same. Obviously 'getting the word out' is an important step to getting more and new users over time.

I think one way to do that would be to get more and more Scientists involved and aware causing them to use it in their vocabulary causing their students/whatevers to then do the same. This would then, hopefully, cause other students/whatevers to do the same bring DC into the home from the only people possible, the kids! As kids we all thought we could solve all the problems of the World if we just thought about it enough. As adults we begin to realize the daunting tasks involved. IF we could get the idea of DC being a positive influence and a venue for change maybe we could get it installed on every computer, or at least the Developed World ones! BUT I think if its involvement were acknowledged in official papers, it would start the thought processes flowing.

For me it doesn't matter whose loss it is because waste is never a good thing. If the waste can be eliminated with minimal effort, as it can be at LHC@home, then to not do so is just lazy and irresponsible.

Just got this error trying to perform an update:

2/2/2009 10:05:58 AM|rosetta@home|Sending scheduler request: Requested by user
2/2/2009 10:05:58 AM|rosetta@home|(not requesting new work or reporting completed tasks)
2/2/2009 10:06:03 AM|rosetta@home|Scheduler RPC succeeded
2/2/2009 10:06:03 AM|rosetta@home|Message from server: Server error: can't attach shared memory
2/2/2009 10:06:03 AM|rosetta@home|Deferring communication for 1 hr 0 min 0 sec
2/2/2009 10:06:03 AM|rosetta@home|Reason: project is down

Server is up according to the webpage. One task was updated as complete.