crashoverride wrote:The point of this post is not to say changing the DRAM settings shouldn't be tested. Rather, the point is that people expecting a DRAM setting to solve the "2GHZ problem" will likely be disappointed by the test results.
DRAM clocking and power req's are at least worth poking a stick at, when exploring a black box all variables are holes sticks can go in....
Right now I see the following area's we could investigate:
(1) disable all un-needed power draws (GPU, i2C, etc...) check if that changes any results at higher CPU clocks
(2) If clock skew ( ref:
https://en.wikipedia.org/wiki/Clock_skew ) is root cause one option is to disable all clocks besides CPU (similar to #1) OR adjust what clocks
we have knobs for (including DDR3) to see if we can shift the timing into sync
(3) Investigate varying the power to the various PWM driven subsystems that we have control over (note: this is separate from the DVFS cpu clocks)
(4) Determine if upstream kernel with pared down DTS tree and working L2 cache is stable at any higher clocks (could indicate if the above steps are worth deep investigation)
Note: If the upstream kernel with L2 cache patches improves performance over our current L2 cache, then it "could" offset lowered DDR3 ram timings if we find DDR3 changes help.
Working 1.75ghz (or greater) on a CPU with 28nm geometry is going to generate more heat. Using a cut-down Northbridge heatsink I don't see heat issues, instead I hit memory access errors. Clock skew, insufficient power, poor memory controller design, etc.. I have no idea where the clock train derails..... but its a fun black box to
poke at.... and determining root cause by exploring a system's limits tends to illuminate all kinds of dark corners in your system (look at what this thread has uncovered just regarding BL30.bin).
On the cache topic the L2 cache flush patches I was looking at earlier this year starting at 3.18 kernel fixed issues with the kernel improperly flushing the entire cache way too often. Are the extra cache flushes effecting our current performance? No idea, but a use case of headless database could really use a properly working L2 cache. If we end up running at higher clocks an L2 cache that properly works will boost overall performance, especially if we adjust DDR3 ram timings.
