Suggestions for v7

[John Naylor]

I have two suggestions for v7:

1) Make the client's list of hardware IDs for GPUs a separate file, not integrated into the client exe. This could then be updated in the same way the cores are, when new GPUs are released. This happens far more frequently than client releases do, and as the main motivation for making the cores separate from the client was to allow them to be auto-updated more frequently (or allow more of them to be added without a client update), it seems that maybe we should do this for the GPU hardware ID data too. I realise that if OpenCL means the GPU has one core for all GPUs eventually this could become irrelevant, but in the meantime, it would be useful.

2) It often happens that client updates require user intervention due to changed settings so it is often said that auto-update for the clients as well as the cores is not feasible. With that in mind, would it be possible for the clients to at least have some kind of notification built in? Say when trying to download new units, the assignment server could check the client's version number (as it presumably does already, to enforce rules on minimum versions of clients for certain projects) and cause the client to issue an alert to the user if a newer client version is available.

[PantherX]

If it is too much ask, could you update your post with all the suggestions in this thread so that the programmer(s) who will visit will have all the requested features in a single neat pot and that would save time as he won't have to read the entire thread thus the possibility of overlooking a feature will be less.

Here are my suggestions:(FF@H = Future F@H)

1) There should be an option within the client itself to start with windows automatically and also an option to include a delay of X minutes.

2) Rather than remove the flags, in the Advance Tab, make all the flags available in a check-box style and each flag should have its own description.

3) A plug-in should be available so that FF@H Clients can have access to SpeedFan data (or any other temperature monitoring software) and there is a constant monitoring of the temperatures of the CPU. GPU, HDD, etc. If any of the temperature crosses a threshold (either default settings or user configured) than that client which is causing the overheating problem should either get paused or should exit (depends on the user's choice). If the client is paused, once the temperature reaches a safe level, it can automatically resume its work. If the client exits, then a message should be displayed on screen willing the user what client was exited at what time.

4) The client displays real-time stats about you.

5) There should be an option called "testing" where new users who just want to test the client and are not sure that they want to continue. With this option, "dummy" WUs should be assigned so that the user will see the effect the client has on the system. The dummy WUs should be available for GPU, SMP, UNI and also in Small, Medium, Large so that all possible combination are covered and the user will know what to expect form their system.

6) Rather than downloading and installing 3rd party apps, you can introduce the add-on feature just like Firefox. The main client is provided by PG and the add-ons are up to the user which to install from the available list that PG knows won't have a negative impact on the science.

7) The homepage of the FF@H should include a "virtual client" that will be installed upon user request and will tell you if your current system is capable enough of running F@H (like virtualmark) if not, a list of hardware that is preventing you from joining F@H should be displayed.

I really hope to see some of these features in the v7 Client. Also you may want to take a look at this thread to incorporate some amazing ideas (http://foldingforum.org/viewtopic.php?f=16&t=14027) Another idea that I came across the forum (can't remember the person):

Include the type and Machine ID when you hover the mouse over the icon in the taskbar

[7im]

1. can be done using a scheduled task. Is it really beneficial for fah to duplicate that functionality?

2. The standard switches can be added as check boxes, with mouse over descriptions. Advanced or new switches can still be added in the text box. I like it.

3. The plug-in suggestion is an interesting idea, but I don't like the idea of tying fah in to your overclocking setup. Too much potential for blaming fah for not shutting down your system, when it could actually be a speedfan or hardware issue.

4. Displaying real time data slows down the client. That it counter-intuitive to the design of the client. Use the links in the tray icon to get you stats.

5. Has been requested already, but providing so many different types of WUs seems redundant.

6. Like #3.

7. The very minimal requirements for folding with each client type are listed in the FAQs. Not sure this large programming task is worth the small benefit. Nice idea though.

8. Like the mouse over tray icon stuff, seen several requests on that too.

[John Naylor]

1) It may be possible with scheduled tasks, but as the client is aimed at everyone (including those who are rather less computer literate than the majority of members on the forum), having such an option built in would benefit the people who don't know how to use scheduled tasks and save those that do a few seconds on configuring each client

