This is an excellent suggestion, and is exactly what I'd like to do. However, I tried it a few times, and upon client restart (which I open after I edit the config file to set the new CPU count), it loads the benchmark work unit with whatever the CPU setting happened to be when that work unit was downloaded. For example, if the work unit was downloaded with 16 threads, it doesn't matter what the cpus setting is in the config file. Upon re-launching, it will be folding with 16 threads. I tried with a 1, 2, 3, and 16 thread solve (work units downloaded with these settings). I let them finish, close the client, delete the FAHClient folder contents, paste the files from the benchmark folder, edit the config file to specify a different # of CPUs, and relaunch, only to find it running with the previous # of threads!PantherX wrote:Great write-up and I look forward to the comparison between SMT on and off.
Back when i7-860 was released, I tested it using the same WUs* to see if the HT on/off would make a difference. I discovered that there's a 12% to 25% reduction in TPF when going from 4 threads to 8 threads (IIRC).
I have two suggestions:
1) Can you please compare the TPF from the same WU*? IMO, PPD is great but what I look at is TPF as it provides a better representation. PPD will vary on internet speed and any server issues (fingers crossed, there won't be any outage).
2) You can capture 2 WUs*, one from a small Project (14677) and one from a large Project (14236) to see how good/bad project scales. Of course, there's nothing that's preventing you from capturing WUs from different atom ranges if you feel like it.
*Generally speaking, you can't predict what WU your system will get. However, once you get a WU from a Project you like, you can capture it for benchmarking to your heart's content without any hindrance to F@H. The method I used was in early V7 release and I assume that it still works:
1) Once you have spotted the elusive WU you want to capture, pause the CPU slot, copy the entire %AppData%\FAHClient folder (let's call it Benchmark)
2) Resume the CPU Slot and set it to Finish
3) After the CPU Slot has finished, disconnect the LAN cable (this is a fail safe step)
4) Exit the FAHClient
5) Copy the contents of %AppData%\FAHClient folder again (let's call this Live)
6) Delete the contents of %AppData%\FAHClient and copy of the contents of Benchmark into it
7) Modify the config.xml file as follows (I have made comments next to each setting that I think might help you achieve consistency with the highest optimization):8) Once you have finished benchmarking, exit FAHClient, delete the contents of %AppData%\FAHClient and then copy LiveCode: Select all
<config> <!-- Folding Core --> <checkpoint v='30'/> //Frequent checkpoints will slow down CPU processing. Setting it to the max will ensure the highest performance level <core-priority v='low'/> //Higher priority then idle ensure that any idle processes in Windows doesn't impact the CPU performance <!-- Slot Control --> <pause-on-start v='true'/> //This allows you to start-up the client and ready the system before you pull the trigger <power v='full'/> //Just in case to ensure that the client doesn't do anything funny <!-- User Information --> <user v='Benchmarking_In_Progress'/> //You can easily identify that this is a benchmark and not real WU. <!-- Work Unit Control --> <dump-after-deadline v='false'/> //You can now fold this WU way past the deadline if you want to. <next-unit-percentage v='100'/> //Prevents the FAHClient from disturbing the CPU folding at 99% <!-- Folding Slots --> <slot id='0' type='CPU'> <cpus v='4'/> //Start with 1 and use _r2w_ben's list of CPU values. </slot> </config>
9) Plug the LAN cable in and then start up FAHClient which should resume as if nothing ever happened.
Do note that if the WU was downloaded when the CPU had 16 CPUs, it will not run on any value higher than 16 in the Benchmark phase.
I hope this helps you out and you can speed up the workflow
Any thoughts?