aaaah that explains a lot :)
Collecting thread is up here lads : SB FPO Batch collecting thread
Will add every nite the new listed CPU's into the Excell file
Printable View
aaaah that explains a lot :)
Collecting thread is up here lads : SB FPO Batch collecting thread
Will add every nite the new listed CPU's into the Excell file
That is a great idea. We can create a nice data base of info.:up:
yeah I like it like that, simple file you can print it out, go to the shop and try to find ya batch or similar performance....
Now we need more results !!
Good job :up:Quote:
Originally Posted by Leeghoofd
Hey guys fill it up, spescially those with C-batch harry up. We need a good overview to figuer out Intel's new Batch-business.
Most chips seams to B-batch in this round, in countrary with last rounds. I'm wondring if C-batch is the way to go, but we need more data to comfirm it.
2600K #L041B741, Biostar TP67XE, Noctua NH-U12P with push/pull.
WPrime 1024M load:
http://i695.photobucket.com/albums/v...prime1024M.png
WPrime 1024M idle:
http://i695.photobucket.com/albums/v...e1024Midle.png
Nice nice nice !!!!Quote:
Originally Posted by PolRoger
Can u pass Linx with that setup ? Care to share some settings ? I'm at 4.8 at the same voltage and slightly higher temps.
This is batch L040B208 2600K at 5G at 1.370v bios with level1 Load-Line Cal enabled. This is in my torture rack case which has twin remote rad cooling loops. Prime95 blend was ran for a little over 4 hours at 1.370 v core/1080 QPI/VTT smooth as silk. RealTemp readings are correct with EasyTune6 showing slightly higher.
Another great OC there flesh !!!Quote:
Originally Posted by flesheatinvirus
Could you fire that up and run TMonitor while Prime95 is blending ? I'm curious to see if Prime95 is being throttled. Thanks!
Thanks again. I like that little program TMonitor. What version is that? I will give it shot.
1.031 - http://www.cpuid.com/medias/files/so...nitor_1031.zipQuote:
Originally Posted by flesheatinvirus
I've not used this TMonitor program until yesterday, but I was wondering what would the graph look like during throttling? Every few seconds I am getting 1-3 bars dropping off in the graph, and sometimes I see a core drop to 1600 mhz but its only for like 1-2 seconds max. Do you think the CPU is actually throttling due to heat or due to waiting on a workload? This is when running prime95. I've set the options in my UEFI (P8P67 Deluxe) to allow for a higher than default TDP.Quote:
Originally Posted by ugotd8
EDIT: I'll add that when looking with ThrottleStop, FID sticks at the multi I have set the whole time I am running prime.
I just ran a quick test with new wPrime version 2.04 while running a multi reading log with TMonitor and saw no change at all. I do not like the new version wprime as it only loaded my cores up 50% during the 1024m test. I will also try version 1.55 My mistake, did not load all the cores up.
I see the periodic drops in TMonitor too, but I have my doubts if they're real. I don't see them when using RealTemp or ThrottleStop(monitoring).
I have seen it a couple times here but not really that much of an issue and performance seems fine.
Yes, I too see periodic drops. I'm talking about steady core speed drops. For example when I lead the TDP values to default in BIOS, then fire up Linx, core speeds drop from 4800MHz to 4200Mhz.Quote:
Originally Posted by bmg
What I'm getting at here is a rather off-the-wall theory that I could "dial-in" my TDP levels so that Linx, Cincebench (and lightwave) don't throttle, but Prime95 does hence passes. I'm working on my long held assumption that Linpack and Prime have nothing to do with real world usage, and as long as my lightwave renderer never throttles and I can get my OC to pass Linx and Prime that way, I'm golden.
Feel free to tell me how full-of-xxxx I am. :-)
ThrottleStop is awesome, thanks for that. Much less extraneous load during benching/stability testing. The FID column sticks just as you said. Not as pretty as TMonitor, but I like it better. Thanks again.Quote:
Originally Posted by korruptedone
I haven't stressed with Prime95/LinX yet... but most likely it will need a couple bumps vcore increase. I was using vcore "offset" +100, DRAM at 1600 9-9-9-24 @1.625v all other voltages set to default. BIOS PLL voltage overide set to enabled.Quote:
Originally Posted by ugotd8
L040B208 with 1.37v load for Prime @ 5GHz is looking very good! How much vcore does your other chip L042B208 need for 5GHz?Quote:
Originally Posted by flesheatinvirus
Thanks much. Actually I not even tried the L042B208 yet, waiting for the new board which should be here tomorrow, no dual channel on this board. I am hoping it will be similar to the L040B. I also snagged some nice Gskill 17066 in the 7-10-7-27 flav which should scale nice. I ran 3DM01 again for the fist time in years only to be surprised like everyone else how well Sandy scales, reminds me of my old Wolfy E8600. I will test that chip out with in a couple days and post all findings as well as some bench pics.
For some odd reason cpu-z is reading only 3400mhz lol... All my other monitors r saying 4700 and i run 1meg super pi in 7.xxx seconds ... hrmm?
Wow, quite a gem there. I need +180 or about 1.44V load for 5GHz. Temps jump to mid to 70's so fast I just stop the test.Quote:
Originally Posted by PolRoger
Just picked up a different cooler, and tried using way less thermal paste, we'll see how that goes.
Very nice oc and batch Alex-Ro! :D I asked a shop here today if they had that batch, and they had it! :D They will send it tomorrow so I should have it in 2 days. I also bought gigabyte p67 ud4 and Noctua U12P-SE2
If you look at the microarchitectural papers for Sandy Bridge(SNB) there's a decoded uOp cache which allows micro-ops to be cached off and allow the decode unit to be turned off if it isn't needed. This is rather important because for "smoke tests" like LinX and Prime95 try to keep very small loops that fit completely within the L1 instruction cache because historically execution units and caches are where most speed paths lie, so the harder you pound those units, the more likely you're able to destabilize the system.Quote:
Originally Posted by Venom-Crusher
However, it appears the caches and execution units in SNB are robust, so the weakness appears to be in the decode stage, which is rather complex for x86 parts. The uOp cache in SNB allows the decode stage to be turned off for tight loops, and any instabilities in the decode stage will only be exposed once you run a program that doesn't fit in cache and requires constant instruction decode like 3DMark.
I think there needs to be an amendment to SNB stability and that would be to run some sort of large program such as 3DMark, etc.
I think you need to install SP1 with AVX,then run latest linpack and see what happens. :clap: Kaboom;)
One problem with 3D mark is when your processor is unlocked it reports the wrong freq. I did two tests @ 5000 with my 2600KQuote:
Originally Posted by famish99
3D Mark 11.
Vantage
Both reported CPU @ 3400.
Not sure what the 2500K reports.
It's not that it reports the wrong freq, but that's what your base clock before turbo is. It's also possible that 3dmark isn't able to stress the clock all the way up.Quote:
Originally Posted by crossg
Nevertheless, the need for a non-loop intensive stress test is necessary to make sure you don't get chokes from the decode. I assure you this isn't an easy job; there are teams of people in semiconductor companies involved with just creating tests to break the system, a team which I am a member of ;)