New
#401
i980x @ 4.00GHz, Corsair Dominator GT - 6GB, Corsair SATA III SSD (256GB)
Still looking for that stupidly elusive 7.9 on the CPU =/
Sorry...don't know why I keep putting corsair for the SSD - it's crucial. Probably just easier to type after typing it for memory
I've knocked at the door of 5GHz and I don't think it's feasible, unless there's some other component contributing to the encoding subscore portion of the CPU score. By my estimation it will take an OC to over 6GHz to get it there...not really comfortable doing that (and my wife would probably kill me!).
As an FYI, the encoding needs to complete in about 0.55s for it to qualify for a 7.9 whereas at 4.7 it's 0.86s. 1.37 * 4.7 = 6.44. My suspicion is that there's some other component incorrectly included in the score. Beyond that, the subscore isn't necessarily friendly to 980xs or really anything that's quad core + HT as the encoder will not use more than 4 threads when encoding.
Yeah, I know you don't get a 1:1 increase in speed with thread count, but it would assist, although to be fair, the sample file that's used for the test is quite small.
There are LN2 people at around 5.7 ghz who have gotten 7.9. Could possibly have been fluke but hard to say, I believe some microsoft post on channel 9 saying 7.9 will take 8 cores. I've now had my 980 over 5ghz and still 7.8.
It would be nice to see the number on the screen I guess but I don't much care anymore, an overall score in the 6's even is plenty to have a great windows 7 experience. (probably less)
Yeah, from what I can tell, core count beyond four is irrelevant. As I said, mine "fails" to hit a 7.9 even at 4.00 solely due to the encoding test. This test, from my reading, is limited to using 4 threads...again, there isn't necessarily a linear performance gain in thread count, but the long and short of it is, unless the wm encoder is changed to support more threads, it's a pretty bad/useless/irrelvant test IMO.
Therefore I deem mine a 7.9* :) (kinda like Canseco!)
Edit:
I also opened up procmon and noticed that it's actually writing the file to disk when doing the encoding rather than doing it solely in memory. So now we're working with (potentially) three components rather than just two necessary ones. If this disk write time is included, anything going on during the test has a chance of skewing it greatly. I suspect it is the case because I see a lot of substantially different measurements ranging from around 0.80ish to 0.95ish between same clock speed executions.