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

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

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....

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?

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.

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.

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.

Praise be upon you.

Google c bitfields.