I know some of you are on internet connections where you are charged per packet, or have monthly bandwidth limitations. Or you have a slower dial-up connection, and so when you hit a 1-3MB file that needs to be downloaded, you notice how long it takes.

I was tinkering with the BOINC client and monitoring the activity between the client and the project, and I stumbled on to a way to potentially save a considerable amount of bandwidth.

The convensional wisdom seems to be that you should use 24hr (i.e. the current maximum) runtime preference (Rosetta Preferences) to crunch each task for a long period of time, and therefore have to download less tasks in a month.

...that's fine. It also results in needing to contact the project less frequently, which saves you bandwidth on "scheduler requests".

...but there is another factor, and that is the types of tasks you have remaining in your BOINC client. If you keep a large cache of work (i.e. have set the local preference to fetch additional work, or have set your General Preference to only connect to network about every xx days, with a couple of days in there).

For example, I was running with a short runtime preference and had set to "no new work" for a considerable time, I had about 20 tasks loaded on my machine, most of which were completed. So when I allowed new work and network access, BOINC requested a lot of work. I got back a 500K scheduler reply, which gave me 14 more tasks... but no file transfers occured... because my existing tasks already had the required files loaded.

If I had been running 24hr tasks, and not keeping any extra work around, I would only have one or two tasks per CPU on my machine. That would greatly increase the odds that I would have to download another 1-3MB file to process a "new" protein... even though it is the same one I might have compelted, and reported back yesterday. But as soon as all the tasks using that file are completed, BOINC cleans up the file.

...so it might actually net less bandwidth if you cut your runtime to 12hrs and thus keep twice the number of tasks onboard. That increases the odds that you will keep the 1-3MB files for several of the active types of work, and therefore not need to download them again.

You could also move towards that same goal by increasing the number of days between network connections in your General Preferences. Again, net result, more work units exist on your machine, and you increase your odds of already having the requisite files onboard.

Having said that, don't go overboard. If you have a 1hr runtime preference, connect to network every .1 days, and you keep 5 days of work onhand, your scheduler requests will be frequent and large, because all of those tasks are reported back each time.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

If you run multiple projects, and want to conserve bandwidth, then I would suggest actually running 99% Rosetta and 1% backup project for a month, and then reversing the resource shares the following month... rather then running two projects with a 50/50 resource share for two months.

Or if you have multiple computers, and multiple projects, then run 99% Rosetta on one machine, and 99% other project on the other... rather then 50/50 on both machines.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/