Printable View
Welcome:D. But yeah, they messed up pretty much with 780's and Phenoms. 790's aren't too pricey anymore though;).Quote:
Originally Posted by Meatwad
Anyway, bah, after 1.5 hours of messing around idle it froze up. So rebooted and dropped Vimc from 1.3 to 1.2V, priming now again. Not for 8h+ though, just an hour or so. After that Ill let it idle again and see what happens.
To even suggest that is not right m8....consider deleting your post man. To advise someone to deliberately damage hardware to get an RMA is just not right.Quote:
Originally Posted by Jaivan
LOL, I'm not happy with my DFI-M2R, BIOS ,AOD incompatibility, MEM/NB instability, you name it..., doesn't mean I will blow out the mobo just to have a replacement, simply I put it out of my recommendations.Quote:
Originally Posted by Jaivan
As Tony says, is not right thing to do.
:down:
Wouldn't it be better to run something like F@H client to stress test the CPU? Prime only runs through an integer process with no SSEs doesn't it? In other words it is an old test made for old 286s or earlier.Quote:
Originally Posted by Rammsteiner
I am running F@H GPU CLient 2 (Ver 6.11 beta 2) and the CPU client (ver 5.03) both at the same time and they are loading up the GPU and two cores. The Task manager is showing a +50% CPU usage at the moment. I am only running at stock speed, however.
Orthos will use a gromacs core with the StressCPU option, that ought to be similar to F@H. F@H stressing isn't recommended. If you're doing it to test stability, you're gambling with WU's, they'd rather you run the client with a stable system so that they receive usable data.Quote:
Originally Posted by Majmac
Thx for that, Ill use Orthos. Hopefully it wont freeze as a matter of incompatibility as it happened with my 6400 X2 (the system froze after 3~4 hours while it ran Prime without problems and was solid as a rock lol).
I hope Orthos stresses the CPU more than Prime then:cool:.
@Tony......You carry weight with DFI and have direct contact with Oskar could you pretty please with sugar on top make a suggestion to Oskar to look into and fix the non AMD Overdrive Support issue with our boards Bios?;)
AOD does actually work, once the OC gets high thats when issues set in.
I don't see why it would. Orthos runs Prime95. It also only spawns up to two threads, so you'd need multiple copies for a quad.Quote:
Originally Posted by Rammsteiner
Use the 25.x series of Prime95 builds:
ftp://mersenne.org/gimps/p95v255a.zip
If you really want to stress your CPU, set it up to use small FFTs and match the memory usage to a core's share of the on-chip cache of whatever processor you're testing.
What would you say is the highest you can get one of these processors to run at, super stable, and reasonably safe, on a TRUE with decent airflow?
Since the OP is on liquid... Id like to know if you could run this at 3.5 on good air? (I run my Q6600 a 3.6 on air, and its stable at 3.8 on air)
stable and safe, i would say 3.2ghz on air without going to high on voltages
Well Oskar must be sending you special Bios then because AOD locks up the PC at random just opening the Program up! Now with current AOD it shuts it down just by opening it up NO Oveclocking Done what so ever and defaults loaded in Bios. There most certainly is a Issue with this Board and AMD Overdrive!:yepp:Quote:
Originally Posted by Tony
works for me manQuote:
Originally Posted by Brother Esau
http://www.ocztechnologyforum.com/st...er_AOD_DFI.png
High voltages and Phenom do not go hand in had. Mine's running 3G at 65°C-70°C fully aircooled outside a case (Noctua + 120mm). Voltage is set on 1,4V if I'm not mistaken.Quote:
Originally Posted by Manicdan
i do agree here tony but still there is no WARNING on any of on the product pages about blowing out MOSFETS etc when you put a 125W on a 95W board, :confused:Quote:
Originally Posted by Tony
what is you temp reader?, Everest is kind out of sync with the rest of the utilitys my phenom is 80c after Everest, but in AMD OverDrive its 46c :rofl:Quote:
Originally Posted by massman
AOD sets your ram voltage to 1.8V at startup (beside cpu voltages), that might not work with your timings.Quote:
Originally Posted by Brother Esau
Lol,i need 1.4V for 2.4GHz NB here. How far could you push the NB frequency?Quote:
Originally Posted by Tony
Looking at my testings it seems higher cpu frequencies make only sense if the nb frequency is ~500MHz below. You mentioned that already.
The original point was that prime is only an integer test, and doesn't stress SSE instructions. Orthos can also test using StressCPU, which uses a gromacs core similar to F@H SMP. On my machine, my computer draws 5-10W more using StressCPU over small FFTS.Quote:
Originally Posted by Particle
AMD Overdrive :)Quote:
Originally Posted by wiak
Might be bios issue, haven't tested it on version 1.4 yet
Ive been using a stress test program that Ive never seen heat up CPU's like anything else before...It also tests multiple parts of the CPU, and shows it for individual tests. It also tests RAM and HDD....Quote:
Originally Posted by ryboto
S&M stress test.... is the name and it will automatically detect any number of cores on startup..so you dont have to run multiple versions of it, and it stresses the cores simultaneously.
Lets just say when it hits the FPU tests...Ive seen it heat up CPU's 7-10C hotter than ORTHOS or P95 would...
It will error out when there is instability also.
can easily get it from Hirens BootCD in windows, using the wintools section of the CD.
Did a little evening testing; effect of NB frequency on CPU score 3D06 using 4-4-3-12 1T DDR800 Vs 5-6-6-18 2T DDR1066
http://www.ocztechnologyforum.com/st...37;20clock.PNG
I will go more in depth for part2 on TTR but this shows all is not quite what you would think, with regard to 3D06 anyway ;)
1066 was far from linear, DDR800 1T performed exactly as i thought it would.
Also using the new beta for the DFI the HT clocking is broken, you have 2000MHZ or lower, higher values do not work. On the MSI running HT=NB clock I saw performance increases.
:up: Now that is an odd result. Can it be that you had too less nb vid applied at 2200MHz and 2400MHz. I'm shooting into dark here but maybe some internal error correction is in the way here.
Another thing is max async latency. This memory timing has an big impact on everset memory benchmark. Using an higher memory voltage resulted in an lower max async latency. I skimmed over the BKDG and found that it's value gets optimized at start with some pattern testings.
Don't have the DFI and 9850 running, testing 4850e in M3A but i found those setup screenies from my previous tests.
2.8/2.2GHz: MAL 56ns
http://www.abload.de/thumb/setup4j5.jpg
2.8/2.4GHz: MAL 59ns
http://www.abload.de/thumb/setupx9s.jpg
Between reboots at the same settings MAL differs at about 1ns, the other 2ns difference must be caused by the different NB speed.
Does the 1T setting work on the DFI for you? I allways have to use memset for that.
Quote:
Originally Posted by Tony
Tony, there is a "New" 4/16/2008 Beta up on DFI Site I am actually on it now.
Was this posted here already?
Asus M3N-HT with 9850 at 3.4GHz.
http://forums.overclockzone.com/foru...19#post2536519
Found it on hwbot.org.