Suggestions for v7

[uncle fuzzy]

The systray client manages that with a click on a "pause when finished" option. If v7 is headed away from consoles and towards a systray-type control interface, I expect to see that option.

[bollix47]

Thanks ... I should have specified the console version as that's all I use for my clients which are mostly run on Linux.

[7im]

One option I would like in the future is the ability to activate the oneunit flag without having to stop/restart the client.

e.g. Have a system variable that the client checks before downloading it's next WU.

FAH1unit=0 - carry on as if the -oneunit flag was not used
FAH1unit=1 - stop the client after current upload and before downloading the next WU as if the -oneunit flag had been given

This would avoid the need for a manual restart to add the -oneunit flag to the command line and possibly avoid some lost WUs or lost progress.

While your request may be a better short term workaround, I'd prefer to see them fix the problem, not the symptom. I'd like to seem them fix the client/fahcore so that stopping and restarting a WU doesn't increase the risk of loosing a WU.

When they allowed that to happen, they settled for the lesser to 2 evils, and they should have fixed both evils IMO.

@ Cordis, yes, the conclusion in your second post is one possible logical extension of what you read from the new post. A good guess that I agree may be likely, but still just a guess. However, in your original post you made is sound like someone told you inside information about the v7 client.

Which was it, a good guess or did you "hear" inside info? If you have inside info, we'd love to hear more!

[cordis]

@7sim - No, I have no inside info, I basically read the same blog you posted and made the assumptions I did, sorry if I led you to believe that I have more information. Perhaps 'heard' isn't the verb I should have used. I was more tentative about the suggestion just in case it was already a feature in the new tool that someone had seen. It's hard making suggestions for a tool that has such a vague spec, but I wanted to put it out there anyway in case somebody is listening. I suppose the feature doesn't really need a gui to be added, if we could edit the config file and it were checked before reloading the next WU, that would probably accomplish the goal. It would certainly be more ideal just having a button in a gui, but hey, I'll take what I can get. And certainly, it would be a lot better if to have higher reliability for shutdowns, definitely, but a 'stop after the running job' option would be great if you want to make sure you get the results back as soon as possible with the least amount of delay, which they appear to like.

But for future reference, don't ever assume that I have any inside data, just your average folding schlub, riding the waves of decisions that Pande makes and trying to hold on (and pay the power bills). I'd love to see weekly Pande Group internal development reports so I could plan ahead on farm development a little, but I'm not going to consult a lawyer over the latest blog entry or dissect forum posts like the Zabruder film. If I make a bad assumption, meh, I'll survive. If others read my posts, and make assumptions about what Pande is up to, well, yikes, sorry if I'm leading you on. Mostly, I think we should really just relax. OK?

[bruce]

\I'd love to see weekly Pande Group internal development reports so I could plan ahead on farm development a little, but I'm not going to consult a lawyer over the latest blog entry or dissect forum posts like the Zabruder film. If I make a bad assumption, meh, I'll survive. If others read my posts, and make assumptions about what Pande is up to, well, yikes, sorry if I'm leading you on. Mostly, I think we should really just relax. OK?

Excellent suggestion -- let's all just relax.

Yes, the internal development reports might be interesting, but they've never released anything like that so I doubt it's going to happen now.

As far as planning your farm let remind folks that we're talking about a new client. I'm sure I've said these things before, but I'll repeat them one more time.

The client is not the FahCore(s) that does the processing and it's not the WUs from the various Projects that they process. If a current FahCore has troubles shutting down and restarting, that same FahCore will have that same trouble when stopped/restarted by the v7 client. Development of the FahCores are handled independently from the client.

The client is an interface between you and the servers and the FahCores. We have to assume that it will have similar methods of specifying things like advmethods, gpu, bigadv, verbosity, oneunit...etc. (you, talking to the assignment servers) and that it will be able to download units, download FahCores, start a WU processing, upload the results, etc. (the client, talking to the servers and the FahCores)

