Custom RAM Timings for GPU's with GDDR5 - DOWNLOAD LINKS - UPDATED

[laik2]

what VDDC offset?
Try those on linux
Also I didn't push the gpus too far, so they're a bit loosened..I'll post my best results on  windows later.

-69V From Bios . pulling around 880W ATW from 6 cards .

I see 7 GPUs...

Here's my latest update on Linux --> 3x Sapphire Nitro+ RX 480 OC 8GB, Sapphire Nitro+ 2x RX 480 8GB, 1x MSI Armor 470 4G all Samsung
{ "gpu_temp": " 61 61 60 61 62 61", "gpu_fanspeed": " 40 60 40 23 33 21", "gpu_core": " 1165 1100 1145 1165 1165 1145 ", "gpu_memory": " 2120 2050 2120 2120 2050 2120 " }
GPU0 -100mV, GPU1 -100mV, GPU2 -125mV, GPU3 -100mV, GPU4 -100mV, GPU5 -125mV -> ATW consumption 816W


Here's what these are doing on windows --> Almost the same config but 1 Nitro+ OC was at 2120 not 2050(probably bad batch, so I lowered it to get it stable)

[1714614642]

1714614642

[NisamRobot]

What strap do you guys use for samsung? Custom or 1625 strap?

[laik2]

Custom.

[NisamRobot]

Custom.

mind sharing that strap, or at least give a hint at some values you changed?

[laik2]

Depends on algo, for ETH values that give significant rate are located in RAS/CAS.

[NisamRobot]

Thanks, now i see you get 28.5-29 on msi armor 470 4gb, that is what i get on the same card using 1750 strap, i was wondering it could get better using custom timings....

[laik2]

Thanks, now i see you get 28.5-29 on msi armor 470 4gb, that is what i get on the same card using 1750 strap, i was wondering it could get better using custom timings....

Actually I haven't pushed it too much, last unstable result was 30.4 on linux and I just lowered to 1100/1950 and I got 28.8 stable + bonus 75W power consumption ATW

[nerdralph]

I see at least a couple people have written strap decoding programs, but I can't find publicly released.  I was going to write one and release it publicly, but I figured if someone else has already written one...

[deadsix]

I see at least a couple people have written strap decoding programs, but I can't find publicly released.  I was going to write one and release it publicly, but I figured if someone else has already written one...

I haven't seen a publicly available program yet, would be great if you could do that man

[nerdralph]

I see at least a couple people have written strap decoding programs, but I can't find publicly released.  I was going to write one and release it publicly, but I figured if someone else has already written one...

So it's not as simple as using atombios.h to dump the fields in ATOM_MEMORY_TIMING_FORMAT_V2.
https://raw.githubusercontent.com/torvalds/linux/master/drivers/gpu/drm/radeon/atombios.h

Straps for GCN cards are 52 bytes long (3 bytes for memory clock, 1 byte for memory type, 48 bytes for strap), but sizeof(ATOM_MEMORY_TIMING_FORMAT_V2) = 40 bytes.

So is it just a matter of old-fashioned reverse engineering?  i.e. looking at different straps and reading through GDDR5 data sheets to figure out the strap offsets for different values?

[kilo17]

I know myself and wolf0 both wrote our own programs/scripts to do it.  Even with that I use an old fashion speadsheet like Excel or Numbers to do it mostly.

[niko2004x]

I see at least a couple people have written strap decoding programs, but I can't find publicly released.  I was going to write one and release it publicly, but I figured if someone else has already written one...

With all due respect, if you have such a tool then public release means less profits for you.
No sane (=selfish) miner would do that. At least I wouldn't with all the work involved.
And yes I written such a tool to decode/encode RAS, CAS, PGM, MISC, MISC2, ARB_DRAM, ARB_DRAM2 parts of timing string and edit bios with it
(for all cards starting from HD 7xxx).

