![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Means the world to fast uniprocessor and dual core clients who can't quite make the deadlines on SMP units. However running four of them on a Q6600 will not out produce a single SMP WU. From a design/point fairness perspective, you don't want four of them producing better than a single SMP instance in the first place.
Yes, it's on advmethods only at the moment.
, thats on 6 cores at 3.5Ghz running 24/7. an older quad or dual core would be better with uni if they can get these new WUSlow Dual Cores and slow AMD Quads sure (probably), but even a stock clocked Q6600 will do better by sticking with normal SMP WUs. I haven't seen these new 10114's yet (you referred to) but my X3220's (same as a Q6600) at 2.4 GHz were getting 4800 PPD on 6701's (Linux) before I shut my farm down. There is no way a Uni project with QRB will ever generate 1200 points/unit on the same hardware to justify running four of them.
Well, I have a dual Opteron 280 (4 cores) @2.8GHz with two GPU clients, and it was doing about 21-25min TPF on a P670x. This machine has been processing a P10113 for the last 24 hours and has completed 29% as of this writing. TPF with this machine doing nothing else except running the GPU clients is a bit over 45 minutes. When I'm on the machine doing my usual stuff the TPF shoots to nearly an hour. I've seen PPD as low as 1300.
Well, I have a dual Opteron 280 (4 cores) @2.8GHz with two GPU clients, and it was doing about 21-25min TPF on a P670x. This machine has been processing a P10113 for the last 24 hours and has completed 29% as of this writing. TPF with this machine doing nothing else except running the GPU clients is a bit over 45 minutes. When I'm on the machine doing my usual stuff the TPF shoots to nearly an hour. I've seen PPD as low as 1300.
Another consideration is that these WUs do not seem as stable. I had one crash which I recovered from but this machine never gets any SMP crashes, and I was very surprised when I saw that, especially in winter.
Sorry for the misunderstanding. I reread my post before I saw your reply and I realize I made it hastily and wasn't completely clear.
Considering how many uniprocessor projects are out there, you'd be taking a pretty big gamble trying to get a 10436 or 10437. If you have an SMP rig that can make SMP deadlines, there is no reason to run multiple uniprocessor units.
[19:29:14] Completed 500000 out of 500000 steps (100%)
[19:29:15] DynamicWrapper: Finished Work Unit: sleep=10000
[19:29:25]
[19:29:25] Finished Work Unit:
[19:29:25] - Reading up to 3698352 from "work/wudata_08.trr": Read 3698352
[19:29:25] trr file hash check passed.
[19:29:25] edr file hash check passed.
[19:29:25] logfile size: 56954
[19:29:25] Leaving Run
[19:29:26] - Writing 3791266 bytes of core data to disk...
[19:29:26] ... Done.
[19:29:28] - Shutting down core
[19:29:28]
[19:29:28] Folding@home Core Shutdown: FINISHED_UNIT
[19:29:32] CoreStatus = 64 (100)
[19:29:32] Unit 8 finished with 94 percent of time to deadline remaining.
[19:29:32] Updated performance fraction: 0.932935
[19:29:32] Sending work to server
[19:29:32] Project: 6070 (Run 0, Clone 129, Gen 205)
[19:29:32] + Attempting to send results [March 15 19:29:32 UTC]
[19:29:32] - Reading file work/wuresults_08.dat from core
[19:29:32] (Read 3791266 bytes from disk)
[19:29:32] Connecting to http://171.64.65.54:8080/
[19:29:46] Posted data.
[19:29:46] Initial: 0000; - Uploaded at ~246 kB/s
[19:29:47] - Averaged speed for that direction ~247 kB/s
[19:29:47] + Results successfully sent
[19:29:47] Thank you for your contribution to Folding@Home.
[19:29:47] + Number of Units Completed: 622
[19:29:51] Trying to send all finished work units
[19:29:51] + No unsent completed units remaining.
[19:29:51] - Preparing to get new work unit...
[19:29:51] Cleaning up work directory
[19:29:51] + Attempting to get work packet
[19:29:51] Passkey found
[19:29:51] - Will indicate memory of 3995 MB
[19:29:51] - Connecting to assignment server
[19:29:51] Connecting to http://assign.stanford.edu:8080/
[19:29:52] Posted data.
[19:29:52] Initial: 40AB; - Successful: assigned to (171.64.65.81).
[19:29:52] + News From Folding@Home: Welcome to Folding@Home
[19:29:52] Loaded queue successfully.
[19:29:52] Sent data
[19:29:52] Connecting to http://171.64.65.81:8080/
[19:29:52] Posted data.
[19:29:52] Initial: 0000; - Receiving payload (expected size: 206471)
[19:29:53] - Downloaded at ~201 kB/s
[19:29:53] - Averaged speed for that direction ~248 kB/s
[19:29:53] + Received work.
[19:29:53] Trying to send all finished work units
[19:29:53] + No unsent completed units remaining.
[19:29:53] + Closed connections
[19:29:53]
[19:29:53] + Processing work unit
[19:29:53] A4 will attempt to use 4 threads.
[19:29:53] Core required: FahCore_a4.exe
[19:29:53] Core not found.
[19:29:53] - Core is not present or corrupted.
[19:29:53] - Attempting to download new core...
[19:29:53] + Downloading new core: FahCore_a4.exe
[19:29:53] Downloading core (/~pande/Win32/x86/Core_a4.fah from www.stanford.edu)
[19:29:53] Initial: AFDE; + 10240 bytes downloaded
[19:30:05] Initial: EBF8; + 3028899 bytes downloaded
[19:30:05] Verifying core Core_a4.fah...
[19:30:05] Signature is VALID
[19:30:05]
[19:30:05] Trying to unzip core FahCore_a4.exe
[19:30:07] Decompressed FahCore_a4.exe (10057216 bytes) successfully
[19:30:12] + Core successfully engaged
[19:30:17]
[19:30:17] + Processing work unit
[19:30:17] A4 will attempt to use 4 threads.
[19:30:17] Core required: FahCore_a4.exe
[19:30:17] Core found.
[19:30:17] Working on queue slot 09 [March 15 19:30:17 UTC]
[19:30:17] + Working ...
[19:30:17] - Calling '.\FahCore_a4.exe -dir work/ -nice 19 -suffix 09 -np 4 -checkpoint 15 -service -verbose -lifeline 2928 -version 634'
[19:30:17]
[19:30:17] *------------------------------*
[19:30:17] Folding@Home Gromacs GB Core
[19:30:17] Version 2.27 (Dec. 15, 2010)
[19:30:17]
[19:30:17] Preparing to commence simulation
[19:30:17] - Looking at optimizations...
[19:30:17] - Created dyn
[19:30:17] - Files status OK
[19:30:17] - Expanded 205959 -> 421644 (decompressed 204.7 percent)
[19:30:17] Called DecompressByteArray: compressed_data_size=205959 data_size=421644, decompressed_data_size=421644 diff=0
[19:30:17] - Digital signature verified
[19:30:17]
[19:30:17] Project: 10437 (Run 1959, Clone 0, Gen 0)
[19:30:17]Yeah, because the A4 core is now a universal core that can run on as many threads as you tell it. As you see in the line above, it is spawning 4 threads and should be using all of your CPU.
Yes, by accident. I disabled this now.Tobit said:
Probably p10437 which is a multi-threaded A4 project released about a month ago.
Sounds like a p7200 which, I thought, was still in beta. Haven't seen an official announcement yet stating it had been moved to public or advmethods. I just asked the developer about this.
Sounds like a p7200 which, I thought, was still in beta. Haven't seen an official announcement yet stating it had been moved to public or advmethods. I just asked the developer about this.
PPD wise, I am surprised you are taking that big of a hit.