This will be a total rewrite of the client. That means that it won't be a small, simple upgrade to the v6 client. When the v7 client is released, we're likely to find that it has a different look and feel. We're likely to find most or all of the present features, though we may find it has different way of communicating with us (and perhaps a different way of specifying "advmethods" or -gpu 1 or whatever). The client may have different ways of communicating with the servers or with the FahCores but as I said in the previous paragraph, the Projects, WUs, and FahCores won't be changing (at least not at the same time). PPD will not change. The limitation on bigadv for Linux will not change because of V7 -- that issue is entirely separate, based on a problem in FahCore_a3 that's being worked on by different people and it would only be a coincidence if both events happen at the same time.

V7 will still be getting WU assignments for SMP, for GPU, and for Classic projects. V7 won't change that -- and in any case, V6 will still be available. (If you choose, you can continue to do exactly what you're doing today.) As far as planning your farm is concerned, you should plan it exactly as you would plan it today.

[Lehabey]

- I wish there would be just a single client for CPU and GPU. After install it can run wizard and determine the best way to use your PC resources (GPU support). You can change settings later if needed of-course.

- Benchmark mode to see how your computer compares to others. It would help me decide if it makes sense to run F@H on my old PC.

- Better support for Linux such as rpms, GUIs and so on. It helps to automate startup and change settings.

- Download new task when current task is almost done. Helps to eliminate downtime spent on uploading and downloading. Perhaps it can also work in offline mode if my wireless disconnected because work units are predownloaded already.

- Show some sort of progress bar for project goals and estimated time left if possible.

Happy folding!

[PantherX]

Welcome to the F@H Forum Lehabey,

- I wish there would be just a single client for CPU and GPU. After install it can run wizard and determine the best way to use your PC resources (GPU support). You can change settings later if needed of-course.

That is the goal of v7 Client. (Link)

- Benchmark mode to see how your computer compares to others. It would help me decide if it makes sense to run F@H on my old PC.

A P4 can run a CPU Client without any issues. My guess is if it can run Windows XP, it may be able to fold by using the Classic Client (some may have to fold 24/7 to meet the Preferred Deadline) (response 1, response 2)

- Download new task when current task is almost done. Helps to eliminate downtime spent on uploading and downloading. Perhaps it can also work in offline mode if my wireless disconnected because work units are predownloaded already.

That is requested a lot of times and we can only hope that it is implemented in v7. A third party tool is available. The part in red would actually be bad for the Science as WUs get tied up. Each WU relies on its previous one to be generated hence you have to return them quickly for the Project to progress further.

- Better support for Linux such as rpms, GUIs and so on. It helps to automate startup and change settings.

Not sure about the underlined part, but Linux will play a more prominent role in F@H in future. (Link)

- Show some sort of progress bar for project goals and estimated time left if possible.

Not sure if I want PG to invest their very limited resources on a trivial matter. There are third party apps that can do the same thing, just visit the tools list.

[Zagen30]

- Benchmark mode to see how your computer compares to others. It would help me decide if it makes sense to run F@H on my old PC.

That's a fairly subjective issue. Some people don't care at all about power usage and will fold on anything they can get their hands on. Others have high energy costs and are very concerned about energy efficiency, and obviously there are all sorts of individuals in between. A P4, for instance, uses a lot of power and doesn't net very good PPD, so to some people it doesn't make sense to run one while to others it makes sense as long as it meets the deadlines.

- Show some sort of progress bar for project goals and estimated time left if possible.

Not sure if I want PG to invest their very limited resources on a trivial matter. There are third party apps that can do the same thing, just visit the tools list.

I think some sort of built-in client monitoring would be useful. I'm sure you've seen a lot of new contributors who refer to their computers' performance in terms of the number of minutes/frame, only they're talking about the frames that are displayed by the systray bubble, which are relatively meaningless in assessing overall performance. They don't have much else to go on initially since they don't know about the log files and there's no other noteworthy and readily apparent progress tracker built into the client.

