Quote Originally Posted by jcool View Post
Good idea! So we just run a batch of X WUs and check the completion times right?
Yes
If so, make sure to include enough WUs in the process so that highly multithreaded machines won't be half idle. Which presents a problem.. 24 WUs would be a good number for SP rigs, it's divisible by 8 (Core i5/i7), by 4 (i5 750 or older Quads), and by 12 (Gulftown). However, my Dual Gainestown as well as the Quad Opteron (16 Threads) would have an "idle problem" there.

So I'd suggest 24 "test"-WUs and just leaving the multi sockets out? Since most people crunch on single sockets.
Got it ... I messed up my calcs ... nice catch. Yes, 24 is a much better number of WUs to test although going to 48 gets us to an even divisor across all current and near future core count (1,2,3,4,6,8,12,16) but I can see where crunchers are going to be hard pressed to go down for 12 hours as it is so I think your suggestion of 24 is great.

I will be working on a basline for 24 HFCC WUs over the next couple of days and I will be trying to pick out WUs that are more or less uniform so there is not too much raw idle at the end. Oh ... Oh ... I need to go talk to Mr. Wizard ... why not build the set from the same exact WU ??? This way we could scale up or down as much as necessary to handle overall runtime and core count linearly. Looks like I'll have some crunching downtime next week as I work out the details of how to make this happen.

As a start, what elemtents do we want to capture?
CPU
vCore
vTT
CPU model
CPU Stepping
CPU Multi
CPU BLCK
QPI
Thread count (HT on/off)

DIMM
vDIMM
Amount
Speed
Channels (1, 2, 3)
Timings

HDD
SSD

Graphics

110 / 220

Headless