Quote from: CYPER on December 26, 2013, 02:10:47 AM

Quote from: sickpig on December 26, 2013, 12:52:01 AM

so you're impling that setting the clock to the default value lower the Amps, despite the fact that you're increasing the voltage per die?

I have 2 problems with the current state of overclocking:
Problem 1 applies to everyone:
Setting the voltage on the Advanced tab resets the clock.
Problem 2 applies to me only (and maybe other people):
Setting any overclock in cgminer.sh kills a number of dies. I think it happens because when you increase the frequency of the chip the current required increases, which creates a change in the voltage/current values and so this change makes the dies sleepy.

from my limited experience I think that both points apply to everyone. For what is worth I've been albe to verify only the second one: every time I overclock the miner a good number of cores will be disabled during the first two minutes of the new cgminer session. Usually they're concentrated in one or two die. On the other hand I've never tried
to verify the first point, mainly because I don't know how to do it. How do you know for sure that the clock has been reset, do you look at the Amps or is there anyway to read the value of a PLL registry?

Quote

This is what I do: on boards with sleepy dies I increase voltage to the max and when I see they kick in and are alive I immediately lower it to safe values, but not too low so they don't fall asleep again.
Then I restart cgminer.sh where the overclock values are and this makes the dies to fall asleep again even though the voltage hasn't changed (just the current changes as higher frequency results in higher current).

Instead of increasing the voltage to the maximum value, I just set it a little bit higher take into accounts on how many
cores are disabled in a particular die. the I restart cgminer and wait 1 minute to see if changes make any difference.

I use this approch because I don't want to cook my asics/vrms.

I've also increased the SPI frequency because of what 'orama said in one of hist last post said:

Quote from: Bitcoinorama on December 23, 2013, 03:39:30 PM

If the SPI frequency is too low then there is not enough bandwidth to collect all the good nonces found. So you want to find an equilibrium where by SPI frequency is high enough not to miss any of the nonces found, but low enough to retain a healthy noise to signal ratio and thus minimise hardware errors.

Another think I do is taking not of all the changes I apply along the way (a goodthing is coping /config/adavanced.conf at differnet moment in time)

To check the distribution of disabled cores I use a modified version of a pl script included in bertmod. It is an ASCII version, it only outputs temps and disabled core per die, e.g.

Code:

Board 0: Temperature sensor: 47.5C
DIE 0 ON: 46 OFF: 2 95.8% OK
DIE 1 ON: 48 OFF: 0 100% OK
DIE 2 ON: 48 OFF: 0 100% OK
DIE 3 ON: 48 OFF: 0 100% OK
Board 2: Temperature sensor: 64.0C
DIE 0 ON: 47 OFF: 1 97.9% OK
DIE 1 ON: 48 OFF: 0 100% OK
DIE 2 ON: 48 OFF: 0 100% OK
DIE 3 ON: 48 OFF: 0 100% OK
Board 3: Temperature sensor: 55.0C
DIE 0 ON: 48 OFF: 0 100% OK
DIE 1 ON: 48 OFF: 0 100% OK
DIE 2 ON: 48 OFF: 0 100% OK
DIE 3 ON: 48 OFF: 0 100% OK
Board 4: Temperature sensor: 49.0C
DIE 0 ON: 48 OFF: 0 100% OK
DIE 1 ON: 48 OFF: 0 100% OK
DIE 2 ON: 48 OFF: 0 100% OK
DIE 3 ON: 48 OFF: 0 100% OK