[Lehabey]

Thank you for comments.
Perhaps one more thing which was probably suggested before: automatic update of the client to new versions.

[PantherX]

I too suggested the auto-update and this was the response:

...6) Not such a good idea. Client updates typically have new settings and new features, and so user intervention is typically needed. Auto updating a client could actually cause it to stop folding. That's a great way to kill product, not improve it. Look at the last update, v6.29. You would have had to add a passkey manually anyway to keep getting full points. Plus a lot of people had to add the -advmethods flag. Auto update can be just as hurtful as helpful. Until that changes, I'd like to see that functionality built in, but not implimented until they can make the upgrades not hurtful at any time...

Source

[KneeDeep]

[Given my shallow understanding of the underlying workings/controls/options of folding, my suggestions are brazen and bound to demonstrate some miss-understandings! Note that I'm folding in a Win7 environment [1055t+2GPU's & q6600+GPU]... not that I see where it changes any suggestions, below.]
__________________________________________

Move towards Dynamic Client Management: there are many [most?] client-options which should by variable without a stop/re-config/re-start cycle, although in some cases an auto-restart might be required.

Examples:
- halt on completion of current WU ["-oneunit"?] {And cancellation of that.}
- # of CPU's to use ["-smp N"]
- GPU loading [EnvVar "FUSH_INTERVAL=192"]

As many options as possible (and would be useful) should be made changeable; as time passes, more elegant ways of handling change could be written into the clients.

These changes should be remotely controllable so that one computer could easily request changes of another. Something like an extended HFM.NET could manage numerous systems and clients.

The first method that comes to mind uses the file-system -- better ideas will abound.
- Monitor for the presence of Change-Request file
- It's modification time-stamp would indicate its currency; file-unlocking (or a content-rule) would guarantee its integrity

In my case, I've so saturated my main, general purpose computer with CPU and 2xGPU folding, it's beginning to suffer when I go web-browsing or DVR'ing. I'd love to:
- have a scheduler reduce the main GPU load and release a core for Sunday night where I'm DVR'ing four channels, simultaneously.
- have a scheduler which would detune in sync with the A/V scan and the defrag.
- click a "button" and have a manager release some of the load when I want to browse; then just click and have things return to full loads.


'Nuff said. Put the hooks there, and someone will build the manager/scheduler....
__________________________________________

Improve client communication with the user. Suggest where users might improve their folding. We don't all have our snouts buried in the fora: we need to be -told- where we're failing, and/or given useful data to help us see there's a problem. [Thanks again, 7im, for helping me triple my PPD throughput!]

