Left pane, second box down, "PowerPlay" there will be a value for "Max Memory Freq. (MHz)" and whatever value you have in there is the absolute maximum the card will accept.
Question for you iSuX (just cos I think you might have the answer).
I've modded bioses with Polaris 1.6.7 and the One Click Timing Patch, etc. but I have noticed on the 570s that the max freq is 2250, with straps going up to 2000. However, when I try to OC above 2000 it just crashes. Anything 2000 and under runs fine.
So, my question, do I need to be adding extra timings above 2000 to allow it to OC above 2000?
I also see in the memory portion, there are freq and voltages up to 1750 mhz, but nothing above. Should I be adding in more freq/voltage pairs as well? Or is all of this unnecessary?
Hi jeremyismer
You ask an interesting question, and are probably already thinking on the right track to solve your problem.
I've been thinking about blogging here on this topic, so thanks for the inspiration. Apologies if this is a bit off topic/Claymore. (it IS, but the question is here too).
I can't claim to have the definitive answers, or even if this is "the" way to do it, but I can share what I discovered along the way, trial and error methods etc.
What I noticed was, some cards have memory timings stopping at 2000 while others go to 2250.
This seems more dependant on the memory type, than the actual card vendor or model.
For example, Micron memory based cards, straps top out at 2000 on (most of) my cards, and these were the worst performers out-of-the box, but one click timing actually made them worse in some cases.
What I think is happening in the firmware, is when an application/os is calling for a specific clock, (that is not specified in the table), the firmware is calculating that, (changing it), based on the scale/gradient as defined by the stepping and values in that table.
For example, (simplified), suppose the top strap was 1000 and has a timing value of 100, and the application calls for clock of 1010MHz, the actual value would be scaled up to 101.
So, when people start editing those straps, you have to think about how the firmware is going to be able to scale those strapping values, when you request some clock value that is NOT specially listed in the table.
What I see is a lot of data out there, where people are editing, sometimes only the top strap, sometimes the top 2, 3, or even 5.
Where that seems likely to screw up later on, will be with people trying to get every last single MHz out of it, and essentially requesting values that might not get scaled to something the card can actually deliver, or potentially values that don't parse.
On tuning straps/mem type.
Samsung: I've more or less given up on. It's a great performer out of of the box. All my efforts to increase MH/s were marginal in that respect, and questionable in stability. Ergo, I decided the potential gains were not worth the downtime. Time I can be using for those cards to mine. (Plus I only have 2 of them, so collective gain is not an incentive for me).
Micron: This is my top performer, but was a lot of work and learning. But all those cards hash at a super stable 32.64 MH/s I shuffled 8 into a single rig, and sometimes think ethman is not refreshing, because those values change so little. lol.
Hynix2. I have to confess, I'm not so happy with my results, and am working on that. (32.07 is my super stable average)
It's tough man, you know, you struggle through issues get things working, take a breather, (if you're lucky ;-) let some time pass so you can assess stability, while all the time wondering, should I try to improve hash rate? What will that cost in down time, stability?
It's a question of expectation, so I decided early on to numerically quantify expectation, in hash rate terms.
I settled on my absolute minimum acceptable on the RX580 would be 32.0, and I mean SOLID, never seeing a 31.999 for example.
(Claymore also helped me here, as his miner got faster, so I wouldn't claim all the credit there)
So currently I'm in two minds with the hynix cards, evening pulling one into the dev rig, I need some ROI :-)
Ok, so back to practicalities here.
I'm usually pretty hesitant to get involved in posting about BIOS settings, there is potential there to damage or even destroy hardware, and that would not be nice for anyone.
Also, I'm frequently astounded at how poorly some people follow instructions, even when those are crystal clear, and include advice to read it and ask first, if you don't understand.
Of course, that's not directed at yourself, simply a general observation.
So, blah blah "I take no responsibility, blah blah", you get the point.
OK, so have a think about this from a different perspective.
The firmware architecture is such, that we see a stepped scale.
If one requests a MHz value that is specifically defined in that table, THAT strap value is used.
Every other value, will be scaled/translated to something in between, (interpolated), or if set above the top step, extrapolated.
Now, interpolation is going to be more likely to work, as it's always constrained, but not so extrapolation, that can only follow the gradient as crafted by the steps between the lowest and highest step values.
Ergo, any value you set above the top step, is less likely to work, and the probability of failure increases with higher values.
So once I theorised this, I decided to test that theory.
I took the 300MHz strap value, and set all values in the table to that value.
Expecting the following: No matter what value I requested between 300 and 2000, there would be no change in hashrate, because there was no scale/gradient in that range. (flat line etc)
This proved so.
I then changed this, so-called flatline BIOS ver, so only the 2000 value was default, and when I requested 2000, I got stock hashrate, while 1900 was more or less the same as 300, (a tiny big higher).
Try to visualise that on a graph, and it makes it's pretty obvious what is going on.
So, essentially one could, in theory, have claymore pick ANY number for the clock, 9000 for example, and provided 9000 limit is set, and 9000 has a specific table entry, that would at least be accepted, assuming the actual strap value was something rational like the original 2000 value.
It's kind of a lookup table, or transform table if you like.
Where I think most people screw up, is by flashing BIOS they downloaded from the net onto their cards, who knows what that does, every situation would be more or less unique, while perversely those same people probably have some "standard" expectation, (as do we all), but how does one expect standards, when working without a standard logical methods?
(That said, I looked at LOT of those online BIOS while trying to work out what was happening in the firmware), so in that situation, having a bunch of random BIOS edits was useful to analyse.
The next screw up, is if you are going to edit a bunch of strap steps, you should at least start by using one of those specific clock values, and take it from there if expectation is not met.
OK, so, something else to think about.
That table is stepped, each line has some Id, (not visible in the editor), so you can't simply add additional steps in there, well, you can't with any editor I have seen so far. This means you need to edit an existing entry, and those are sorted by the ID only, so you can't for example think, "oh, I don't think I need the 400MHz step, as I have 300 and 800, so I will change the 400 entry to 2250.
Rough example, that table would then be
200
2250
800
1000
1600
But think about what that does to the curve on the graph. Fine if you use any of those specific values, but everything else would be a roller coaster value around the 2250 mark.
Also, you need to think about how the card inits, so I decided it would probably be a bad idea to touch the lowest value, (200, 300 etc), that is the stepping the card will init at, as it uses minimal power, and equally, if it gets a reset from the driver, it needs to start there before clocking up.
What I did was to edit the scale so I could make the last entry, (the fastest one), some value that was overclocked. I decided to pick 2250 on the RX580, simply because I knew it could be called, and meant I didn't need to test how to, (or even if), the MAX limit was editable, (and understood by the fw).
Logic being, minimal change = maximum stability.
Of course this means eliminating one of the lower, existing steps, and shuffling the rest of them up the list, which is kind of tedious in the editor tbh, and VERY easy to make mistakes, copy/pasting etc
The method I came up with is this.
Open 4 instances of the editor.
1: The stock BIOS for that specific card, (readonly etc, for reference and cross checking, typos or my screw ups)
2: The stock BIOS for that specific card, (same as above), but this will be the one I edit.
3: The previous revision (if I have one)
4: The BIOS with the straps I'm copy from, (if I have one)
Eliminate distractions, interruptions, and lots of coffee if it's dark outside :-)
Well, that's more or less where I'm at with trying to understand this topic so far, but work continues for sure.
The aspects mentioned here, where I devised tests for proof, I've said so, but I'm open to debate on, (or anything I might write for that matter), but I decided I was confident enough in that proof, to move forward.
Indeed some of this is purely theory, albeit observational based, but also based on more than a few years experience in related fields, and I'd very much welcome anyone correcting me if I've erred anywhere.
Equally, testing was done on Sapphire, Gigabyte, Asus based, RX580 8GB cards, which is hardly runs the gamut, so I would make no claims this info applies to all and every vendor, model. That said, there is enough above, people can experiment on their own, and take full responsibility for doing so.
@jeremyismer If you want to PM me, link/dropbox/etc your stock BIOS and best edit version, I can take a look, (include card make, model of course), I might be able to help you in a positive direction.
Oh yeah, and here's a funny discovery, (that helped me understand more about the types of chips/archecture used, (you can Winflash the BIOS on a card, WHILE MINING with it in claymore) hahaha.
Happy mining everyone.
