Since I'm more of a "set it and leave it" guy when it comes to OC, I'm curious to know if there are any benefits to using the beta BIOS compared to the public 1002 release? I'm sure there is some small things that really help those that are constantly tweaking, but is there anything to get from them in regards to stable over time OC?
Was "some time" longer than 60 seconds? Maybe increasing the timeout value even further would be the solution? It's possible to change the range of values accepted through the registry too though I'm not sure if windows would actually use a value that's over the default range. To uncap the value range you need to change ValueMax to 0xffffffff after which the timeout values can be set to 1569325055 milliseconds (~18 days). Here's the updated .reg files that do this too:
NVMeIdleTimeoutRegistryTweaksv2.zip 2k .zip file
Gonna try this myself now and continue testing, hopefully this is it so there would be one less thing to worry about
After some more testing sadly I've confirmed the stuttering still isn't completely gone. I did however notice something I hadn't noticed before; I got a warning in RealBench just when the stuttering started about running low on ram and something about the pagefile. I was running with "Up to 16GB RAM" (have 32gb) I'm gonna try temporarily disabling the page file next and see if that fixes it.
Hey guys, I'm far from being a highly talented OC'er as my only recent experience is with this Ryzen build (so about 3 weeks) but I see many people asking for some Memory OC guides, and I haven't really seen a post yet to describe how to define correct timings for memory OC using DOCP profile without change BCLK.
Again, I'm not expert, but this has worked for me so far, and so, I wanted to share and see if maybe it could help some of you.
I've put together that google doc to show how the calculation works, you can copy it and make updates to the yellow boxes. Google Doc
This is based on the paper from crucial and the fact that the BIOS prefer odd numbers when you get over 2666MHz DRAM frequency.
Before you start, make sure to clear CMOS so that you don't get failed POST with PState OC which would cause very high voltage to your CPU !!
The way the spreadsheet works is that you have to put the initial timings and max Module Speed in the yellow boxes, and then it'll give you what timings to try for other DOCP profiles.
You can simply try the various DOCP profiles from the Extreme Tweaker BIOS page.
Before selecting your DOCP profile, make sure to put the advertised voltage for your kit in the VDRAM, in my case 1.35V.
Also, make sure to set your VDDSOC to at least 0.95V as it helps for memory training.
Some of the more guru guys here will tell you 0.95V is not much and you could go to the 1.15V but I'm kind of trying to keep my voltages as low as possible.
Then select the one that you can get to boot up with no changes to the timings until it fails to POST.
When it fails to POST make sure to put your latest good memory OC based on DOCP profile, and then go to the Memory Timings section of the BIOS to see what timings it got to work with.
Put those timings in the yellow boxes.
In my case for instance, I've got a G.Skill F4-3600C16Q-32GTZR kit (4*8GB) and I can boot 26666 using CL 16-39 max, after that it wouldn't POST.
Then based on the calculation, to boot at 2933 I would have to put the 18-18-18-44 timings.
To boot at 3200 I would have to put 20-20-20-48 timings.
As there is no DOCP profile to boot at 3433 nor 3600, I haven't tried the other timings yet.
So what I've done is that I've put my DOCP Profile for 3200Mhz without using BCLK, and then put the correct timings, save, and it works
The only issue you can get after that is that you could get cold boot issues, but then using the correct ProcODT should solve the problem (I still need to try it, didn't have time this week-end)
For me using 3200Mhz has a real advantage over 2666Mhz when compiling very large code base (a 15% speed increase).
As noted by many, there is probably something going on with the infinity fabric and memory bus speed.
Wendell from TechLevel1 made an attempt to explain this and how to tweak memory timings in this video:
In fact my spreadsheet was very much inspired after seeing that video
I hope it'll help
Originally Posted by Spartoi
What is faster/better for Ryzen:
2933Mhz with 18-18-18-18-38 timings
2666Mhz with 14-14-14-14-34 timings
I was able to OC my RAM using the same settings after upadting my BIOS to 0082. I lowered SOC Voltage to 1.1V though. For future reference, if trying to OC further to 3200Mhz, should the ProcODT settings be decreased, increased, or does it not matter anymore?
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.
Originally Posted by psychok9
Hello! I would buy Ryzen but only with >3200/32GB Memory.
I've seen on 1st page some 32/64GB @ 3200MHz without BCLK with G.skill memory. Finally can we get it?
You can easily get to 3200Mhz by releasing timings like shown in the spreadsheet above.
To release timings you'll have to go to the Extreme Tweaker page of the BIOS and enter timings by hand.
Having the correct ProcODT is still going to require some manual tweaking and checking, so you'll need to try for yourself.
Originally Posted by psychok9
Thank you for sharing your experience. Can't you get 3200Mhz without changing BCLK?
I don't like it because CPU Infinity Fabric get clocks from memory speed but without BCLK.
I've got the second one and can get 3200Mhz with the timings from the spreadsheet.
If you're luckier than me and have a better piece of silicon then maybe you'll be able to do better
Edit: added information about selecting right VDRAM and VDDSOC. Edited by Benus74 - 4/25/17 at 3:25am
Actually mine is on Slot #3, so I'm just not sure.
I wonder if defective SPD information is responsible for my having alot of difficulty (many retries necessary) to get a boot to UEFI after clearing CMOS, as the board may be having difficulty knowing what the heck the memory is.
Originally Posted by dorbot
Looks a bit like it. So what does that mean? Should we compare notes on bios and settings, RGB or not? Or is it just that GSKILL RAM is "a bit iffy". Are the RGB kit's SMbus comms screwing the pooch?
Originally Posted by SpecChum
Could be a CPU-Z bug? HWiNFO shows no sign of the errant profile.
The discussion here is started when i asked for the SPD screenshots. Few weeks ago when testing OC settings suddenly the leds on one of my RAM sticks stopped working after a BSOD. I did also get some weird bootings and problems in windows. After checking the SPD info i saw weird SPD Ext. values on 1 of my sticks.
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.
I'll give HWiNFO a go, not tried debug mode before. Let you know what the result is.
+rep for the stutter fix, after a quick test it seems I am rid of it. Thanks mate
Sadly it didn't completely get rid of the problem for me after some more testing. I also tried to disable the page file completely and that didn't help either
There's something more to this than that but it certainly seems to have something to do with how windows 10 handles NVMe SSD's. I've tried both the Samsung NVMe driver and the stock windows driver and that didn't change anything.