Toss in some useful clues amidst all the start-up verbiage [okay, my fault as I use "-verbosity 9]; send email, perhaps.

Examples:
- "You are an idiot with BROOK_YIELD null or zero: refer to ...."
- "Consider raising FLUSH_INTERVAL: refer to ...."
- "You are soooo wrong, turning off cpu-locking on the GPU!: reference ..."
- "Typical SMP PPD's for your CPU are ..."

Ahhh... but you're saying that last item was a trick! Read on if you, remain awake.
__________________________________________

Collect client h/w information: return info to Stanford with each WU and periodically crunch the numbers tp users can see what to expect from their h/w. Make some of this data easily available to users; consider pushing some of it back (at WU start-up? Or email?); learn from whoever's doing things right, and wrong.

Upon WU completion, return the CPU [e.g. "AMD1055t"], GPU ["r5750"] client ["SMP"], [and other?] points of interest. Then tabulate results so users can understand typical performance versus theirs. [Ignore RAM/CPU/CPU clock speeds and cores used as excess data?]

I'd recommend just listing the prior month's data, indexed in whatever way you find amusing: ClientId x relevant H/W?)
E.g.: (I'm betting someone can come up with a better presentation than below, particularly the grouping by deciles.)
- GPU: Fahcore_11 & radeon5750 - mean=2322ppd, max=4512ppd, distribution=2.1.1.2.1.1.1.1.0.0
- SMP: Fahcore_23 & AMD1055t - mean-3012ppd, max=7542ppd, distribution=2.1.1.3.1.0.1.1.0.0

[bruce]

[Given my shallow understanding of the underlying workings/controls/options of folding, my suggestions are brazen and bound to demonstrate some miss-understandings!

Just because somebody else has suggested an idea and been "shot down" previously doesn't mean it's a bad idea -- only that it's unlikely to happen soon. In fact, I get the distinct feeling that V7 is feature-frozen so suggestions in this topic either have already been implemented or are destined to happen someday in the future, if at all. Brazen ideas are often good ones, though.
__________________________________________

Move towards Dynamic Client Management: there are many [most?] client-options which should by variable without a stop/re-config/re-start cycle, although in some cases an auto-restart might be required.

Examples:
- halt on completion of current WU ["-oneunit"?] {And cancellation of that.}
- # of CPU's to use ["-smp N"]
- GPU loading [EnvVar "FUSH_INTERVAL=192"]

(a) The Windows systray client allows a degree of dynamic management, such as your -oneunit suggestion. (b) Changing the number of smp cores isn't simple and (at least) would require a restart of the FahCore. (c) The EnvVars were never intended as a permanent method of doing anything. We're all waiting for a new FahCore that optimizes those settings itself.
[Updates to the FahCores is asynchronous to an updated client and would happen automatically for all versions of the client.]

As many options as possible (and would be useful) should be made changeable; as time passes, more elegant ways of handling change could be written into the clients.

These changes should be remotely controllable so that one computer could easily request changes of another. Something like an extended HFM.NET could manage numerous systems and clients.

That's already a goal for new-client development, though we have no way of knowing how much of that goal will or will not be achieved in a particular version.

In my case, I've so saturated my main, general purpose computer with CPU and 2xGPU folding, it's beginning to suffer when I go web-browsing or DVR'ing. I'd love to:
- have a scheduler reduce the main GPU load and release a core for Sunday night where I'm DVR'ing four channels, simultaneously.
- have a scheduler which would detune in sync with the A/V scan and the defrag.
- click a "button" and have a manager release some of the load when I want to browse; then just click and have things return to full loads.

The fundamental problem here is that there are really no software tools to manage the GPU load. An Operating System has years of development and understands priority, memory demands, historic processing patterns, etc. and has a task scheduler that can optimize conflicting demands for resources. Historically, the GPU was designed to drive your display. Data was presented to it and it processed it FIFO taking as long as necessary before displaying that information on the screen. Even as the GPU began to take on other types of processing, conflicts for resources were still resolved by simply upgrading to faster hardware. There's still no practical way for FAH to determine if the GPU is busy rendering video or processing high-performance game data. I have not studied OpenCL -- it may include these types of managment routines, but only recently did FAH incorporate a manual time-slice management routine to provide a manual way of reducing temperatures.
__________________________________________

Your other ideas sound good but I expect they are out-of-scope for a project that's run mostly by biochemists, not computer scientists.

[KneeDeep]

(a) The Windows systray client allows a degree of dynamic management, such as your -oneunit suggestion.

We're in agreement; it's a nice feature, but an implementation which supports neither local nor remote-computer autonomous (software-driven) control.

(b) Changing the number of smp cores isn't simple and (at least) would require a restart of the FahCore.

Currently true (I presume), but I don't see it as intrinsically true. I suspect the cores-used count could be expanded or contracted at control points -- at times when the cores have been idled, such as at checkpointing moments -- with little additional complexity. [Yup... a naive expectation. ]

(c) The EnvVars were never intended as a permanent method of doing anything. We're all waiting for a new FahCore that optimizes those settings itself.

Again, to robustly state the obvious, as I tend to do: some variables reflect strategic decisions; how enthusiastic should we be about SkyNet making those decisions? My point was that at different hours or varying personal-use modes I'd want the strategies to favor my chaning interests: would there be an abstract way to direct that self-optimization? Flags for "Share GPU-1" or "Gimme a CPU"?

The fundamental problem here is that there are really no software tools to manage the GPU load.

Whole-heartedly agreed! Even the limited control we exert [BROOK_YIELD and FLUSH_INTERVAL] is ill-conceived [sorry, someone!] in that it impacts -all- GPU's on a multi-GPU system. [Hmmm, I guess one could slam different registry entries for the EnvVar before each GPU-start (yuck).] But, it's better than nothing.

Your other ideas sound good but I expect they are out-of-scope for a project that's run mostly by biochemists, not computer scientists.

As I muttered: put in the hooks and provide the data and there's a decent chance someone will make good use of it. Conversely, -don't- provide those and....

Thanks for your many fine posts, Steve! Your efforts are much appreciated...

[bruce]

(b) Changing the number of smp cores isn't simple and (at least) would require a restart of the FahCore.

Currently true (I presume), but I don't see it as intrinsically true. I suspect the cores-used count could be expanded or contracted at control points -- at times when the cores have been idled, such as at checkpointing moments -- with little additional complexity. [Yup... a naive expectation. ]

I suspect that when the SMP analysis initializes, it partitions memory in such a way that each thread can integrate 1/N of the atoms (or something equivalent to that). Reinitializing in the middle of a run is unlikely to be used by the (other) primary audience for gromacs -- namely researchers who run that code on their own systems, including clusters/super computers -- where changing hardware characteristics would be a relatively rare need that couldn't be handled by a simple restart. Doing it without a restart would be an issue primarily for gromacs.org, not for the Pande Group.

If the Pande Group implements such an option, I'm quite sure that they'd accept the change request and set up the parameters for a reconfigured system and then restart the core from the last checkpoint. V6 has a couple of options like that where the client does a STOP/RESTART on the core, resuming from the previous checkpoint.

[guest3412]

I am in agreement with several ideas, but I would like to add a few of my own:

1) a profile selector: where you can select a program, when it loads, pause the gpu client, set cpu to 25% (or whatever % user selectable) max use. The profile selector should be able to do any function from pausing the whole client to reducing how much the client can use of the cpu/gpu and should be able to do this on the fly with out any user interaction. - just like the gaming keyboard - G15? - it would be nice if there could be separate profiles, to be able to select, user nameable even (say gaming 1, gaming 2, movie, surfing web, ect) then when you select a game executable for the profile to load. when I watch a BD movie I have to shut down all my fah clients or I'll get a BSOD from time to time, I don't watch a movie every day, maybe once a week... but still for that 2hrs I have to shut down fah if I don't want to have to shutdown my system and recover from the BSOD.

2) incorporate functions from the fahmon, so you can see what % the client is at (both for the GPU and SMP, or each single CPU client). what ppd you are getting, what the deadline is for each work unit, both preferred and final deadline would be nice. If you really want to get some bonus points, you can list TPF current, average, min, max - for the current project (you could click on it like GPU-Z to change between them). Include the current points that the user has generated - with out having to go to my folding page. Include the amount of work units the smp, gpu, single core client - has finished.

