R@H News

[PY 222]

FYI:

Outage Notice: The project will be down starting today at 3pm PST for maintenance. We should be back online later in the day.

[n7vxj]

I certainly hope this is not going to be a constant problem!!I have one box sitting idle cause it needs more work!! Needless to say, I put it back on RC5, until the servers are back up!!:Pokes:

[PY 222]

I think Rosetta wasn't prepared for the influx of people from the FaD.

So, from what the Admins of the project has mentioned, they are going to add more horsepower onto their server farm to serve everyone. Lets hope that this is the reason why they brought down the servers.

[MerePeer]

I certainly hope this is not going to be a constant problem!!I have one box sitting idle cause it needs more work!!

Some advice from IB:

Originally posted by IronBits
Go back to the Boinc website, login, change your preferences to maintain ~2 days worth of work and you should be good to go.


I saw another post as well, paraphrasing: apparently even though the preference option is worded something like 'how often to connect' with a subtext about cache size, apparently it is actually going to connect whenever WUs are ready, i.e. not wait 2 days then dump. So it would seem by placing the #days higher it only benefits you by having more insurance for Rosetta-down-periods and does not mean less frequent uploading of completed WUs.

[jasong]

Originally posted by MerePeer
Some advice from IB:


I saw another post as well, paraphrasing: apparently even though the preference option is worded something like 'how often to connect' with a subtext about cache size, apparently it is actually going to connect whenever WUs are ready, i.e. not wait 2 days then dump. So it would seem by placing the #days higher it only benefits you by having more insurance for Rosetta-down-periods and does not mean less frequent uploading of completed WUs.
That could make a lot of pay-by-the-hour dial-up users angry.

They should warn people of the "feature" in email.

[Angus]

It's a little more complicated than that.

The returning of results is in two parts.

When a WU finishes, it is "uploaded" immediately (assuming always-on network), meaning the result file is sent to a project server.

However, there is a second step called "reporting" that DOESN'T happen immediately. You will notice that after your WU uploads, the status in the Work tab changes to someting like "Ready to Report". This doesn't actually happen until the BOINC client is darned good and ready, usually when it decides it needs more work, or near the end of the "connect every x days" period.

So - you end up with returned result files, but the project doesn't know you have returned them until it's told by the "reporting" process.
There is a fair amount of frustration in the user community about this split process - the 'credit whores' like to see immediate results when a WU is finished. In a project like SETI(BOINC) credit isn't granted until a quorum of returned results is met. In Rosetta, credit is granted when the WU is "reported". The BOINC folks at UCD seem to think it's too much server load to have the "upload" and "report" happen at the same time. Since the two actions can occur on different servers, it could require two separate connects. But - it's going to happen sooner or later, so why not sooner? ARRGH


Anyway, back to the topic - 2 days seems like a good cushion for this project. A nice balance between reporting time and queue size. Even with the recent "no work available" issues, none of my boxes has run dry. The 5.2.x BOINC client does a much better job of keeping the queue at the requested size.

[Angus]

Originally posted by jasong
That could make a lot of pay-by-the-hour dial-up users angry.

They should warn people of the "feature" in email.

I think the BOINC client honors the network activity type rules - or at least it should.

[PY 222]

FYI. Another downtime.

News

November 8, 2005
Outage Notice: The project will be down again starting at 3pm PST for around 2 hours or less to improve the performance of our database server.

[n7vxj]

This is starting to get old real quick!!! All machines back to RC5 again!!!:Pokes:

[Angus]

Good Grief! Have a little patience! :spank:

At least they are actively improving their setup, instead of ignoring the users.

If two hours outage is causing issues, increase your queue size to a day or two.

[Bok]

Agreed, a pro-active 2 hour outage is a very good thing in my opinion.

Bok

[MerePeer]

Since the default is 0.1 day it made sense to increase it to smooth out any minor downtime. I set mine to 1 day initially to see how it would go, especially re: diskspace (which didnt appear to be an issue?), then I monitored using boincview. As each machine communicated with Rosetta throughout the day it downloaded 24 hours of future work which appeared to be determined based on how fast it was processing WUs, i.e. a 633Mhz gets less than 3Ghz.

In boincview its really easy to see how much work each machine has: the "Work Buffer" column shown in a few screens. I like the host list screen: on the left side click "All locations", then click the "Hosts" tab on the right. The "Work Buffer" is second to last (but can be dragged).

@Angus Thx for the 'splain re: reporting.

[PY 222]

Well, its back up, just as promised.

I wonder if they have added any hardware since the first downtime?

[Exci]

Some great news from the project:

From David Baker,
From analyzing the results of the searches all of you have done over the past week we have made a real breakthrough! The puzzle that emerged at the end of last week was that, while very low rms structures were generated in your searches, they typically had much higher energies than the native structure. It was as if you were playing golf, and the hole you were trying to land in was surrounded by an elevated barrier. I was puzzling over this while bicycling up the hill behind my house Sunday morning, and had an idea which I incorporated into the program and tested later in the day. The really neat result is that when I took the lowest rmsd structures that you found, and started calculations from them, the energy dropped dramatically, and the rmsd decreased significantly as well, as if the barrier had been replaced by a gentle slope down into the hole. Since Sunday, Vatson, a graduate student, Bin, a postdoctoral researcher in my group, and I have found that this dramatic movement towards the native structure occurs for a number of different protein systems.

David Kim is now preparing the latest version of the code for distribution on BOINC, and you will hopefully receive work units with the improved algorithm sometime tomorrow. If he has time, David will include the graphics option Jack Schonbrun has developed which shows quite vividly what is going on during the calculations. We think it is going to be a hit!


Link (http://boinc.bakerlab.org/rosetta/forum_thread.php?id=340)

[IronBits]

:thumbs:

[Bok]

:rock:

Great news!

Glad we could help :)

Bok

[n7vxj]

Sound like it's moving along quite nicely! I took you Guys advice, and reset my preferences, for 2 days worth of work.Shoudn't be a problem now!!:D

[MerePeer]

November 11, 2005
The rosetta application versions have been updated and we are currently beta testing the screen saver version developed by Jack Schonbrun. The updated versions include new methods for increasing diversity in our search strategy and a few minor bug fixes.

[MerePeer]

November 27, 2005
Outage Notice: The project will be down starting today at 3pm PST for maintenance. The server should be back online later in the evening.

[Shish]

Gotterdammerung.....
Why did I miss that preference setting.:bang:
Hate idle machines.:smoking:

[Bok]

November 27, 2005
Welcome to our new technical news bulletin.

Today, we backed up our database and reconfigured the database server to match Seti@home's configuration. We'd like to thank Bob Bankay, Seti@home's database administrator, and David Hammer at Einstein@home for providing useful advice and copies of their my.cnf files. Soon, we will be testing database replication on two test servers (64 bit dual Opterons w/ 8 GB RAM) set up by Keith, and if the tests look good, they will be used for production. The benefits of using replication (as stated in the MySQL documentation) are 1) server robustness (if the master server goes down another can be used as a backup), 2) load balancing for non-updating queries, and 3) server maintenance (such as database backups) without disruptions.

[PY 222]

Its good of them to give us these technical news bulletins.

I for one am waiting for them to bring in more servers to help put in more redundancy and load balancing.