Folding Forum

7im wrote:A new class of client types for -cancer, -alzheimer, -parkinsons, etc. would be a nice addition.

Like any other client types, example -advmethods, using that option would state a preference for that class of work unit, but it would never be a guarantee to get those WUs.

And in the end, Stanford can still control the weighting of the server assignments, so if too much of one class is getting cherry-picked, they can rebalance with weights. Sure, it makes Assignment Server logic much more complicated, but hopefully some recent or future upgrades would have better support for something like this. I think it would raise donor participation / retention.

I definitely agree with this. I like the idea very much. Because most people who fold have a particular disease in mind, and when they find out that they don't get the WU associated to the disease as much as they'd like, they become turned off. So I think this will be a good thing to invite new contributors and keep existing ones.

I for one would love to see bigger/more expansive project descriptions (pretty pictures much appreciated) as it's always nice to know more about the immediate project you're currently wrangling with.

The same goes for a viewer, but if it could be made to show details and the graphical representation about the current project I'd be a happy camper.


Somewhat related thought: What about posting a "devblog" (a'la EVE devblogs) whenever there is a new PHD report coming out, pretty pictures and "simple" explanations to help alleviate "brain-freeze" from very sciency sentences


A big thanks for all the years of hard work goes out to both Pande Group and all the guys on the forums here and all the interest-group forums. Been here for years, haven't been showing my appreciation enough. So thanks!

Abyssal_Angel wrote:Somewhat related thought: What about posting a "devblog" (a'la EVE devblogs) whenever there is a new PHD report coming out, pretty pictures and "simple" explanations to help alleviate "brain-freeze" from very sciency sentences

You mean a simplified explanation whenever a new scientific publication comes out? Seems like they provide laymen summaries for most of the scientific publications (see the Papers page) and I've summarized many papers even further on the Wikipedia article, or are you talking about something different? I just don't understand. Also, feel free to open a thread on a confusing publication and I'm sure we'll be able to simplify it if you'd like. Still, I'll agree that it's important to have some of the achievements explained to all of us; we're not biochemists...

Jesse_V wrote:

orion wrote:

7im wrote:A new class of client types for -cancer, -alzheimer, -parkinsons, etc. would be a nice addition.

Like any other client types, example -advmethods, using that option would state a preference for that class of work unit, but it would never be a guarantee to get those WUs.

And in the end, Stanford can still control the weighting of the server assignments, so if too much of one class is getting cherry-picked, they can rebalance with weights. Sure, it makes Assignment Server logic much more complicated, but hopefully some recent or future upgrades would have better support for something like this. I think it would raise donor participation / retention.

I couldn't agree with you more with this idea 7im.

I've always thought, with the v7 client, that it would be nice for people to be able to click a button or add a flag for the type of research that they wanted their system to be doing. Allot, if not most, start to fold because they have a family member or a friend with a disease and they want to help out in those areas of research.

Your idea would allow these people to know that they are helping, yet give Stanford control of assignments.

Good idea. I think checkboxes are a pretty good option, rather than some flags. Adding flags to V7 isn't the most intuitive thing (pros and cons to that I guess), so I think checkboxes here are a pretty good idea since you can't screw up like you can with flags. I'm imagining something like this during the installation configuration, though of course you should be able to change it during runtime:

What would you like to work on? We will make reasonable efforts to give you the selected projects if we are actively pursuing such research.

• All of the below (recommended)
• Unsolved general problems in biochemistry
• Alzheimer's Disease (AD)
• Huntington's Disease (HD)
• Cancer
• Chagas Disease
• Malaria
• Osteogenesis Imperfecta (OI)
• Antibiotics (drug design)
• Parkinson's Disease (PD)
• Viruses (HIV and influenza)

Great idea! But I would keep the checklist limited to one choice. If you can choose multiple areas, everyone will choose cancer, Alzheimer's, HIV (interesting idea, mentioning HIV in Kasson's viral research would be a big boost in popularity for his research), Parkinson's and Huntington's. 'No one' will want to do Chagas WU's for example.

If I can only choose one area, let's say cancer,, the server checks if there are any cancer related WU's availabe (or the chance of me getting a cancer WU is higher). If not, I get a random WU from another research area.

Likely true.

Pick one disease, pick all diseases, or pick no disease (and do dev work with -adv, bigadv, beta, etc.)

Otherwise the AS logic gets too muddy.

VijayPande wrote:I've been thinking about bringing the screen saver back for GPUs . . .

I like the screensaver idea a lot. It should categorically hide any screen-lag problems because the GPU FahCore can be as efficient as you can make it while nobody is using the computer and by the time the desktop is displayed, FAH's GPU processing should be suspended, leaving the GPU free for process other work.

There have been two entirely different goals for the Viewer and a screensaver. The FAHViewer was designed to provide a scientifically accurate display of the current protein. It doesn't achieve that goal today, but there are already tickets addressing that goal. For FAHViewer on V6, that worked (more or less), but it consumed too many resources except perhaps on the PS3.

A totally different goal is to provide a simple screensaver containing a slideshow, where the image is either static or gets viewed from a different perspective with an update frequency comparable with other screen savers. DO NOT try to blend these two goals. We need both.

One of the problems with the old screensaver was the time required to stop/restart FAH's GPU processing quickly -- such as having somebody move the mouse just as soon as the screensaver starts to replace the image of the desktop with the image of a protein. That issue would still have to be addressed -- including how long it might take to switch from a FAH-dormant--desktop displayed to a dormant state to a FAH-and_screensaver-active-state and then to reverse that sequence.

IMHO, I don't see a need for a screensaver for SMP/Uni cores . . . just GPUs . . . and even that can get complicated if there are multiple GPUs or a PhysX device and a video device.

bruce wrote:

VijayPande wrote:I've been thinking about bringing the screen saver back for GPUs . . .

A totally different goal is to provide a simple screensaver containing a slideshow, where the image is either static or gets viewed from a different perspective with an update frequency comparable with other screen savers. DO NOT try to blend these two goals. We need both.

IMHO, I don't see a need for a screensaver for SMP/Uni cores . . . just GPUs . . . and even that can get complicated if there are multiple GPUs or a PhysX device and a video device.

I would be happy for a screensaver triggered client parameter rather than a fah screensaver.
I turn off my screens so a blank screensaver is fine by me... less resources going to waste.
Right, have the main GPU triggered off screensaver and the other 2,3,4 going full blast the rest of the time... though it should be user configurable.

I agree completely with the option to have a screensaver or "run only when idle for xx" option, and for the option to choose a particular disease.

I don't know if this is "holding FAH back", but I think a big opportunity for small cost would be a benchmarking client. Lack of proper test machines has already been touched on in this thread regarding how points values are assigned, and although I'm not a programmer I think modifying a client for benchmarking should be relatively easy.

The "benchmarking client" would be similar to the regular v7 with a few representative WUs embedded in the download. Instead of communicating with assignment servers the client would run some frames from the embedded WUs and output the time it took for the run. Many options (like username & team) would be greyed out. The community could use something like this to get better performance data and compare systems.

Most importantly, if it could be used at hardware review sites like Anandtech and Toms Hardware it would add a lot of free publicity for FAH along with useful data for upcoming hardware. I think FAH would definitely fit into their test suites when comparing what a processor or GPU can accomplish.

Not that much anecdotal evidence is required to pursue this, but I would like to offer by way of an example that a screensaver GPU client would likely get my wife to run FAH. And that's saying quite a bit considering how much she resents you guys for monopolizing my time.

It's interesting to see the support for the screensaver client. Last week I sent an quick email to Dr. Pande letting him know about this thread, and later I notified him about some of the reactions here to his GPU screensaver idea, and added my support for it. He then replied:

Hi,
I'd like to see it soon too, but this is very much a balancing act of delaying other things to make this happen. I'm cc-ing Joseph Coffland, lead programmer, on this one.

Joe: I agree with Jesse that this is a high priority. What do you think about an ETA? (say even just for Windows – since this would have to be OS specific)?

I've yet to hear hear anything from J. Coffland, but that of course doesn't mean that he hasn't replied to Dr. Pande. I completely understand his position, but I thought it was cool that he classified it as a "high priority" and just thought I'd note that here for you guys.

Since a screensaver would presumably not start folding until much after the initial configuration and after the user steps away from the computer, I'm wondering if or how startup errors and whatnot could be avoided beforehand. I guess I'll just have to wait and see!

A common theme that seems to be occuring and one that i have noticed on the top teams is donor retention. I have a fair idea of what causes it.

Losing interest - Lack of tangible benefits from the project
Cost of running/upgrading hardware.
Decisions made by PG regarding hardware and what WU they can run - Not saying the decision was the wrong one for the project but some people will see it as wrong
Involvment in the Decision making process - I know we have the DAB but what about the smaller teams, i Also get you can't include every team
Errors with WU failures etc, Current examples are the 76xx GPu projects and those 512 byte bigadv WUthat just keep cycling through
Lack of clients/cores for certain hardware - yes resources are limited but there are some very good coders on this project who would love to help
The points system - People have every opinion on it, all thinking that they are right. Is there a better way?

Nathan_P:

A common theme that seems to be occuring and one that i have noticed on the top teams is donor retention. I have a fair idea of what causes it.
Losing interest - Lack of tangible benefits from the project
Cost of running/upgrading hardware.

Absolutely. To help with this, I would recommend using the V7's "About Project" window.
This may be the only source of first-hand information to many donors.
It may help preserve interest with the project.

With respect to the "About Project" window, I propose that:
1. The window can be presented in multiple languages based on donor choice.
2. That the window contain general F@h news from the PG, as well as the project description.
3. That this information is refreshed every time a WU is downloaded.

My thoughts after folding for 6 years, which others have said above:

- V7 client may not be 100% intuitive, but it's a big step in the right direction for easy of installation and upgrade. The switches are still pretty obscure and probably should be listed for easy reference on the client.

- V7 client should contain some type of marketing feedback without having to come to this website/blog to find out what is happening. This place is only for the hardcore, not the average donor. Perhaps a "marketing manager" role needs to be assigned for someone to translate the bites, bytes and protein lingo into human speak that the average donor could understand and get excited about. The pick your disease option is a nice "marketing" type of enhancement ,as long as it's implemented in the GUI and NOT implemented using arcane switches.

- Points for older folders is an issue. I was once at folder #50 for the project and have fallen to 150 simply because I've been bit too often with hardware choices that were non-optimal a few months after acquisition. Vijay Pande's comments about GPU's being a "huge resource for FAH's scientific calculations" isn't exactly aligned with the points system (hello GPU-QRB?!? chirp, chirp). I've got $2000 worth of old GPU's burning a lot of power to produce a whopping 50,000 PPD--- the same $ investment today could buy 250,000PPD++ worth of multi socket SMP folding. Look at Atlas Folder's once mighty GPU farm being easily thrashed by SMP machines with mega QRB's. (Honestly, after writing out this paragraph, I fail to understand why I keep burning the GPU's... anyone know why?)

I'd also throw out the idea of a points multiplier incentive for older folders to keep them interested. It wouldn't have to be much, just a token of appreciation for sticking around (random thought: 1% bonus per WU for each month of contribution)

- JP

@JPinTO: +1 GPU QRB needed badly!

It is interesting to note that F@h's number of active clients have grown quite linearly over time. (Proof in this pic) At the same time, our FLOP count hasn't increased in the same way. If you look at our petaFLOP milestones, you'll see there was massive growth there during 2007-2009, but then something happened, and it took nearly three whole years to increase another petaFLOP. I don't know, but I can see something is happening here. I'd speculate that it's gotten less exciting and new. Clearly research takes a long time, but most people must have very short-term attention spans, or we'd still be experiencing the same level of growth that the project did several years ago. Not sure what can be done to entirely solve that, but I think there are many ideas here that may help. I also know that PS3's and GPU's contribute more towards FLOPS than CPUs do, so that's some indication that CPU folding has been preferable, but I haven't seen any long-term graph of the growth of each client so that's just guesswork.

I also like Jorge1950's and JPinTO's idea of more news and updates in the V7 client, I'd support that as well. I also like how there are much more links to folding.typepad.com from folding.stanford.edu now than there were before the website revamp, that helps.

The Points FAQs explain the reasoning behind the QRB:

Certain projects require substantially more computer resources than others, either in terms of more disk space, more network transfer, or more RAM used. By default, these work units are given out to clients that opt in to request them. To reward those contributors for donating resources beyond the typical client, we currently give bonus points for these larger work units.

The bonus points are a reward for contributing more resources to FAH, and so you should not be surprised if these work units impact system performance and use the full resources of the computer.

The utilization of abnormal amounts of computing resources? An impact of system performance? I'm actually very pleased with how the SMP client performs, but it seems to me that GPU folding more appropriately falls under these statements. There's a recent thread in which jwyount is trying to decide on bigadv, SMP, or GPU folding based on PPD/watt and PPD/cost criteria. Currently GPU folding doesn't appear to be winning the decision, and search on Google gives many, many other examples. Points mean something. IMO, if Dr. Pande would like to see more GPU folding, not only do we need to address the system impact aspects using a screensaver or other options, but we need a point incentive. Adding the QRB to GPUs would of course add to the points inflation problem that some have been bringing up here, so as always the decision will have to balance the pros and cons. I'm also voting for it though.