So hopefully if your here you've had your mining rig up and stable for a few days/weeks and your ready to dial things in a little tighter. Unfortunately, I can't publish a final solution that will optimize everyone because there is no set of numbers that will work for everyone's particular combination of silicon... one persons utopia will be another's unstable mess. The stock values in the main guide are intended to be "safe" values for the typical card, but even then there have been some cases where it misses the mark as evidenced by the questions that required setting tweaks to resolve. Hopefully this guide will help w.r.t. those questions too.
There are a few knobs you can turn and this guide is intended to show you what they are, what they do, how they interrelate, and how to turn them. The principals in this guide apply to all GPU's but the examples relate to AMD RX Radeon Vega's because... Well, VEGA.miningguides.com.)
That also means the optimization specifics relate to cryptocoins that use the CryptoNight hashing algorithm as its proof-of-work (Monero, ETN, AEON(light), ect ). The CryptoNight PoW is designed to be resistant to mining via the kind of processor that dominate the Bitcoin mining scene (ASIC). This is accomplished by requiring each hash to invoke repeated calls to memory. GPU's with lots of fast memory (Vegas!) or CPU's with lots of L3 cache (Ryzen 1700) do well on CryptoNight algorithm coins.
Note: This tuning guide assumes you followed the main guide to get to this point and thus assumes you are using OverdriveNTool and JJs_HashMonitor.
This Tuning Guide is not Complete. The Theory section is drafted but the mechanics of how you go about making systematic changes is not. Life keeps getting in the way and I have decided to make what is written available... more to come but hopefully this is helpful for some.
One knob in your arsenal is your High Bandwidth Memory (HBM) frequency (speed). The faster you drive the memory (MHz) the faster your CryptoNight hashrate (as a generalization). A Vega 56 comes stock with P3 memory clocked at 800mhz and a Vega 64 comes with Mem_P3 at 945mhz. You will see that most guides push the memory higher then stock values. For example, the baseline settings from this sites guide increase the Vega 56 Mem_P3 up 150 MHz to 950MHz and the Vega 64's gets increased 150MHz to 1100 MHz. (In hindsight I should have bumped both of those back about 50MHz to be an even safer starting point for more peoples first time setup).
The second knob is your GPU's memory voltage. HBM speeds, if your particular card can even handle it, may need higher memory voltage to be stable... but, more voltage means more power and heat. Your tuning goal is to find the minimum memory voltage required to drive the memory at the rate you selected with knob #1. This is an insidious foe as the memory may show some stability for a few hrs and then your system freezes (stays on with Vegas running but won't respond). This kind of behavior may be a sign that your card was only pretending to be happy with the MHz/mV combo you were using. You need to decrease MHz, or increase voltage in search of long term stability. Invalid hashes in the form of numerous "AMD invalid result" errors reported by XMR-Stak can also be a sign that you are pushing too hard and need to decrease MHz, or increase voltage in search of valid hashes.
The third knob is GPU core frequency (speed). In CryptoNight mining, core speed matters but it is not the driver with Vega's... What you want is to be fast enough to service what your memory can handle. A Vega 56 comes stock with GPU_P7 at 1590mhz and 1200mV. A Vega 64 at 1630mhz and 1200mV. That's fast and is great for gaming but it is overkill for CryptoNight mining. The stock settings in the main guide for instance is just over 1400MHz. (This is also why the Vega 64 which has a faster core ability than the 56 is not markedly faster in CryptoNight mining).
If you lower GPU Core Frequency and don't see the hash rate decreasing then the reduction may be acceptable. Conversely, if you bump up the Mem_P3 speed and don't see a hash rate increase, you might bump GPU Core Frequency a bit. You want to minimize GPU_P6/7 speed though because....
The 4th knob is GPU core voltage. GPU core speed stability requires voltage and since voltage consumes power and generates heat, you want to use the lowest GPU speed required to maximize your memory so that you can use the lowest GPU voltage required to service your GPU. If you get a bunch of AMD compute errors you may need more GPU voltage.
If XMR-Stak crashes at startup (but Windows doesn't) then there is no harm done... but you need to try a lower intensity (higher numbers aren't necessary faster). Intensity does factor into your hash rate so you do want to use the optimized numbers if you are able.
As stated in the guide, you will need to make intensity allowances if your GPU serves a monitor/HDMI dongle (you'll know when you get lots of pixelation on the screen and maybe an eventual Windows crash). The guide recommends that 1800 on both threads of whichever Vega services your monitor/dongle is a safe starting point. You are free to experiment to see if your rig has a different happy place. I push it to 1908 on both threads of the Vega that serves my HDMI dongle (I don't have an iGPU). I do get some pixilization but since I have a dedicated miner I don't really care.
If pixilization gets so bad that it causes Windows to crash then of course you need to reduce intensity ... that's why I still don't use 1932 on that particular Vega.
While, OverdrivenTool shows a nice user interface for all the P-states, changing OverdriveNTool values in GPU_P0 to P5, and Mem_P0 to P2 will not actually change anything... you need a soft power play table and Windows reboot to change those (shaded blue in figure below). Those lower states do matter so we do set them (which you have hopefully done) but the tweaking optimization occurs in the high numbered performance states that are heavily used during mining and are editable via OverdriveNTool (GPU_P6, GPU_P7, and Mem_P3 shaded green below).
Don't fret about the soft power play table (P states you don't easily control) once you have a base soft power play table installed. The one exception is if the power play table you used was too aggressive for your card and caused you to crash on Windows startup or Vega reset. If that is the case then you DO need to obtain an even safer soft power play table (links for safer Vega 64 / Vega 56 reg files will go here).
The good news is that AMD did design the driver such that it will throttle your card if the memory temp gets too hot (80C as I understand). For this reason you don't read a lot of Reddit posts about people cooking their Vega's to failure in the short term. I still recommend you drive the fans hard to keep things cool and long term healthy. Now you know the background on 3000rpm... do as you please.
DO NOT USE GPUz. You want the 64 bit portable version of HWiNFO64 (blue button in bottom center of this screen). Select, "Sensors Only" when you open it. Even WWiNFO can cause hash drop so only use it if you are actively tuning.
Remember every Vega is different so if you notice you have a problem card (out of family with the rest) it is fine to make a new profile in Overdriventool.ini and apply it only to that card (I do that for my one gimpy Vega). Open the .ini file, copy a profile and paste it to the bottom. Change the profile name (no spaces) AND make sure you increase the profile ID Number.
Also, do NOT assume the order of your threads in the XMR-Stak Webpage is the same as the order you call them out in Overdriventool. That would be way to easy. While XMR-Stak is running, use the GUI to command your first card to a lower MEM_P3 speed and use the Webpage to see which XMR-Stak threads slows down. You don't have to restart the miner. You can change parameters with OverdriveNTool while the miner is running. OK, more to follow but that is what I have so far....
There are a few knobs you can turn and this guide is intended to show you what they are, what they do, how they interrelate, and how to turn them. The principals in this guide apply to all GPU's but the examples relate to AMD RX Radeon Vega's because... Well, VEGA.miningguides.com.)That also means the optimization specifics relate to cryptocoins that use the CryptoNight hashing algorithm as its proof-of-work (Monero, ETN, AEON(light), ect ). The CryptoNight PoW is designed to be resistant to mining via the kind of processor that dominate the Bitcoin mining scene (ASIC). This is accomplished by requiring each hash to invoke repeated calls to memory. GPU's with lots of fast memory (Vegas!) or CPU's with lots of L3 cache (Ryzen 1700) do well on CryptoNight algorithm coins.
Note: This tuning guide assumes you followed the main guide to get to this point and thus assumes you are using OverdriveNTool and JJs_HashMonitor.
This Tuning Guide is not Complete. The Theory section is drafted but the mechanics of how you go about making systematic changes is not. Life keeps getting in the way and I have decided to make what is written available... more to come but hopefully this is helpful for some.
Theory You Need To Understand
Knob #1: Memory Frequency (MHz)
Knob #2: Memory Voltage (mV)
Knob #3: GPU Core Frequency (MHz)
If you lower GPU Core Frequency and don't see the hash rate decreasing then the reduction may be acceptable. Conversely, if you bump up the Mem_P3 speed and don't see a hash rate increase, you might bump GPU Core Frequency a bit. You want to minimize GPU_P6/7 speed though because....
Knob #4: GPU Core Voltage (mV)
Knob #5: Intensity and Blocksize
The final Knob is "intensity/blocksize". This is actually a miner setting that is controlled behind the scenes in CastXMR and by you directly in XMR-Stak. Intensity is based on GPU architecture and should be pretty standard for every Vega. There is a rational explanation for Intensity and blocksize settings (data) but I have had more luck using the guess-and-test approach. My results are posted in the guide (1932 on all threads). I have found that in XMR-Stak 2.1 and above, setting "strided_index" to 'true' gives a small benefit in hashrate without any negative side effect.If XMR-Stak crashes at startup (but Windows doesn't) then there is no harm done... but you need to try a lower intensity (higher numbers aren't necessary faster). Intensity does factor into your hash rate so you do want to use the optimized numbers if you are able.
As stated in the guide, you will need to make intensity allowances if your GPU serves a monitor/HDMI dongle (you'll know when you get lots of pixelation on the screen and maybe an eventual Windows crash). The guide recommends that 1800 on both threads of whichever Vega services your monitor/dongle is a safe starting point. You are free to experiment to see if your rig has a different happy place. I push it to 1908 on both threads of the Vega that serves my HDMI dongle (I don't have an iGPU). I do get some pixilization but since I have a dedicated miner I don't really care.
If pixilization gets so bad that it causes Windows to crash then of course you need to reduce intensity ... that's why I still don't use 1932 on that particular Vega.
GPU Performance States
The P numbers you see in the figures above are GPU performance states. As a GPUs workload increases it works it's way up the available Performance States. When Gaming or mining, the GPU will work up to and then camp out in the higher performance states.While, OverdrivenTool shows a nice user interface for all the P-states, changing OverdriveNTool values in GPU_P0 to P5, and Mem_P0 to P2 will not actually change anything... you need a soft power play table and Windows reboot to change those (shaded blue in figure below). Those lower states do matter so we do set them (which you have hopefully done) but the tweaking optimization occurs in the high numbered performance states that are heavily used during mining and are editable via OverdriveNTool (GPU_P6, GPU_P7, and Mem_P3 shaded green below).
Don't fret about the soft power play table (P states you don't easily control) once you have a base soft power play table installed. The one exception is if the power play table you used was too aggressive for your card and caused you to crash on Windows startup or Vega reset. If that is the case then you DO need to obtain an even safer soft power play table (links for safer Vega 64 / Vega 56 reg files will go here).Midpoint Summary:
Oversimplified midpoint summary is this... Maximize the HBM frequency (Mem_P3, Knob #1) that your particular batch of silicon can handle and understand the interrelationships with knobs 2, 3 and 4 so you can do whatever is required with the other knobs to get stability and value out of that memory speed while minimizing power consumption. Use OverdrivenTool to turn those knobs... initially via the GUI and ultimately via a dialed in set of OverdrivenTool.ini file profiles that will be called automatically via JJs_HashMonitor at each miner start. Easy right!Cautions
Know When Enough is Enough
I am writing this guide because it was heavily asked for but you should take some pause before you spend too much time chasing perfection. If you take your 10,000 h/s rig down for a cumulative day worth of crashes in an effort to optimize an extra 100h/s out of your rig... it will take you 10,000/100 = 100 days to make good on that investment. That said, each watt you consume does cost money so I think you will find that it is worth some time for power optimization. I personally apply the principles mentioned to ensure stability on my one gimpy Vega 64 vs. actually spending too much time trying to find the exact line my already proficient cards will go unstable.
The Silicone Lottery (Hash Rate and Power):
Regardless of whether your actual silicon could handle more or not, the stock Vega 64 AMD driver will reject a memory frequency much greater then 1100MHz (1107MHz might be actual stock limit?). If you apply certain soft power play tables to your Vega 64 you can technically command a Vega to 1200MHz but your Vega very likely cannot handle that speed and if it can then getting their will require a significant voltage boost... which means a lot of power and heat. Just remember that if your Vega 56 is stable at 800mhz and your Vega 64 is stable at 945mhz then AMD has met it's obligation and, while you aren't a silicone lottery winner, you can't go complaining to AMD about a gimpy card either.
As mentioned earlier, the baseline guide is already pushing the stock memory frequency by 150MHz and is netting you hash rates of 1950h/s per Vega 56 and 2010h/s per Vega 64. While a Memory clock of 1200MHz might get you closer to 2200h/s it is not an entitlement (and even if you "win" the silicon lottery it is likely not worth the power and heat required...). I personally have not even gone fishing for these higher speeds with my cards and am content with the hashrates posted on the main guide. I use this tuning guidance to tune the power required to get me there and stable. YMMV.Card Safety
Voltage drives heat. The good news is that AMD stock gaming settings push GPU core P6/7 voltages harder then we will. That mean the card can more then handle the heat your mining should produce... provided the fan does it's job. Unfortunately, because games push the core harder than the memory, the AMD driver is designed to adjust fan speed based on core temperate. That's a bummer because mining pushes the GPU memory harder than the core so in our perfect world the AMD driver would adjust fan speed based on GPU memory temperature. It doesn't. That is the reason why this guide has you set the minimum fan speed to 3000rpm. Some consider a 3000rpm minimum fan speed to be bit Overkill. You are free to dial it down based on your final settings but I use 3000rpm to keep things cool and I'm not about to post a lower base value in my guide.The good news is that AMD did design the driver such that it will throttle your card if the memory temp gets too hot (80C as I understand). For this reason you don't read a lot of Reddit posts about people cooking their Vega's to failure in the short term. I still recommend you drive the fans hard to keep things cool and long term healthy. Now you know the background on 3000rpm... do as you please.
Tools and the Mechanics of Optimization
As warned in the intro of this post... it is not yet completely written and you have gotten to the bottom of what I have written... A quick peak ahead is that you should use a Kill-a-Watt ( USA 110V / Europe 220V) to monitor success and will set these values (The knobs above) via a call to a specific profile in your .ini file.DO NOT USE GPUz. You want the 64 bit portable version of HWiNFO64 (blue button in bottom center of this screen). Select, "Sensors Only" when you open it. Even WWiNFO can cause hash drop so only use it if you are actively tuning.
Remember every Vega is different so if you notice you have a problem card (out of family with the rest) it is fine to make a new profile in Overdriventool.ini and apply it only to that card (I do that for my one gimpy Vega). Open the .ini file, copy a profile and paste it to the bottom. Change the profile name (no spaces) AND make sure you increase the profile ID Number.
Also, do NOT assume the order of your threads in the XMR-Stak Webpage is the same as the order you call them out in Overdriventool. That would be way to easy. While XMR-Stak is running, use the GUI to command your first card to a lower MEM_P3 speed and use the Webpage to see which XMR-Stak threads slows down. You don't have to restart the miner. You can change parameters with OverdriveNTool while the miner is running. OK, more to follow but that is what I have so far....
-- Copyright Vega.MiningGuides.com 2017/2018 --