Am I causing the bandwidth problems? Are you?

Message boards : Number crunching : Am I causing the bandwidth problems? Are you?

To post messages, you must log in.

AuthorMessage
Profile shanen
Avatar

Send message
Joined: 16 Apr 14
Posts: 195
Credit: 12,662,308
RAC: 0
Message 78895 - Posted: 11 Oct 2015, 2:17:13 UTC

Second attempt, and my apologies if I'm making the same mistake, but I attempted to create a new thread, and apparently failed. However, that is actually touching the root of the problem. I do NOT want to spend a lot of time figuring out how a BOINC project works--and it was complicated behavioral problems that led me to abandon the last two projects I had supported. (I also was a top 1% contributor to the original pre-BOINC seti@home project, but I abandoned that one mostly because I think their approach is flawed. They are looking where the light is best, not where they "lost" their ETI...)

Notwithstanding explanatory commentary from the actual scientists, right now I feel that the most reliable way to contribute to rosetta@home is to run ONLY the rb projects. At least I have a good chance of completing those work units and thus providing useful results. How many of you have reached the same conclusion?

After reaching this conclusion, I routinely abort non-rb projects before they can waste any running time--but even if I catch such a non-rb project during the original download, it seems the data gets downloaded anyway. (I'm pretty sure the data downloads to client machines are much larger than the uploaded results. Most of the data is presumably discarded after use and the uploads are almost negligible.) If bandwidth is the bottleneck resource for rosetta@home, then people like me are probably making a bad situation worse...

Just a few specific example of the problem: A few days ago, two FKRP units managed to get started on one of my machines. I looked at their statuses at the end of the day when I had to shut down the machine. As confirmed the next morning, one of them lost at least 20 minutes of work since the last checkpoint, and the other lost 15 minutes. Those losses were actually on the small side for my observations of FKRP work units, but in general each time I turn off a machine about 15 minutes of rb work is lost. (Yes, sleeping the machines is an option, but there are reasons I rarely use that approach.)

On a different machine, I have developed the routine of checking before shutting down. I started doing this after noticing that some work units never seemed to make progress when that machine only runs for 2 to 4 hours at a time. It turned out that those work units would not checkpoint for some hours and just restarted each time the computer was booted. Yesterday it was okay to shut it down, but the two days before that, it had work units with more than one hour of uncheckpointed work, so I have to sleep the machine to make any progress.

There are various constructive suggestions, but I doubt whether it is worth discussing them here, since I basically feel that most of them are out of the scope of rosetta@home. I think the most definitive solution for bandwidth problems might be P2P network caching of the bulk of the data, where the BOINC clients would first try to find a copy of the data from some other client that already has it... (That's based on a belief that a lot of the data is analysed several times in different ways.)

Another BOINC-level approach would be to make sure that normal shutdowns can trigger checkpoints. Sort of a local sleep for BOINC tasks? (Of course this might be too difficult because it is so OS-specific.)

A less definitive approach that should be within the scope of the rosetta@home staff would be to slack up on the deadlines. Way up, if you ask me. I strongly believe they could save a lot of bandwidth with a little patience. It would still waste a lot of work in some cases, but maybe I would never notice?
#1 Freedom = (Meaningful - Constrained) Choice{5} != (Beer^3 | Speech)
ID: 78895 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile shanen
Avatar

Send message
Joined: 16 Apr 14
Posts: 195
Credit: 12,662,308
RAC: 0
Message 78897 - Posted: 11 Oct 2015, 22:57:49 UTC - in response to Message 78895.  

Okay, at this point both threads are visible, and it is apparently another complexity of rosetta@home that made it difficult to see the first new thread. NEITHER of the new threads appear where I would expect them to. The option to control the display orders of the comments is incorrect or, even worse, the indexing itself is broken.

On this visit I noticed another reference to Google Groups, where there is apparently a separate discussion going on. That's fine and dandy, but additional complexity. My life has sufficient complexity, so no, thank you.

Not wanting to sound like some sort of extremist, but I'm looking for simplicity, not layers of complexity. The idea of donating unused computing cycles to useful projects remains sound, but the layers of complexity are just out of my range of interests. If I want to play complicated games, I hear that there are many fascinating networked versions of Rogue/Hack/etc. these years.

Therefore it appears I should start looking for a different BOINC project to support.
#1 Freedom = (Meaningful - Constrained) Choice{5} != (Beer^3 | Speech)
ID: 78897 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Link
Avatar

Send message
Joined: 4 May 07
Posts: 356
Credit: 382,349
RAC: 0
Message 78899 - Posted: 12 Oct 2015, 8:10:37 UTC - in response to Message 78895.  

Notwithstanding explanatory commentary from the actual scientists, right now I feel that the most reliable way to contribute to rosetta@home is to run ONLY the rb projects. At least I have a good chance of completing those work units and thus providing useful results. How many of you have reached the same conclusion?

Not me at least, my conclusion is to let my computers run 24/7 and/or hibernate them if a reboot isn't necessary for system maintance or so. This not only helps with BOINC projects, but also does not disturb my other usage of the computer since everything stays exacly where I left it.



If bandwidth is the bottleneck resource for rosetta@home, then people like me are probably making a bad situation worse...

Bandwidth is not the only issue, also database size can be one (not sure however if it is here).



so I have to sleep the machine to make any progress.

See, there is an easy solution to the "problem".

BTW, since Windows 8 hibernating is standard when pressing the power button, so even Microsoft (finally) noticed, that shutting down every day is completely unnecessary (older versions of Windows would shut down when you press the power button).



Okay, at this point both threads are visible, and it is apparently another complexity of rosetta@home that made it difficult to see the first new thread. NEITHER of the new threads appear where I would expect them to. The option to control the display orders of the comments is incorrect or, even worse, the indexing itself is broken.

You can choose from four display orders (I don't think that's too complex), I just tried all of them and they do exactly what they are supposed to do.
.
ID: 78899 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote
Profile Chilean
Avatar

Send message
Joined: 16 Oct 05
Posts: 711
Credit: 26,694,507
RAC: 0
Message 78975 - Posted: 23 Oct 2015, 3:18:12 UTC - in response to Message 78897.  
Last modified: 23 Oct 2015, 3:19:52 UTC

Okay, at this point both threads are visible, and it is apparently another complexity of rosetta@home that made it difficult to see the first new thread. NEITHER of the new threads appear where I would expect them to. The option to control the display orders of the comments is incorrect or, even worse, the indexing itself is broken.


This option works perfectly fine for me as well. You know there are a bunch of "sticky threads" which will be at the top of the list no matter what, right?
ID: 78975 · Rating: 0 · rate: Rate + / Rate - Report as offensive    Reply Quote

Message boards : Number crunching : Am I causing the bandwidth problems? Are you?



©2024 University of Washington
https://www.bakerlab.org