Client Setup Optimization Questions

[dawhippersnapper]

I am running a few clients that I'm wondering how to setup to get the most out of them.
I'm running the 7.2.9 client on everything, most of my clients are on windows. I tried to setup bigadv options on a 32 thread (16 core) E7 (2 x e7-4830)xeon server, and I get fairly low 16k to 40k PPD on SMP, and have never picked up any bigadv units that I can tell. Do bigadv units go to windows clients? I also have a few 16 thread (8 core) xeon servers that I'd like to do bigadv on.

I have 2 Intel i7 2600k dev servers on centos that I get between 14 and 26k ppd on. Does that seem optimal?

I have another Intel i7 3770 desktop with a gtx 680 gpu on windows, I don't have any special options setup on it, and get about 50k to 60k ppd from it when idle.

Do memory speeds or timings change ppd much? I have most of my motherboards maxed out on memory, and keep the timings at the highest are said to be allowed from intel, even thought the sticks are rated much faster.

I saw one place via google search that some people ran a linux virtual machine to run the client on to get better performance (or bigadv), is there evidence to suggest this would be a benefit?

I have many more servers I could put clients on, but I'm worried about the power draw possibly tripping a breaker. I'm also thinking about writing a script for scheduling the clients running so that during peak hours I can pause the clients.

[7im]

Hello dawhippersnapper, welcome to the forum.

No BA on Windows.
Yes, linux gets slightly better PPD than Windows.
Faster memory speed helps, only slightly. GHz and core counts are the biggest factors.
Yes for Linux VMs, see first answer and second answer.
If scripting, look at using the command line only client described in the Linux Install Guide.

[Joe_H]

First, some answers to your bigadv questions. One year ago PG announced that requirements for bigadv were moving to requiring 16 actual cores. Deadlines were also shortened. Those requirements were put into place earlier this year. So your 8 core Xeons probably can not complete current bigadv WU's within the deadlines. Your 16 core server is probably below the speed threshold to complete WU's for bigadv within the preferred deadline based on reports from other folders. But, currently the only bigadv WU's available are being assigned to Linux based folding clients. I don't know if that will change in the future.

Assuming you have a passkey entered, others can comment on whether the points yield is within the normal range for your systems. For the time being, SMP is pretty much what your servers can contribute.

[dawhippersnapper]

Thanks for all of the info. I may attempt to setup a linux vm on the 16 core server and see if it does any good for a trial. I just did a little looking around and saw that the AMD server CPUs were doing way more PPD than comparably priced intel servers. I might have to make the next few server purchases AMD based for to be able to contribute a little more.

Most of my servers sit idle for a huge part of the day, and then based on cron job or user traffic have spikes. Before last month, I hadn't installed a folding client on any of my hardware since 2006, and magically went from 120,000 points to 2 million+. Seeing the jump in points has me motivated to try to contribute a lot more. http://kakaostats.com/dm.php?u=859159

Unfortunately the vast majority of my servers haven't required me to need to buy powerful CPUs, it's been more about storage and ram. I see what I can manage and possibly custom build some future servers to try to make them more powerful while meeting the other demands. I do have access to a huge amount of desktop workstations, but I'm going to guarantee that they'll trip breakers if I push them all to 100% cpu, plus that'd make for a huge electric bill. In two of my datacenter racks, electric usage is part of the "rent", but I only have 2 x 30 amp 240v drops on battery backup, so I have to worry about breakers tripping there too.

[jrweiss]

The "pause on battery" feature should work with the battery backups, if you can connect the UPS to the machine via USB.

[dawhippersnapper]

The "pause on battery" feature should work with the battery backups, if you can connect the UPS to the machine via USB.

I didn't mean for that purpose. We have two huge battery backups that are in line with a diesel generator and commercial power from two different substations, no usb connections. Right now I have the 240v lines coming into the racks into PDUs that I think will trip the breaker at 20amp draw per section. We sometimes come a little close (15 amps) per section, and I think putting the client onto some of the older servers that wouldn't amount to much more PPD would be a bad idea.

I do use the pause on battery feature for my desktop and main laptop. The desktop battery backup with USB works remarkably well. I have the APC Back-UPS XS 1000, it shows I draw about 280w with the intel 3770 at 3.9ghz on 4 cores, and the nvidia 680 superclocked+ with a gold rated 1000w PSU. I have a 17" Macbook Pro laptop with i7 CPU, but it gets about 4k PPD so I don't really ever run it, as it makes it too hot and drains the battery even while plugged in.

[bruce]

