Quote from: nerdralph on February 27, 2018, 03:32:07 PM

Quote from: pbfarmer on February 24, 2018, 11:21:41 PM

Quote from: nerdralph on January 12, 2018, 04:08:37 PM

I recently decided to take another look at RAM timings now that many people have been playing with custom timings for several months.

Instead of zeroing FAW/32AW as I do in my strapmod utility, I think it is better to set them low. 7/10 seems to be standard for Hynix straps, while 6/8 is typical for Samsung. My testing so far using 6/8 on Hynix gives the same performance for eth mining as 0/0, while potentially being more stable at higher memory clocks.
I also suspect the field labels may be reversed, so FAW is really 32AW, and vice-verse. In my testing, when I set "FAW" to 8 or 10 while leaving "32AW" to zero, I see no slowdown in ethash speed.

I may update my strapmod when I'm done, but my goal is to finally finish a Linux tool I started working on last year that tweaks timings at runtime. This allows for tuning the memory timing for ethash, equihash, or cryptonight without reflashing the BIOS and rebooting. It has already greatly improved strap testing, as I have been able to modify timings on the fly while mining; I don't even have to restart the miner. I still crash the GPU a lot, as dynamically switching between two sets of good timing will still cause a hang depending on which timings you switch in what order.

I have sort of been under the assumption that in the presence of an invalid value, memory controllers must be calculating t32aw automatically. Every strap I've ever seen (including from mfgs) is out of spec, given that t32aw should always be >= 8 x tfaw, as i understand it.

Btw, would love to take a peek at your tool

If my suspicion about the labels being reversed is correct, and 32AW is a multiplier for FAW, then 6/8 is perfectly fine. FAW would be 6*RRD, and 32AW would be 8*6*RRD.
That also would better explain the observation that setting what they think is 32AW to zero causes instability.

As for the tool I'm working on, you can get an idea of how it works by looking at my fork of amdmeminfo.
https://github.com/nerdralph/amdmeminfo
I modified it to show runtime strap values. My tool doesn't just read them, it writes them too.
I believe Yurio is ahead of me in this process with his Windows miner now being able to do runtime timing modifications.
https://github.com/zawawawa/GatelessGateSharp

That formula seems wrong, or i am missing something.

Elpida is as follow:

1500: 6/10/7
1625: 7/12/8
1750: 7/12/8
2000: 7/12/8

No matter how you put it, neither tFAW and tFAW32 can be any multiple of tRRD.
Currently using tFAW = 0 and tFAW32 = 4.

For what i remember actually, tFAW if its set to 0, its actually read as 8. Dunno if each single value counts as 8, or if its just timing properties. If its the first - that would make sense for the 1625-2000Mhz straps. That makes possible the following : tFAW = 7 * 8, Which would also fall in line with what you said.