It is not as simple as reading atombios.h (I don't read this one and it seems mostly irrelevant for the task),
but this thread gives a lot of hints how to do it.

[kilo17]

I see at least a couple people have written strap decoding programs, but I can't find publicly released.  I was going to write one and release it publicly, but I figured if someone else has already written one...

With all due respect, if you have such a tool then public release means less profits for you.
No sane (=selfish) miner would do that. At least I wouldn't with all the work involved.
And yes I written such a tool to decode/encode RAS, CAS, PGM, MISC, MISC2, ARB_DRAM, ARB_DRAM2 parts of timing string and edit bios with it
(for all cards starting from HD 7xxx).

It is not as simple as reading atombios.h (I don't read this one and it seems mostly irrelevant for the task),
but this thread gives a lot of hints how to do it.

I started this thread to try and help people but quickly realized that trying to help people became "Can you do this for me" and my PM inbox was overrun with it.  So I took a backseat for a bit.

On a side note niko2004x, nerdralph would have zero problems figuring it out and writing it.  His knowledge about programing etc FAR exceeds both yours and mine.

[nerdralph]

I see at least a couple people have written strap decoding programs, but I can't find publicly released.  I was going to write one and release it publicly, but I figured if someone else has already written one...

So it's not as simple as using atombios.h to dump the fields in ATOM_MEMORY_TIMING_FORMAT_V2.
https://raw.githubusercontent.com/torvalds/linux/master/drivers/gpu/drm/radeon/atombios.h

Straps for GCN cards are 52 bytes long (3 bytes for memory clock, 1 byte for memory type, 48 bytes for strap), but sizeof(ATOM_MEMORY_TIMING_FORMAT_V2) = 40 bytes.

So is it just a matter of old-fashioned reverse engineering?  i.e. looking at different straps and reading through GDDR5 data sheets to figure out the strap offsets for different values?

After reviewing the thread discussion again, and more digging through the kernel code, it seems atombios.h is some ancient relic of video cards gone by.
The straps for GCN cards are 32-bit values that get written to the GPU memory controller registers.
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_1_sh_mask.h

4 bytes each for:
MC_SEQ_RAS_TIMING
MC_SEQ_CAS_TIMING
MC_SEQ_MISC_TIMING
MC_SEQ_MISC_TIMING2
MC_SEQ_PMG_TIMING

That accounts for 20 bytes of the strap.  Training and PHY timing may be part of the strap as well, but decoding the 5 register values above should be all that is needed to make tangible improvements in the timing.

[laik2]

I see at least a couple people have written strap decoding programs, but I can't find publicly released.  I was going to write one and release it publicly, but I figured if someone else has already written one...

So it's not as simple as using atombios.h to dump the fields in ATOM_MEMORY_TIMING_FORMAT_V2.
https://raw.githubusercontent.com/torvalds/linux/master/drivers/gpu/drm/radeon/atombios.h

Straps for GCN cards are 52 bytes long (3 bytes for memory clock, 1 byte for memory type, 48 bytes for strap), but sizeof(ATOM_MEMORY_TIMING_FORMAT_V2) = 40 bytes.

So is it just a matter of old-fashioned reverse engineering?  i.e. looking at different straps and reading through GDDR5 data sheets to figure out the strap offsets for different values?

After reviewing the thread discussion again, and more digging through the kernel code, it seems atombios.h is some ancient relic of video cards gone by.
The straps for GCN cards are 32-bit values that get written to the GPU memory controller registers.
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/include/asic_reg/gmc/gmc_8_1_sh_mask.h

4 bytes each for:
MC_SEQ_RAS_TIMING
MC_SEQ_CAS_TIMING
MC_SEQ_MISC_TIMING
MC_SEQ_MISC_TIMING2
MC_SEQ_PMG_TIMING

That accounts for 20 bytes of the strap.  Training and PHY timing may be part of the strap as well, but decoding the 5 register values above should be all that is needed to make tangible improvements in the timing.

Well...u are not wrong

[Zorg33]

Decoding is already done by many of us.
The hard part is finding the best values, that is not simply guessing.

An encoding/decoding tool could help that process very much.
Maybe someone publishes his own, I don't have time to write one.

What I wonder the most about is how custom straps improve hashrate through reduced latency and not through increased bandwidth. I think for example ZEC mining is much more sensitive to latency than bandwidth. Obviously fragmented memory operations rely more on latency than bw.
I'd like to get some insight on these different approaches in timing adjustments and their relation.

[nerdralph]

I`ve got a working prototype, and should have full decoding of at least 6 strap registers working by the end of the day.

strap.h:

Code:

typedef union  _ARB_DRAM_TIMING2 {
  u32 data;
  struct {
    u32 RAS2RAS:8;
    u32 RP:8;
    u32 WRPLUSRP:8;
    u32 BUS_TURN:8;
  } fields;
} ARB_DRAM_TIMING2;

parse.c:

Code:

#include <stdio.h>
#include <stdint.h>

typedef uint32_t u32;

#include "strap.h"

ARB_DRAM_TIMING2 t8 = {0x922A3217};

int main(void)
{
  printf("RAS2RAS: %d\n", t8.fields.RAS2RAS);
}

RAS2RAS: 23

[deadsix]

I`ve got a working prototype, and should have full decoding of at least 6 strap registers working by the end of the day.

Praise be upon you.

[azgal0r]

I wonder what's your background to have such knowledge. I haven't touched C in years so I barely have any idea about whats happening in this snippet.
 For example what does RAS2RAS:8 means ?
And  ARB_DRAM_TIMING2 t8 = {0x922A3217}; What's happening there ? You are instantiating a type with some hex ?

I am curious because it's been a long time since I had to deal with this kind of low level programming.

[nerdralph]

I wonder what's your background to have such knowledge. I haven't touched C in years so I barely have any idea about whats happening in this snippet.
 For example what does RAS2RAS:8 means ?
And  ARB_DRAM_TIMING2 t8 = {0x922A3217}; What's happening there ? You are instantiating a type with some hex ?

I am curious because it's been a long time since I had to deal with this kind of low level programming.

Google c bitfields.