Be sure you get WRITTEN permission to run FAH from the owner of the servers (since it seems likely that you don't own them). It's for your own protection as much as FAH's.

FAH runs at an extremely low priority so if during those bursts of activitiy, there's enough foreground work to keep all/most of your CPUs busy, FAH will yield processor resources rapidly and resume work rapidly when there are idle periods -- as long as there's RAM enough to hold inactive FAH pages, and it doesn't sound like that's evern going to be a problem. I believe that running FAH on all of the CPUs will have almost zero impact on "essential work."

FAH GPUs, whether AMD or NVidia, is in transition. A new points plan has been proposed which will generally increase the points over what GPUs have been getting. (The plan is being tested but not formally in place yet so it might still undergo some changes.) Equal-points-for-equal-work GPUs do not support task priority or preemptive task switching and we know of some reports of perceptible screen lag when FAH is sharing the GPU with the screen drivers. I'd worry about that a lot more than CPU sharing during production hours, but you have to be the judge of that.

[dawhippersnapper]

I have gotten permission a long time ago (my boss is the owner), and I own some of them myself.

I tested out one of the beta units, the scoring was pretty crazy (183,000 ppd on one gtx 680 sc+). The priority of the FAH works remarkably well on CPU, I haven't noticed any difference at all on request times from servers that run FAH, but when doing some tasks like media encoding using all available cores, I'd rather pause CPU folding programmatically.

I do have to pause the GPU client on my desktop though when I want to use it. It may be a good feature to detect mouse movement as an option for GPU folding pausing that pops up a box that allows you to resume folding when you are ready, or resume after a certain amount of idle time.

[bruce]

I do have to pause the GPU client on my desktop though when I want to use it. It may be a good feature to detect mouse movement as an option for GPU folding pausing that pops up a box that allows you to resume folding when you are ready, or resume after a certain amount of idle time.

There has been talk of a new FAH screensaver. No details nor any anticipated date, but that's fundamentally what you're talking about.

[dawhippersnapper]

That makes more sense, I was over thinking it.

[Nathan_P]

Your E7 machine is running slow - my dual L5640 machine can get 45k even in windows and clocks are the same, with more cores you should be nearer 50-55k. However there have been some results posted on a couple of the team forums that have proven that for folding LGA1567 is not the best and can easily get beaten by much less powerful hardware. These are dedicated though and i'm guessing that your machine isn't. Would be interesting to see some frame times from when the machine is idle to see what you are getting

[dawhippersnapper]

Your E7 machine is running slow - my dual L5640 machine can get 45k even in windows and clocks are the same, with more cores you should be nearer 50-55k. However there have been some results posted on a couple of the team forums that have proven that for folding LGA1567 is not the best and can easily get beaten by much less powerful hardware. These are dedicated though and i'm guessing that your machine isn't. Would be interesting to see some frame times from when the machine is idle to see what you are getting

For this holiday slow down it's been doing a little better. Right now on a 6098 unit it's running at 5 minutes and 14 seconds TPF, and ~45k ppd. I've seen it get up to 60k on another WU wednesday evening. The normal total cpu load that it gets up to when FAH isn't running is ~10%, but that seems to drastically affect the PPD (mid 20s and sometimes lower).

[Joe_H]

The normal total cpu load that it gets up to when FAH isn't running is ~10%, but that seems to drastically affect the PPD (mid 20s and sometimes lower).

Yes, a low load can greatly impact the processing of SMP WU's as some threads get slowed down. The other threads spend time waiting on those slowed threads. Reducing the total threads assigned to folding in these cases can actually improve throughput, especially when some are being done on virtual cores from HT.

[PinHead]

I am running a few clients that I'm wondering how to setup to get the most out of them.
I'm running the 7.2.9 client on everything, most of my clients are on windows. I tried to setup bigadv options on a 32 thread (16 core) E7 (2 x e7-4830)xeon server, and I get fairly low 16k to 40k PPD on SMP

These values look incorrect ( even though windows will not receive BA ), does the slot on the 7.2.9 client for smp show as "smp:32" ? Unless that server is heavily loaded 24/7, then it might make sense.

[Napoleon]

If you're into tweaking, you might want to try smp:16 and check your logical CPU to physical core/CPU mapping using CoreInfo. Then you can use some app like Process Lasso to automatically enforce the affinity of the FahCore_??.exe process approriately. I do so to funnel floating point work and integer work on my 2C/4T machine, and I've found it's surprisingly effective, viewtopic.php?f=15&t=20543#p205366.

Of course, the scale is quite different in your case, but I believe the idea remains valid nevertheless. FAH will keep the 16 physical FPUs busy at all times, yet leaves you 16 free threads. If the normal workload happens to be integer intensive, you just might be lucky enough to wring good FPU/ALU concurrency out of your server.