Topic: Avalon ASIC users thread - page 154. (Read 438516 times)

Something is wrong.
Cgminer says 80 GH/s advantage but Slushs pool only 70 GH/s...

Something is wrong.
Cgminer says 80 GH/s advantage but Slushs pool only 70 GH/s...

Can anyone think of a reason not to get this PSU for a 3 module silver and a 3 module black Avalon with overclocking intentions ?
http://www.nexustek.nl/Nexus_RX-1K_Modular_Quiet_Power_Supply_1000W.htm
single rail 12V 80A
ATX 20+4 pins
ATX12V/EPS12V 4+4 pins
4x PCI-E 6+2 pins (only 2 will be used)
Case dimensions - W x H x D (mm) 150 x 86 x 165

TIA for your thoughts!

So the shown HW errors are a multiple of the the diff mining at?
having a higher percentage

cgminer restarted in the night, MHz is again at 341

I'm getting a high rate of rejects from the pool so cgminer is showing me nearly 79GHash/s but on the pool bitparking its only around 71GHasch/s like it was at 300 MHz?
watching this

Auto tries to keep HW errors below 1.5%. Are you sure you're not mining at a higher diff?

thank you CKolivas! 80C will cook me and my tiny apartment. I think I need to figure a way to vent the heat directly outside without letting the rain and snow in,

Very much dependent on the chips, so this can only be a wild guess, but... 80+ degrees?

just curious what might the "error range" be? it's getting rather hot in here and I think I might have to buy another AC unit... summer is right around the corner...

I guessed this might be the case since the temperatures really aren't getting into the error range even with regular air cooling - especially since it's 3 degrees at my home overnight and the hashrate doesn't go up. I suspect the hashrate will only get higher with more voltage given to the chips.

I am seeing little or no improvement by cooling with a portable A/C.

Unit with A/C
1h 37m 58s  83896.29  temp3 43    freq(auto) 354

Unit without A/C
6h 54m 22s  83111.32   temp3 53    freq(auto) 353

Thanks for the detailed info! I noticed that during the first 10 or so hours the overclocked avalon was stable, but then it becomes more and more unstable, even the outside temp dropped significantly during night, cgminer restarted repeatedly, I feel that instability might comes from FPGA. What could be the cause of that? Have you observed same accumulated instability over time?

P.S. also sent 1B to you, cgminer still rules  

How is the auto balancing between maximising clock speed but minimising fan speed? What is the hierarchy?

A few notes about the auto-clocking approach.

First and foremost, you can fry your hardware as you are running your avalon out of specification, especially if you try it on a batch 1 device with its lower power and quality PSU.

As is virtually always the case, manually fine tuning the final result will always be better than an automated process that guesses. With time I wish to get rid of the requirement to have fixed intervals and allow the user to specify any arbitrary value for the frequency, though the interface coping with it is a bit of an issue at the moment.

Ironically some people are finding the frequency a little too high and others a little too low. I suspect everyone is looking at a different endpoint for what is an ideal frequency in their eyes. The targets I've set are based on hardware error as a percentage, with hysteresis of +/- 0.25% - this is because a .5% increase in hardware errors works out to the amount the hashrate would rise with 2Mhz increments; i.e. if your hardware error count is going up at the same rate as the hashrate should rise, you are wasting energy. Ideally, a regression plot is what would be needed, getting the hashrate rise with each increment and the hw error percentage rise, and seeing when one grows faster than the other, but this is absurd stats to try to go looking for, especially when the values fluctuate wildly under normal circumstances only. By default with avalon-auto, you will get hardware errors of 1~1.5% . When looking at the hardware error count, make sure you are comparing it to the diff1 shares and not the accepted since you will almost certainly be mining at higher diff. Hardware errors are harmless in their own right but indicative of how hard you're pushing the chips for their available voltage and cooling. It sounds like these chips are capable of much more with more voltage but no one's done said mod yet.

The way to calculate hardware error percentage is:
HW * 100 / (diff1 + HW)

It's also worth mentioning that to simplify the calculation of different frequencies, the values passed to the avalon with this latest firmware on the "regular values", i.e. 300 and below, is slightly lower than the values that would have been passed to it, but it should make only a negligible difference to hashrate, lost in the noise of normal variance that happens with hashrate. The "timeout" value passed is also smaller now, which means you may hit the limit at lower speeds than you used to - but the old timeouts were too high, and even if you apparently had a higher hashrate, if you go back and check your stats you may find you were getting more rejects. This is because the higher timeouts were leading to duplicate shares being generated so it is only a disadvantage.

A sure fire sign that you're overdoing it is cgminer repeatedly being restarted by the avalon watchdog, or periods of hashrate dropping, or smoke coming out of your PSU.

Tried restarting multiple times from the interface, still seeing 15-20% HW errors. Soo weird.