3) when the user sets up their client for the first time, make suggestions based on questions of how the user uses their system, ie: dedicated folder, part time folder - 4,8, 12hrs/day, run during work hours only, run as service (so that it runs even when logged out), these should be options that the user can choose and change whenever. you could have a setup wizard, and an advanced setup, for people that run servers 24/7 and know what all that advanced stuff means can choose it through the gui. You should be able to dock the client in the sys tray.
If the user selects dedicated server and runs smp, but is too heavily using the computer to make the deadline, a notification balloon should pop up at the bottom, upon user return that they can click on or dismiss notifying them that they missed the preferred/final deadline, and they should consider a different setup. If they dismiss the notification, they should still see the message when they open the client, it should not be another intrusive message box they have to dismiss, but instead be a note on the screen they can see and click to re-run the wizard, or make advanced changes. The client should learn how the user uses their computer, by how much they are pausing the clients, or using cpu time and request appropriate work units with deadlines that would coincide with the average usage. just because today I used my computer more than usual, or was working on my computer with some issue, or upgrading it, should not affect the average greatly. neither should it if I am away from my computer for the whole day unusually. Deadline should have more time to complete than the average would allow, for instance, if the user completes a WU in 1hr, there should be a 24-36hr window for final deadline, if the WU is usually completed in 48hrs there should be at least a 60-72hr final deadline. preferred deadline should be at least the average, or the server should NOT send the WU. when first setting up a client and there is no average then the server should send a longest deadline project to benchmark. The local client should keep track of the average for that machine(at least 1 month), to offload any additional tracking, so the only thing the server has to do is decide what project to give the client with x deadline. since every project can have a different tpf the client can take that into account when computing the average for the project deadline. if the client determines that the assigned project can not be completed it should be able to request the server for a different deadline project if it knows it will be unable to complete the given project before final deadline.

