Overclock.net › Forums › AMD › AMD Motherboards › ROG Crosshair VI overclocking thread
New Posts  All Forums:Forum Nav:

ROG Crosshair VI overclocking thread - Page 1129

post #11281 of 16926
Quote:
Originally Posted by lordzed83 View Post

what volts u on ?? Im one of people that got 3600 stable here from 3200 cl16 kit with crappy cl18.

Besides that cpu ?? and ram kit ?? Throw us a bone to go from biggrin.gif

I have been trying 3600 16-16-16-36-1T @ 1.45v My ram is G. Skill F4-3600C16-8GTZR (B-Die). So it is native 3600 but with 2T. No way to switch Command Rate on the Gaming K7 =/.

Also tried 112.5 BCLK with the same timings but I get E6 instead which seems to be a VGA Q-Code.

I've also tried both PCIe 1.0 and 2.0 without success.
Edited by Secret Dragoon - 4/24/17 at 3:23pm
post #11282 of 16926
Quote:
Originally Posted by Benus74 View Post

If you are able to run 2666Mhz with 14-34 timings, then you should be able to do 2933 at 16-38 as this would result in a similar true latency.

I get a 3b Q-code error when I try to set timings to 16-16-16-16-38.
post #11283 of 16926
Quote:
Originally Posted by lordzed83 View Post

Its getting better and better biggrin.gif if driver wont help deffo try volts. What memory speed You are on ?? In my case i can boot up with Soc 0.95 but found that anything below 1.125 under heavy load makes me loose performance or crash. Same with VDDP in my case helped with making oc stable where nothing else did.
Btw I'm using LLC2 auto gave me crash here and there not to mention i had to bump cvore so much i would idle at 1.46 tongue.gif

1.25 vcore with LLC3 @3.7GHz (currently using the stock cooler and although 3.8 @1.3v seems to also be stable with LLC3 the temps get too high)

I'm using 2666 14-14-14-34 on 1002 BIOS (so 1T) 1.35v dram and vboot dram. 2933 also works although with much looser timings (tried 18-16-16-38) so I'm sticking to 2666 for now waiting for may AGESA update.

With the stock driver and 60000 nvme idle timeout (also tried 1569325055) still got freezing but there's definitely an improvement over the samsung driver. Freezes happen much less frequently and also last a lot shorter (with the samsung driver the freezes sometimes lasted over 30 seconds). I'm gonna have to call it a day for now gotta wake up early tomorrow but hopefully this helps someone and maybe someone more knowledgeable is able to pinpoint the exact cause for this.

EDIT: So one last update. After checking the NVMe SMART information with CrystalDiskInfo I noticed that after all this testing and freezes the Controller Busy Time (0A) and Number of Error Information Log Entries (0F) values had risen (from 22 to 26 and 88 to 90 Decimal). Also I got a bunch of event viewer warnings at one point during a long freeze with the following description and with varying processes: The application \Device\HarddiskVolume4\Windows\System32\svchost.exe with process id 9724 stopped the removal or ejection for the device PCI\VEN_144D&DEV_A804&SUBSYS_A801144D&REV_00\4&2d380d55&0&0009. The ID matches with my Samsung 960 EVO 500gb.
Edited by ggdfdgd3 - 4/24/17 at 4:13pm
post #11284 of 16926
I reinstalled, and uninstalled, and reran the service program again and it finally went back to stock. thumb.gif
post #11285 of 16926
Quote:
Originally Posted by BUFUMAN View Post

ahh this was what i changed recently and recieved my Coldbug problems!!

Do you have the SPD reading issues too?
post #11286 of 16926
Quote:
Originally Posted by SpecChum View Post

Well, I do know that Aura controls the RGB lights by writing to SPD, you can probably guess the rest.

So, if that's right, not only does Aura break the lights on the motherboard, it has potential to knock out RGB RAM sticks.

Nice.

@elmor @Raja@ASUS

If my suspicions are correct I think you need to look into this...

Not sure how that thing works, as I didn't have experience with that yet.. But if there's anything writing into the SPD, then it's a very bad idea.
There can be a collision during the write cycle (with anything else trying to read SPD and switch the DDR4 pages) or a fault and the result is then an unpredictable corruption of SPD.
post #11287 of 16926
Quote:
Originally Posted by Mumak View Post

Sorry, just saw those screenshots from BIOS. That looks indeed wrong - probably a problem with readout of DIMM SPD EEPROM.
Can you please run a let's say 3 times HWiNFO in Debug Mode and attach the Debug Files produced? I will then check the raw data to see what's going on there.
You might also try to use the RW-Tools and dump SPD data a few times. Then check the difference - for a particular module the content should not change. And if you have the same modules then the raw data should differ only by serial numbers and checksum.

Ok, had to do it another way. Here are my debug files.

https://1drv.ms/f/s!AmnqYpEo4iX0gleDQe2JbyXMO7Qf
post #11288 of 16926
Quote:
Originally Posted by Mumak View Post

Not sure how that thing works, as I didn't have experience with that yet.. But if there's anything writing into the SPD, then it's a very bad idea.
There can be a collision during the write cycle (with anything else trying to read SPD and switch the DDR4 pages) or a fault and the result is then an unpredictable corruption of SPD.

G.Skill themselves say you must enable "DRAM SPD. Write" on Intel systems for their lighting software to work.

I presume Aura works in the same way since it looks like pretty identical software.
post #11289 of 16926
Quote:
Originally Posted by CeltPC View Post

Ok, had to do it another way. Here are my debug files.

https://1drv.ms/f/s!AmnqYpEo4iX0gleDQe2JbyXMO7Qf

Sorry to say, but those modules have a pretty badly messed up SPD..
post #11290 of 16926
Martin, do you know what's up with the T_sensor sometimes reading VRM temps instead of Socket temp? In BIOS it always just reads N/A and in Windows it sometimes switches to VRM, while temp 4-6 keep reading Socket.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: AMD Motherboards
Overclock.net › Forums › AMD › AMD Motherboards › ROG Crosshair VI overclocking thread