In another thread (here) there is a suggestion for an opt in flag for certain large WUs.

I wonder if it would be useful to have a number of opt in flags that people could set. Some that come to my mind are

A) Wu with larger than average memory needs (as in the thread mentioned above)

B) Flag indicating willingness to use larger than average bandwidth for data-heavy science apps

C) Flag indicating willingness to use larger than average bandwidth to help debugging - the technical effect would be to download automatically the debug database file mentioned in recent tech news (scroll down to 28th March), and to have the client automatically delete the file when it is superseded by a higher version client.

D) Flag indicating willingness to use long running WU (where long running defined by theproject)

E) Flag indicating that the user wants only shorter than average WU (where short running defined by the project)

What all these have in common is that the scheduler would need to be aware of the flags when dishing out work. As far as I know this is as yet an unresolved wishlist item across BOINC generally, but in my view would be very useful both here and across other BOINC projects..

(D) and (E) would allow a user to select between short, average, or long running WU at the scheduler level rather than at run time. This would be useful on CPDN where a user could (if the project allowed) tick E to ask for BBC-length WU, or tick E to ask for slabs, or leave both unticked to get the standard sulphur WU.

In contrast, the recent mod to allow users to select the run time of the result has been done locally, and is specific to the way Rosetta works - it could not be ported across to CPDN for example to allow selection of long or short runs there. This is not a criticism of the recent mod - it made sense to expoit the flexibility of the Rosetta code in that way; it is just not a method that would work on most other projects.

If enough people here think there is merit in this suggestion, perhaps it could be passed on to the BOINC forums. I don't want to post the idea there immediately, as if nobody here likes it then there is not a lot of point pushing it further.

(A) has been argued for in the thread mentioned before. (B) is suggested to allow for future needs.

All of them are phrased in a way that is independent of the project, and there would be no requirement for a project to adopt all or any of them. Users could set the options even before projects were using them, and then the projects would know that there was (or was not) a large enough user base to exploit.

The precise implemetation of each option would be up to the project, but the BOINC scheduler would provide "hooks" by which different WU could be marked as suitable or unsuitable for each option.

Edit2add:

Perhaps the attributes would be held in two tables, one for workunit types and one for user prefs. The project team could set to Yes / No / Either on a type of workunit; and the user could set as Yes / No in their prefs. The attributes would be hard coded for efficiency, but if a project wanted to add one (tick here to ignore alien spam for example) it would be a simple change to the source.

(C) for example would generate more automated feedback than the current request to users to download the .pdb file manually. Some users just won't do it. Some users have boxes that are too far away to do this, but can flip a setting on the preferences page quite easily. Many users will forget (or not even know) that they need to download a new .pdb file when their app changes version number; those that do know and remember may well overlook the new version at least for a while.


What do people think - is this something worth asking the BOINC coders to consider, or should we refrain from giving them yet another job on their to-do and to-don't lists?

Rosetta project team: would you make use of such a facility if it existed ??

River~~

---

What do people think

I think it's a splendid idea! But I think that "keep it simple" is important too. It seems much of what you suggest the user to flag, is already available in the host information. It keeps history on your bandwidth up and down, and knows your memory, and I think it's pretty safe to assume that if ya got it, you'd be willing to use it (also, with the WU size preference, you already have good control on your bandwidth). And if you aren't willing to use it, the general preferences already allow you configure how much of your virtual storage you want to allow to BOINC, and how much disk and bandwidth.

Since the user can already (in Rosetta preferences) select how long they'd like to crunch, and the server already knows the bandwidth and memory, it would seem the server already has enough information to send WUs that are appropriate for the host's environment.

If additional choices are allowed, I'd suggest simply make two applications, and allow the user to opt in or out of each (just as WCG does with their Rosetta work, and AIDs project you can chose which to run, and both applications run under the WCG project). One would be low bandwidth, low memory WUs (assuming such a thing can be devised), and the other would be what we've got now. I think this would give you your "D" and "E" concept.

So far as the debugging flag, IMO that's best left for Ralph (the Rosetta alpha project).

