Page 5 of 7

Re: Discussion: what is holding F@h back?

Posted: Sun Jun 03, 2012 7:58 am
by KMac
7im wrote:Easy to install is not synonymous with a setup page with 50 possible chech boxes...
A simple "Advanced Options" checkbox could easily hide 3/4 of those options while retaining simplicity of setup for more knowledgeable users.

Re: Discussion: what is holding F@h back?

Posted: Sun Jun 03, 2012 8:03 pm
by csvanefalk
In my opinion, the broken Python dependency that keeps the FaH Monitor AND Viewer from installing on Fedora (without hacks) should be addressed urgently. It seems to be a relatively simple fix, and would be a good thing for the community at large. The tools should install and run smoothly without the need for workarounds for the basic stuff.

EDIT: as Nathan_P pointed out, this affects other distros as well, making it even more relevant to see it fixed.

Re: Discussion: what is holding F@h back?

Posted: Sun Jun 03, 2012 8:16 pm
by Nathan_P
csvanefalk wrote:In my opinion, the broken Python dependency that keeps the FaH Monitor AND Viewer from installing on Fedora (without hacks) should be addressed urgently. It seems to be a relatively simple fix, and would be a good thing for the community at large. The tools should install and run smoothly without the need for workarounds for the basic stuff.

Its not just fedora thats affected, IIRC there are other distro's affected as well. A fully functioning v7 linux client is important but most linux people still use v6. Sorting out the mess that is the GPU whitelist should be an even bigger priority. Better communication with Donors is another - although this is better than in the past

Newbie comes along with shiny new gfx card, installs latest client, client doesn't work. Newbie finds this forum and realises his GPU doesn't work and uninstalls - Donor lost, probably forever.

Re: Discussion: what is holding F@h back?

Posted: Thu Jun 07, 2012 3:38 am
by gwildperson
From my perspective, F@h V7 is not living up to it's potential. When it was first described, it was supposed to be a platform with great potential on which lots of new features could be build. That may be true, but it's not happening. There are many, many things described in the V7 ticket system which would unhinder FAH by providing important capabilities. Several are really, really important, too, including some that work better in V4/v5/V6 than they do in V7. Many others are much less important. I'm sure if we worked at it, we could come up with even more enhancements, too, but I'm concerned about the ones that are already listed. Why has all progress been halted and what can be done to resume the progress that seemed to be going so well?

Re: Discussion: what is holding F@h back?

Posted: Thu Jun 07, 2012 5:02 pm
by 7im
As mentioned earlier, the Client software is not the only project in progress. The backend server software is being updated as well. They work hand in hand, so occasionally, the client work pauses while the server work catches up, or advances to prepare for the next stage of feature enhancements/bug fixes.

When making big changes, you occasionally need to step back and look at the bigger picture, and find/fix the resulting roadkill from those big changes. I.E. letting the ripples from the big splash subside so you can see where the smaller ripples (problems) remain. And those smaller ripples might not appear for a day, a week, a month. Allowing all of the changed processes to go through a regular cycle helps bring an small problems to the front.

Progress hasn't stopped. It's just taking place elsewhere at the moment. ;)

Re: Discussion: what is holding F@h back?

Posted: Mon Sep 17, 2012 4:12 am
by bruce
Frontiers wrote:I have a dream about clustering via Thunderbolt in next versions of SMP core.

Reasons are mostly economical, but partly hardware based
This quote formerly was in this topic and what followed was a discussion devoted to hardware. Since it was off-topic, I have moved that discussion to the hardware forum. If you're interested in that topic, you can find it here. viewtopic.php?f=38&t=22457

By the way, the FAH SMP core has intentionally had clustering capabilities disabled. Data transfers are memory to memory, so they're much faster than even Thunderbolt. Moreover, SMP does not run effectively unless all N CPUs are almost perfectly matched. Please read more from this forum regarding clustering.

Stanford may or may not enable all of the features of the next version of SMP. Personally, I'd like to see FAH use a version of Dynamic Load Balancing that could accommodate Asymmetrical MultiProcessing but that has never been mentioned as a high priority for FAH, and there's a long, long list of things that have been mentioned. I suspect that their current wish-list involves a backlog is most likely several years long and ASMP would probably be behind that, if ever.

That shouldn't stop any of us from dreaming, though.

Re: Discussion: what is holding F@h back?

Posted: Wed Dec 05, 2012 6:47 am
by Barry
Jesse_V wrote:2. Heat issues related to maximum hardware utilization. V7 utilizes everything by default. Everyone has a laptop here on campus, so this is a concern.
How about a built in temp monitor that pauses folding at a user defined temperature, with a pretty safe default pause-temp? Is there even a stand alone product that could do that?

Re: Discussion: what is holding F@h back?

