Page 1 of 1

Goodbye

Posted: Fri Jun 02, 2017 7:43 am
by MondoVman
I'm unplugging FAH after 3 years and an incessant overheated single cpu Toshiba running MS Vista.
I *should* have an option to limit my cpu to a 50% load, but no, FAH engineering pegs my cpu to 100%.
Ridiculous.
Algorithm: Compute for awhile. Rest. Repeat. <--- pretty simple, young people, pretty simple.

Re: Goodbye

Posted: Mon Jun 05, 2017 1:55 pm
by toTOW
FAH uses the CPU, this is how it is designed to work ...

If your system is overheating, the solution is to improve cooling. FAH is not to blame here, a 3D game (or any intensive compute intensive application) will have the same effect as FAH, so the solution will be the same again.

Re: Goodbye

Posted: Mon Jun 05, 2017 3:11 pm
by rwh202
MondoVman wrote:Algorithm: Compute for awhile. Rest. Repeat. <--- pretty simple, young people, pretty simple.
= thermal cycling, fatigue and premature hardware failure...
I wonder why they didn't implement that? (Actually, it was done for GPUs then discontinued)

If a computer can't run at 100% load then it's unsuitable for computing. Either increase cooling capacity or reduce voltage / frequency.

Re: Goodbye

Posted: Mon Jun 05, 2017 3:16 pm
by foldy
I don't know what type of CPU or GPU you have but for multi-core CPUs the FAH client can be adjusted to only use as many cores as you like. And GPU power usage can be limited with tools like MSI Afterburner, so a 50% load is feasible.

Re: Goodbye

Posted: Mon Jun 05, 2017 4:10 pm
by JimboPalmer
I write computer programs, each is speed limited by something, some operate as fast as the hard disk can move data, some operate as fast as the CPU can execute instructions, some run as fast as RAM memory can fetch or store data, some run as fast as the operator can type, etc. But each is limited by something. (If I wrote for F@H, I would have GPU programs limited by the PCI-E bus)
I am old enough I wrote programs limited by floppy disk speed and by 110 baud serial port speeds, which are no longer issues.

F@H does not ask for operator input, and does not use much hard disk bandwidth. The clever designers have minimized time waiting to send and receive WUs over the internet. As the complexity of the proteins has advanced, so has the size of new CPU caches, so F@H is not as bound by RAM as you might suspect. (One reason older CPUs are so much slower is smaller cache sizes, so they become RAM speed limited) So often F@H is running as fast as your CPU can complete instructions. One reason A7 cores are faster than A4 cores is they use newer, more powerful instructions on new CPUs. On older CPUs, A7 is less impressive. while many modern CPUs can automatically throttle back if they encounter high temperatures, they do not throttle back to avoid high temps.

A fast video card working on a simple protein may spend a large fraction of a WU not limited by the GPU. PCI-E Bus speeds, CPU set up routines, more cores than atoms to simulate, etc. may lower GPU utilization. In some ideal future F@H may be able to partition the GPU for multiple tasks, but few cards have even taken baby steps toward that. (Dynamic load balancing scheduling system. This allows the scheduler to dynamically adjust the amount of the GPU assigned to multiple tasks, ensuring that the GPU remains saturated with work except when there is no more work that can safely be distributed to distribute. Nvidia therefore has safely enabled asynchronous compute in Pascal's driver. https://en.wikipedia.org/wiki/Pascal_(m ... hitecture) may help F@H in the future )

So it is not easy or simple to slow a computer by doing less work. (it is easy to do less useful work, but that won't produce less power) rapid heating and cooling inherently means rapid expansion and contraction, so not only may one not use less power, if you do, your computer may not last as long.

Re: Goodbye

Posted: Mon Jun 05, 2017 9:02 pm
by bruce
That's a excellent post, JimboPalmer.

I'd add a couple of really minor statements.

1) If your CPU supports N threads It's likely that the portion of the chip that does floating point operations is shared between two threads. (Intel calls it HyperThreading) For most (non-FAH) programs, the that part of the CPU is idle or close to idle, so two threads can share that circuitry without limiting anything. On the other hand, a single FAHCore thread can keep the FPU busy maybe ~90% of the time, so sharing two FAH threads doesn't gain as much000000 performance as you might expect since the total can not exceed 100%.

2) In most cases, GPU folding is actually limited both by the limits of the GPU's compute circuitry ("shaders") and the PciE bus, but only one at a time. During initial setup, there's a short time while the shaders are waiting for work to arrive. (In the grand scheme of things, that time doesn't matter much.) Later, data can be cached sufficiently that the shaders can be kept busy except for brief interruptions while the FAHCore may be switching from force calculations to coordinating between threads.or error checking or whatever. Traditionally, that's a few percent of the time or even less, so we ignore it and expect the shaders to stay 100% utilized. The rub comes when the shaders are fast enough to outrun the data being supplied and an increasing amount of time is spent waiting for data. If you put enough fast shaders to work, you simply may not be able to cache enough data to keep them all busy all of the time. Then, too, it is dependent on the characteristics of the particular project (how many atoms and other factors).
rwh202 wrote:I wonder why they didn't implement that? (Actually, it was done for GPUs then discontinued)
Built-in cycling of the GPU to reduce utilization has it's problems. There's no easy one-size-fits-all answer. It varies too much with the speed of the GPU and the characteristics of the project and is hampered by the data caching aspects of the FAHCore.