[7im]

1. is a "can't please everyone all the time" problem. Some people want fah in the startup, some people don't. Hard coding it one way or the other was easy. Making it selectable isn't as easy now with Vista/Win 7.

But I support adding that feature.

[John Naylor]

Maybe it could be implemented a different way... in the versions that have an installer maybe the question should be integrated into the installer rather than the client. Programs like CCleaner can disable startup entries without deleting them, which has the same effect (and works in exactly the same way for all versions of windows)... maybe this could be a way of getting around the issues with having it as an option in the client (i.e. have the installer create the startup entry regardless but then enable or disable the entry depending on the setting in the client). How this would be implemented in the console clients, I don't know

[Wrish]

1) When I installed the GPU client, it added itself to autostart without prompting me. The function is already there. A console client never does this, of course, because the console version is meant to be self-contained and run directly. But how hard is it to add a shortcut to Start Menu/Programs/Startup Items? Most systems do not require a delay to start up FAH, though a .bat file makes that possible for those special cases.

2) An improvement over the limited set of check boxes in the current systrays.

3) Modern CPUs and GPUs will automatically throttle or shut down at certain hardware temperatures. This is far more reliable than software monitoring, which requires a potentially unstable driver (needs to hook into the OS) and a table of temperatures matched to various hardware.

4) The console clients are livelier than the systray clients; adding some details to the systray would be helpful... in particular, machine ID numbers for those running multiple clients.

5) Don't reviewers attempt to use real work units anyway? The work mix changes over time, which makes a pre-selection of dummy units obsolete very quickly.

6) Firefox has add-ons because they integrate into the GUI or render engine. FAH doesn't need a formal add-on system if the integration isn't necessary. Plenty of details about the work units and progress are available from reading a work folder.

7) The client downloads are already small and they are free. I don't see how a virtual diagnostic client would help. If you want to know whether you can run GPGPU, download the GPU client and see if it starts. If you want to know every detail about the GPU installed in your computer, use GPU-z instead.

[PantherX]

Wrish @ autostarting GPU Client is something very odd as I have been installing the GPU Client on Windows Vista & 7 and never did the client add autostart.

I had some time to revise my ideas so here is an “improved” version: (no idea of the development and maintenance costs)

1) A plug-in could have potential problems as 7im pointed out so I suggest that you can use the official code by Nvidia which they use to measure the GPU temperature in their Nvidia System Monitor. That way all the codes are “ready” and “official” thus the user just have to set the temperature threshold and the rest is monitored by the client itself. If multiple clients are installed, it can systematically exit the client until the problematic one is found and a message is displayed to the user (same for ATI if it exists)

2) The “testing WUs” should be as close to real life as possible so I have thought of this scheme. In any Project the R0 C0 G0 should be the “testing WU”. PG could finish these WUs internally and when the project is over, they can be simply removed and when any new Project is added, its “testing WU” becomes online.

3) Any resources that is used up for displaying the eye-candy is a harmful to the project so instead of using the traditional polygon to render the image, they can opt for a newer method that uses points instead of polygon which will use much less resources and will work on a “modest hardware” (http://www.guru3d.com/news/pointillist-style-rendering/)

4) In the newer clients, troubleshooting should be present at least at a basic level. Eg. If the GPU client gets EUEs, it should be detected by the client itself and a window appears which states the error(s) found along with a list of possible causes and solutions and in the end a link to this forum. Also a link to MemtestG80 and StressCPU 2.0 be provided. Personally, I would like a automatic stress test to be initiated when error(s) are detected. If this test fails, it can warn the user that the system is unstable.

5) Bonus feature for the GPU Client would be awesome (it could use a similar formula as the SMP2) Also UNI Client could be getting the bonus system but in a completely different manner. The will be only 2 stages in which the bonus will apply.
Stage 1 – Submission of WU within 12 hours = 150 points.
Stage 2 – Submission of WU within 24 hours = 100 points.
Any WU beyond 24 hours will not get the bonus, instead will get the normal points. This way it will encourage the people to fold the WU faster instead of “taking their time” and the project could be completed faster.