4) When a WU server goes down, the client should be able to tell the assignment server that XXX.XXX.XXX.XXX is not responding, please re-route me, and receive a different WU server.
I had a discussion not so long ago with someone about this:

So the AS is supposed to keep up with what server is up and down? ok so when my client asks the AS for a WU server, and the AS gives it IP (A), then seconds later I ask it for a WU server again. Why would the AS continue to say IP (A) with out asking server at IP (A) if it is accepting? I would think that if the AS is repeatability asked by user X at ip X and machine X over and over for a WU server, that the AS would look up IP (A) and say "hey are you accepting?" And when it doesn't reply, make a note that it's down and not repeatably send me there, on the other hand it could be as simple as adding to the client an ability to tell the AS that "I can't reach that WU server, please try another" it just seems to me that it shouldn't be that hard to note that when a server goes down, that the clients can just ask for a different WU server. But I'm not a programmer, just a data analyst. I see things in different ways sometimes.

Nobody knows exactly how this works, but speaking as one who has done a moderate amount of programming I can see a couple of flaws in your suggestion.
First the AS doesn't keep track of who has asked it for an assignment or when. That would be a large amount of data to keep track of, and most of the time it would be useless. If I'm the information clerk in a sports stadium and somebody asks me where the restroom is, I judge whether they want the Men's room or the Women's room and direct them to where their needs will be met. This same process happens over and over. If somebody comes back and tells me that they need directions to a different one because that one is out of order, I'll gladly send them to a differnt one, but the client doesn't provide that information, so if they just come back and ask again, I'll (incorrectly) send them to the same place. Sooner or later I may learn that that restroom is out of order, and when I do, I'll send everybody to a different one. The only question here is how quickly I learn that the Men's server on Level 3-East is out of order or the Women's room on Level 2-West has a long line or there's no paper towels in Level 3-North.
Adding more complex software to the client is one possibility. Perhaps a better option would be for my employer to require me to check on the status of all of the restrooms in the stadium more frequently.

i understand your point now, but i guess since the client needs to be overhauled and v7 is coming .. maybe they will implement the client telling the AS that "i can't talk to ip xx and need another WU server" this shouldn't be that hard to implement based upon your description.

It doesn't do any good if a new client has a new feature to tell the AS something, if the AS isn't also upgraded to listen for the something. Clients and servers are often updated at the same time, but not always. ;)

Oh and yes, if someone thought that blocking a ip would help them get a wu they wanted, well you could always tell the AS to ask the WU server if it's up before assigning another WU server.

5) although unnecessary, it would be nice if the user could put in a custom skin on their gui client, firefox has really come up with some nice ones and it would be neat for sure to be able to use a custom skin! Think of it, the teams could make those and cokes you to be a member for the use of their skin? or just give them out and make them a publicity item. the floating balls that the protein map does, would make a interesting screen saver, but those truly interested in folding, do not wish to spare the cpu/gpu cycles for something that is relatively useless.