Posted: Wed Dec 05, 2012 6:59 am
by csvanefalk
Barry wrote:
Jesse_V wrote:2. Heat issues related to maximum hardware utilization. V7 utilizes everything by default. Everyone has a laptop here on campus, so this is a concern.
How about a built in temp monitor that pauses folding at a user defined temperature, with a pretty safe default pause-temp? Is there even a stand alone product that could do that?
At least for Linux systems, you could probably write a script that does this. I say "probably" because I have never worked with the FaH client API, but assuming there is at least one method for setting FaH CPU usage (either by directly modding the config.xml file in general or modifying this value in particular) and one method for restarting the client (to reload settings), then it is straightforward. Python has bindings for lm-sensors, so what you do is simply to do periodic readings of temp, and then apply some simple logic after your own taste (depending on the level of scaling you want) for scaling CPU use accordingly. The same can be done for GPU if FaH supports setting max GPU usage (we don't have a GPU client for Linux, so I don't know unfortunately).

Re: Discussion: what is holding F@h back?

Posted: Wed Dec 05, 2012 7:25 am
by Stonecold
Barry wrote:
Jesse_V wrote:2. Heat issues related to maximum hardware utilization. V7 utilizes everything by default. Everyone has a laptop here on campus, so this is a concern.
How about a built in temp monitor that pauses folding at a user defined temperature, with a pretty safe default pause-temp? Is there even a stand alone product that could do that?
All modern CPUs have a built-in temperature sensor which shuts the computer down if it begins to overheat, but if you want something that only pauses folding without shutting down the computer, you could try CoreTemp. I haven't used Windows in a while but if I remember correctly CoreTemp has an option to run a command once a certain temperature is reached, so you may be able to have it run a batch file which safely pauses folding (otherwise you could just have a command which kills the client).

Re: Discussion: what is holding F@h back?

Posted: Wed Dec 05, 2012 7:37 am
by Stonecold
csvanefalk wrote:
Barry wrote:
Jesse_V wrote:2. Heat issues related to maximum hardware utilization. V7 utilizes everything by default. Everyone has a laptop here on campus, so this is a concern.
How about a built in temp monitor that pauses folding at a user defined temperature, with a pretty safe default pause-temp? Is there even a stand alone product that could do that?
At least for Linux systems, you could probably write a script that does this. I say "probably" because I have never worked with the FaH client API, but assuming there is at least one method for setting FaH CPU usage (either by directly modding the config.xml file in general or modifying this value in particular) and one method for restarting the client (to reload settings), then it is straightforward. Python has bindings for lm-sensors, so what you do is simply to do periodic readings of temp, and then apply some simple logic after your own taste (depending on the level of scaling you want) for scaling CPU use accordingly. The same can be done for GPU if FaH supports setting max GPU usage (we don't have a GPU client for Linux, so I don't know unfortunately).
FAH can't adjust CPU usage for SMP, but it can reduce the numbers of CPU cores being used (only uniprocessor clients can adjust the percentage of CPU usage). However AFAIK changing number of CPU cores used only takes effect when a new (FAH) core is downloaded.

Re: Discussion: what is holding F@h back?

Posted: Wed Dec 05, 2012 7:50 am
by csvanefalk
My mistake, I only saw this setting in passing (never used it) and wrongly concluded it applied to SMP as well.

Re: Discussion: what is holding F@h back?

Posted: Wed Dec 05, 2012 7:52 am
by csvanefalk
...have not looked into this (have to go to work soon), but you could possibly use the script with something like this instead to work around it: http://maketecheasier.com/limit-cpu-usa ... 2010/09/22

Re: Discussion: what is holding F@h back?

Posted: Wed Dec 05, 2012 8:04 am
by Jesse_V
Barry wrote:
Jesse_V wrote:2. Heat issues related to maximum hardware utilization. V7 utilizes everything by default. Everyone has a laptop here on campus, so this is a concern.
How about a built in temp monitor that pauses folding at a user defined temperature, with a pretty safe default pause-temp? Is there even a stand alone product that could do that?
There's a related ticket: https://fah-web.stanford.edu/projects/F ... ticket/634
csvanefalk wrote:
Barry wrote:
Jesse_V wrote:2. Heat issues related to maximum hardware utilization. V7 utilizes everything by default. Everyone has a laptop here on campus, so this is a concern.
How about a built in temp monitor that pauses folding at a user defined temperature, with a pretty safe default pause-temp? Is there even a stand alone product that could do that?
At least for Linux systems, you could probably write a script that does this. ...
In the Linux terminal, type the word "sensors". On my machine, it spits out the CPU temps.

Re: Discussion: what is holding F@h back?

Posted: Wed Dec 05, 2012 8:08 am
by csvanefalk
Yep, that is lm-sensors, it is this program I was referring to when I talked about the Python bindings.

Re: Discussion: what is holding F@h back?

Posted: Wed Dec 05, 2012 8:46 am
by artoar_11
Stonecold wrote:
FAH can't adjust CPU usage for SMP, but it can reduce the numbers of CPU cores being used (only uniprocessor clients can adjust the percentage of CPU usage). However AFAIK changing number of CPU cores used only takes effect when a new (FAH) core is downloaded.
When WU is in progress and you change number of coresĀ (-smp #), WU will continue from 0% (from the beginning). I have tried this a long time ago, and now I guess so.