6) The present F@H Client is capable of automatically updating the core. I would like to see the same for the client so it will be easy to upgrade. An option could be provided to disable this feature.

7) Introduce transfer cap. The client monitors how much it has downloaded and uploaded (including the failed attempts) and when it reaches the user defined limit, will exit by stating a simple message. It may sound like a trivial thing but for people with fixed quota for the internet usage, it will be a blessing in disguise.

[7im]

2) I already have testing WUs. I keep a copy of the fah folder from various client types, with various fahcore types. Then I configure each copy to ignore the deadlines, and to prompt for a connection. Then I can copy the client to any computer, and run that WU again, and not worry about it aborting, and not worry about it trying to send back to Stanford. I can compare the PPD from my first folding box (P3-800) running a Tinker WU to my top end machine.

It's a lot like how Tech Report does fah benchmarking, but I have SMP WUs too, in addition to just CPU work units. I think I still have a QMD WU stashed away somewhere...

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.

Same answer for #4. Looping in to a stress tester after a WU has failed is not productive. It could simply be a bad work unit, and looping in to a test serves no purpose but to waste time. I do agree the client needs better error capture, and error feedback, as in helpful error messages.

[John Naylor]

8) Add a warning to the client that if SMP mode is launched it will give large results files (and ignore the small/normal/big setting). Would prevent things like this from happening when SMP is no longer considered beta and is recommended for use by the masses.

[P5-133XL]

You all should realize that v7 is already in alpha testing According to Dr. Pande which typically means that it is feature-locked. Adding new non-trivial features/capabilities probably means a significant delay beyond the 1-2 month release deadline that Dr. Pande has already quoted.

[PantherX]

True. None of these features will make it in the BETA Stage but we are hoping that it will eventually make its way into the new V7.XX Client Versions. Also it does give PG an idea of what features the donors want hence they can make the Client better for all of us.

9) A F@H CPU Benchmark. The purpose of this is to check how long it takes to run a particular set of instructions and will allow the Servers to assign an appropriate WU. Those systems that are dedicated, overclocked and stable can run WUs that are not generally assigned to them i.e. we can shift from the traditional 8+ CPUs for bigadv to XGFLOPS and above will get them. That would more fair method and would be easy to tweak in the future when more variety of CPUs are released. We can also split the Projects into different categories of XGFLOPS and regardless of what model your CPU is, it will be assigned the appropriate WU based on the GFLOPS of your CPU.

10) Automatic download of new WU when the current WU has finished. The Completed WU can be uploaded to the Servers once the New WU has finished downloading.

[bruce]

9) A F@H CPU Benchmark. The purpose of this is to check how long it takes to run a particular set of instructions and will allow the Servers to assign an appropriate WU. Those systems that are dedicated, overclocked and stable can run WUs that are not generally assigned to them i.e. we can shift from the traditional 8+ CPUs for bigadv to XGFLOPS and above will get them. That would more fair method and would be easy to tweak in the future when more variety of CPUs are released. We can also split the Projects into different categories of XGFLOPS and regardless of what model your CPU is, it will be assigned the appropriate WU based on the GFLOPS of your CPU.

That may sound good on paper, but it has too many limitations. The V3 client had a feature like you describe but it was abandoned.

Any benchmark that runs concurrent with whatever else is running at the time is inherently inaccurate and subject to manipulation. (FAH cannot demand exclusive use of the resources during the benchmark.) Moreover such a system cannot be applied to machines which operate less than 24x7.

[PantherX]

Moreover such a system cannot be applied to machines which operate less than 24x7

That is exactly my target group. Dedicated folding machine that will be running at their maximum potential which will give PG the required result and make donors happy. However, you are correct about the limitations

[codysluder]

My computer at my office runs 45 hrs per week. A benchmark that gives me a WU based on my computer speed would give me assignments that I cannot complete.