I've been wondering, when the Rosetta application downloads, it seems a fair portion of the bulk is a file that probably contains the algorythms and/or hueristics to use. Would it be possible to break this into say 4 parts? And only update one at a time with an application change? That might reduce the new application version download by about 1/3. Or, if the file is more organized along the lines of 100 different approaches, for the case where 100 models are going to run, then it would be great if the initial install would just bring down 10 or 20 (thus only allowing shorter WU runtimes initially) and then bring down more with each project update. That would spread the download time across several interactions and really help the dialup users to get up and running quickly and easily.

I think the main problem is that if a person sets up a limiting configuration in the general preferences, the errors they get aren't very clear. I think each project website should have an applet download that examines your PC's environment, and "tests" whether it is appropriate for the project, BEFORE you install any software. Nothing worse than a dial-up user waiting half an hour for a sizeable download, only to install and have it fail saying your PC's too slow, or small, or old version of Windows, or whatever.

River~~ do you agree that the base information is already in the system? Or have I missed key points of your idea?

---

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/

I don't see the logic in having special-purpose flags for all these things. Only the "download extra debuging stuff" flag is a special function. Projects will always have needs that you haven't anticipated. (I didn't see "willing to run short deadline WUs" on your list, for example.)

The cruncher could simply have a pair of 32-bit words for each project. Each WU would also have a 32-bit word, and some simple logic could be used to see if that WU fits the crunchers requirements. That would allow up to 32 flags that are defined by the project.

Note that the cruncher has a *pair* of 32-bit words. That is very important. The bits of the second word would say if the corresponding bit of the first word is a soft or hard requirement. If no WU fits the cruncher's requirements, then a WU meeting only the hard requirements could be sent. If no WU meets the hard requirements, then no WU would be sent.

Actually, I was going to suggest the multiple application idea anyway. I think if people could opt in specifically to the cancer work, or to the HIV or malaria work, this might help motivate certain groups of people to come crunch for Rosetta.

This might help application stability too, because you can isolate any changes for the HIV work, for example, from those to the base Rosetta algorythms.

If some of these other projects that are coming down the pipe had a smaller memory footprint, then that would be the cat's meow! I think that would address the WU concerns and also attract more people to R@H.

---

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/

It would also help to have the application be able to send back the amount of ram on a system, so that larger WUs that require 512 Megs aren't being sent to the systems with only 256 Megs. Or Ram and number of cpus.. so two WUs that require 512 Megs aren't sent to a P4 /w HT turned on that only has 512 Megs of ram. Let us put the donated hardware to maximum use.. Graded by 256M, 384M, 512M - and trying to ignore the 8Megs that are eaten by some onboard graphics cards.

---

The issue is that when BOINC sees a PC which reports 512M, it doesn't know the TRUE memory demand of that PC by its owner throughout the day. That PC could be a "dedicated cruncher" PC, devoted 100% to BOINC projects, or it could be a PC that is used for other memory intensive tasks as #1 priority.

This issue is affecting few BOINC projects right now, namely Rosetta and CPDNs, because the rest have minimal RAM demands (1/10th or so).

I think a lot good ideas can be had by watching how F@H solved these problems, as I suggested in here, like "BigWU" and "advmethods".

---

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

I'm talking about machines that actually have ONLY 256 Megs of ram at present. (Half of the recommended minimum for the project.) They work fine for some WUs and have problems with others.

As for 512 Meg systems being used and pre-empting the Rosetta client; they've had trouble getting pre-emption to cause problems with the Ralph client; so now that we've got an updated Rosetta client, that problem should have disappeared as well.

My dedicated F@H machines have 256Megs/cpu core. So while I've seen those switches, I've never used them. But since we have to convince Boinc to update their code for switches to be passed from the computer's clients (Rosetta, Ralph, Climate Predication, etc) - it's best to ask for more than we need at present, since changes to Boinc aren't going to be instantly added when we or other projects are ready for other switches.

---

... I think each project website should have an applet download that examines your PC's environment, and "tests" whether it is appropriate for the project, BEFORE you install any software. Nothing worse than a dial-up user waiting half an hour for a sizeable download, only to install and have it fail saying your PC's too slow, or small, or old version of Windows, or whatever.
...

Only if the results of this applet can be overriden by the user. I'd get really unhappy if these two computers in my farm were prohibited from running Rosetta:

https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=69576

https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=73388

According to someone's completely arbitrary decision, they are not capable of running Rosetta, since they both use Win 98 SE (gasp) as their OS. I just don't think anyone has told these two systems, because they seem to work very reliably.

-- Edit -- forgot BOINC forums don't auto-parse URLs --

---

Only if the results of this applet can be overriden by the user.

Oh, I totally agree. My thought was just that the applet would be a diagnostic tool, or available as a reference on the signup page. I mean, if you were coaching a friend of yours... that had the same PCs... knowing what you know... how would you advise them? I'd tell them they are undersized, and that they shouldn't expect it to work.

The applet would just inform you where you don't meet the guidlines, or that you DO meet the guidelines. It would have no way to PREVENT you from going ahead and downloading Rosetta. I just meant to have a simple way for someone who knows nothing about how many Ghz or MB their machine has, to have it checked out FOR them. Part of that "make it easy" concept. "We suggest you click here to run the Rosetta@home assistent to check your system and confirm it meets these recommendations".

---

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/

River~~ do you agree that the base information is already in the system? Or have I missed key points of your idea?

No, because the base data I had in mind was about user preferences, not about technical stuff.

Two boxes, owned by different users, might be identical but the users might still want to give the project a lot of resource on one box, and only a lttle on the other.

Just one example: you do not know, for a broadband user, if they are on a small monthly download allowance (and would therefore resent extra bandwidth suddenly being used) or are on an unlimited connection. This is info that may well not be on the PC anywhere at all, only in their ISP's admin computer.

The main reason for my post was to find out if people think it would be useful to provide a BOINC-wide facility on which projects could build. What I am hearing is that folks think keeping it within a project is adequate at present. If that accurately reflects people's feelings then I won't take this idea across to the BOINC forums.

To answer some other points made in this thread:

Settings applet

The idea of a setting applet is a good one, it could be run automatically for new users to provide the best guess for the settings. The majority of users, asw e know, would leave the settings as they are. Some users who complain about the effect of the applet settings, and other users who just plain like twiddling, could the re-adjust the settings, as dgnuff suggests. There could be a manual feature to re-run the applet for users who total their system by twiddling.

Put it in the application?

Then how do you know which app to send to which client? The point of my post was to start thinking about the BOINC end of the process that would facilitate the provision of distinct applications from a single project. At present this is possible if the distinction is made on technical grounds (size of installed memory, speed of cpu) but not if the distinction responds to user feelings.

To be clear: yes, what I had in mind was to put the actual differences into different apps on the project, this would be the project end of providing the difference. But without having some input from the user, the project can never respond to user preference, or has to write its own code to do that (like WCG have done).

So my idea was one set of coding to do the flagging and selection of the WU instead of every project doing its own coding for that part of the choice.

Leave it to Ralph?

On this project, yes of course now we have Ralph everything should be tested there first.

We already have a request to mainstream Rosetta folk to download an extra debugging module to run alongside Rosetta, so that more info is reutrned when the app fails -- at present the way to implement that is a bit tekky, and will only be doen by a few dedicated people. On this and other projects, a user preference flag that indicates a willingness to lose bandiwdth reporting bugs would be a useful fallback for those odd bugs that escape the initial quality control.

Thanks to everyone for your responses
River~~

Hi,

I think it is needed to make such modification to BOINC and it is needed to differntiate on a per-host-basis. I have a 256 MB Laptop which can'T complete large WUs but my Standalone with 1 GB very well can (and should).

I'm not sure why in the general preferences ov BOINC it asks for maximum of VIRTUALLY memory usage, since virtual memory can be several GB even if you have only 256 MB PHYSICAL memory. This does not make sense to me.

Ideally one should be able to define on a per-host-basis:

a) maximum amount of PHYSICAL memory to be used
b) maximum amount of bandwidth to be transferred per day
c) maximum length of runtime for a WU (based on the benchmark this would give enough information to the project)

I agree it could also be done via flags as suggested by Rhiver and is perhaps even better for the average user if he just decides between, long, average and short WU, big, average and low mem usage, much, average and low traffic. Nevertheless than it depends on the scheduler to decide what is low mem usage on a 1 GB - Box and on a 256 MB Box.

---