Quote from: CYPER on December 26, 2013, 05:31:32 PM

Quote from: sickpig on December 26, 2013, 03:54:38 PM

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.

In my case dies are being disabled (1 die = 48 cores). If just cores are disabled then that is easy to fix - just apply more voltage to stabilize them.

ok got it

Quote

Quote from: sickpig on December 26, 2013, 03:54:38 PM

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?

Yes, voltage drops. For example you apply the overclock and you see a VRM working at 54A. You change the voltage setting just 1-2 values lower and after you hit apply the Amps drop from 54 to 44, which means the higher overclock frequency is no longer applied.

ok.

next time I've to do it I will pay attention to Amps values just after changing the voltage. in the meantime I'll try also to find a way to read the PLL register that contain clock settings.

Quote

Quote from: sickpig on December 26, 2013, 03:54:38 PM

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 tried that, but it doesn't work as effective as applying max voltage. With max voltage the sleepy dies usually kick in immediately.
Also I have a 2nd theory, which I haven't tested a lot, but if you supply sufficient voltage to a sleepy die it might awake after 2-3-4-5-6 hours. But I don't think there is any consistency in results with this method and I prefer to wake them up immediately with stress/shock voltage that waiting hours for them to wake up naturally, which is not guaranteed to happen.

since any other methods you have tried have failed just give this theory of yours a try, no?

Quote

Quote from: sickpig on December 26, 2013, 03:54:38 PM

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

How much? I played with this and I usually stick to 256000Mhz. I tried even more, but I can't see any correlation between this and any results.

actually I'm OC quite slightly, using 1F1, and I'm using as SPI freq 299707 and prev I 've used 256000, I haven't seen now difference, though.

Quote

Quote from: sickpig on December 26, 2013, 03:54:38 PM

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.

How exactly did you do that?

bertmode 0.2.X bin file contained a perl script, asic_status.pl, used to generate a modified version of the status page. A btctalk user (don't rember the name sorry) have changed it to just puts on standard output a few info.

Quote

You created an additional page within the lighttpd server?

no I've just placed the modifed script into /config (just to make persistent across reboost), to use it I just log in using ssh and execute from the command line:

Code:

perl /config/asice_status_ascii.pl

if you find it useful I could upload the file somewhere...