Avalon ASIC users thread - page 136.

SolarSilver

legendary

Activity: 1112

Merit: 1000

Quote from: Tesla71 on July 05, 2013, 02:05:59 AM

Anybody mentioned the fact that the unit gets real hot at the bottom?
Any advise to make that better or doesn't that really matter? Maybe place it upside down ?

They get hot on the bottom because the hashing module is screwed to the heatsink and the heatsink is screwed to the bottom of the case. As the heatsink is not touching the top of the case, the top does not get hot.

The internal fans should do the job of keeping things cool, the bottom will not get hotter than the heatsink anyways

You can add additional air cooling externally on the case bottom if that makes you feel more comfortable.

Keep the case horizontally. I would not flip it upside down, that would make the hashing modules hang from the top, it was not designed for that.

Tesla71

sr. member

Activity: 302

Merit: 252

Anybody mentioned the fact that the unit gets real hot at the bottom?
Any advise to make that better or doesn't that really matter? Maybe place it upside down ?

el_rlee

legendary

Activity: 1600

Merit: 1014

Quote from: BenTuras on July 05, 2013, 12:50:59 AM

Quote from: el_rlee on July 04, 2013, 07:36:58 PM

... and an aluminum plate to the front which really presses the chips down onto the heatsink.

It has been said many times not to put anything on top of the chips. You'll destroy them.

Thru cooling?!

BenTuras

hero member

Activity: 826

Merit: 1001

Quote from: el_rlee on July 04, 2013, 07:36:58 PM

... and an aluminum plate to the front which really presses the chips down onto the heatsink.

It has been said many times not to put anything on top of the chips. You'll destroy them.

el_rlee

legendary

Activity: 1600

Merit: 1014

Quote from: invader on July 04, 2013, 03:10:38 PM

Quote from: el_rlee on July 04, 2013, 10:39:54 AM

Can it be that --avalon-auto is only working with a reading for the fan rpm's? I use water cooling and have no fans...
Also is it possible that the setting for 16 miners instead of 24 is not working?

Last time i looked at your screen i found a huge amount of hw errors even at moderate frequencies,
i would try in simular case (if auto fails) to increment manually in 5 Mhz steps and look at hw error rate.
The only possible way fan data can make a "collision" with auto frequency option in this piece of code,

Code:

			if (!info->optimal) {
				if (info->fan_pwm >= opt_avalon_fan_max) {
					applog(LOG_WARNING,
					       "AVA%i: Above optimal temperature, throttling",
					       avalon->device_id);
					avalon_dec_freq(info);
				}

but info->fan_pwm is not rpm sensor reading, its pwm setting for fan speed. Even if you don't have one or
it just not connected - it will keep on passing pwm value to controller. So if your fan reading is zero -
there is no protection besides --avalon-cutoff option, its just for info purpose in current version.
Thats how i figured it out after looking at sources when my new fans went to 0 rpm and temperature starts growing.
I see no reason for changing 24 to 16 miners options to not work, only one thing - they must be plugged in DATA_P1 and P2 ports.

That was your message in my thread:

Quote from: invader on July 03, 2013, 10:58:19 PM

You should check accepted diff1 shares against hw errors, thats what you really want to know.
According to your screen you have ( 9032 / 735510 ) * 100% = 1.22% error rate
Try the latest firmware that was posted in "Avalon ASIC users thread" and overclock it to 375+

--avalon-auto seams working now, maybe I just was too impatient. I just don't get the results I wanted with my water cooling, frequency is on 354 now with the auto option. I am thinking of applying thermal paste to the back and an aluminum plate to the front which really presses the chips down onto the heatsink.

thorvald

sr. member

Activity: 388

Merit: 250

first crash with firmware 703
I started with auto mode from 370
after a while it will go to 364-368
after 20+ save+apply changes it will start normal and the hash will drom until 0 , all the diff1 shares went to Hw error
a cgminer stop start /restart will fix it for 30 min until it will go again down
it looks like a cgminer restart all the stats are 0
changed to 325 + auto and is the same
soft reboot did not fix it
hard reboot is the way to go

invader

sr. member

Activity: 266

Merit: 250

Quote from: el_rlee on July 04, 2013, 10:39:54 AM

Can it be that --avalon-auto is only working with a reading for the fan rpm's? I use water cooling and have no fans...
Also is it possible that the setting for 16 miners instead of 24 is not working?

Last time i looked at your screen i found a huge amount of hw errors even at moderate frequencies,
i would try in simular case (if auto fails) to increment manually in 5 Mhz steps and look at hw error rate.
The only possible way fan data can make a "collision" with auto frequency option in this piece of code,

Code:

if (!info->optimal) {
if (info->fan_pwm >= opt_avalon_fan_max) {
applog(LOG_WARNING,
"AVA%i: Above optimal temperature, throttling",
avalon->device_id);
avalon_dec_freq(info);
}

but info->fan_pwm is not rpm sensor reading, its pwm setting for fan speed. Even if you don't have one or
it just not connected - it will keep on passing pwm value to controller. So if your fan reading is zero -
there is no protection besides --avalon-cutoff option, its just for info purpose in current version.
Thats how i figured it out after looking at sources when my new fans went to 0 rpm and temperature starts growing.
I see no reason for changing 24 to 16 miners options to not work, only one thing - they must be plugged in DATA_P1 and P2 ports.

tiktoc

full member

Activity: 176

Merit: 100

Quote from: cypherdoc on July 04, 2013, 02:08:33 PM

so please tell me what these details mean:

Code:

2013-07-04 12:01:33,573 INFO BasicShareLimiter # Checking Retarget for 1 (30) avg. 1 target 30+-15
2013-07-04 12:01:33,573 INFO BasicShareLimiter # Retarget for 1 870 old: 30 new: 900

Checking difficulty, connection 1 at 30 diff on average. 1 second per share, target is 30seconds avg plus or minus 15 seconds

change in retarget diff for connection 1 for 1 share in 30 seconds is 870, so old diff which is 30 plus new diff change of 870 = new diff total of 900 difficulty

so each 1 share is now worth 900 normal diff shares.

edit slight change to wording after reading more logs

ProfMac

legendary

Activity: 1246

Merit: 1002

Quote from: silverston on July 04, 2013, 11:12:09 AM

Quote from: ?? on ??

Quote from: silverston on July 04, 2013, 09:28:21 AM

after static ip configuration i see black screen with LuCI - Lua Configuration Interface, still loading and after again - can not connect!!

If you changed the IP you also need to change the IP of the computer you are connecting with.

Can such as reset to default?

Google for OpenWRT failsafe
Also, search in these forums.

cypherdoc

legendary

Activity: 1764

Merit: 1002

Quote from: spiccioli on July 03, 2013, 02:55:33 AM

Quote from: cypherdoc on July 03, 2013, 12:17:42 AM

Quote from: jddebug on July 03, 2013, 12:10:37 AM

Is it stratum vardiif ramping up so you are submitting far less shares but same hashrate?

is there a way to tell?

Yes,

look at the lines with "Checking retarget for...", you'll see that it grows slowing down share submission.

spiccioli

so please tell me what these details mean:

Code:

2013-07-04 12:01:33,573 INFO BasicShareLimiter # Checking Retarget for 1 (30) avg. 1 target 30+-15
2013-07-04 12:01:33,573 INFO BasicShareLimiter # Retarget for 1 870 old: 30 new: 900

silverston

hero member

Activity: 952

Merit: 502

SAPG Pre-Sale Live on Uniswap!

Quote from: ?? on ??

Quote from: silverston on July 04, 2013, 09:28:21 AM

after static ip configuration i see black screen with LuCI - Lua Configuration Interface, still loading and after again - can not connect!!

If you changed the IP you also need to change the IP of the computer you are connecting with.

Can such as reset to default?

el_rlee

legendary

Activity: 1600

Merit: 1014

Can it be that --avalon-auto is only working with a reading for the fan rpm's? I use water cooling and have no fans...
Also is it possible that the setting for 16 miners instead of 24 is not working?

@ckolivas: I got some water cooling blocks on spare - if you like I would send you one over as a donation

Just PM me if interested.

silverston

hero member

Activity: 952

Merit: 502

SAPG Pre-Sale Live on Uniswap!

after static ip configuration i see black screen with LuCI - Lua Configuration Interface, still loading and after again - can not connect!!

elasticband

legendary

Activity: 1036

Merit: 1000

Nighty Night Don't Let The Trolls Bite Nom Nom Nom

one of my avalons connects via 192.168.0.110

shmadz

legendary

Activity: 1512

Merit: 1000

@theshmadz

Quote from: silverston on July 04, 2013, 08:28:17 AM

Hello!
please help!
I can not connect to the Avalon ...
Connecting to laptop via patchcord, I type in the browser 192.168.0.100 and wrote some time - Error connecting.
how to stop it?
only from box ...
sorry for my english

Did you set a static address on your laptop?

May or may not need a crossover cable,

google "How to set static IP"

silverston

hero member

Activity: 952

Merit: 502

SAPG Pre-Sale Live on Uniswap!

Hello!
please help!
I can not connect to the Avalon ...
Connecting to laptop via patchcord, I type in the browser 192.168.0.100 and wrote some time - Error connecting.
how to stop it?
only from box ...
sorry for my english

Bogart

legendary

Activity: 966

Merit: 1000

Quote from: Tesla71 on July 04, 2013, 05:44:48 AM

Quote from: -ck on July 03, 2013, 08:06:51 AM

Quote from: Tesla71 on July 03, 2013, 07:59:56 AM

Nice thanks, maybe that fix my issue:

Quote from: Tesla71 on July 03, 2013, 01:50:31 AM

- my cgminer process seems to restart after every 4 hours or so.. must watch longer to see if it happens regulary. could it have something to do with the --avalon-auto, maybee the freq gets to high and it restarts? I am using --avalon-freq 300-340

One possibility. There are a few different ways that it restarts. One is an actual error in the code that makes it hang and stop submitting work, which should be fixed in this latest firmware. The other is multiple pool or network outages - and this is where the watchdog is trigger happy, as any period of 2+ minutes without work is enough for cgminer to stop being able to make work and the watchdog is not smart enough to detect what it is. Another is fpga screwups, but they are getting less likely with more fixes going into the cgminer direct USB code than they used to be with the old serial interface thereby bypassing one potential point of failure. An operating system error is also possible, and seems more common with the wifi enabled for reasons that aren't clear. Finally there's true hardware failure of one sort or another - overheat, inadequate power etc.

I could confirm that the newest firmware 2130703 fixed the restarts of cgminer. It's running since 18 hours so far.

Same here. I installed it on 2 units last night (Batch 1 and Batch 2), and both now show 10+ hours of cgminer uptime.

It also seems to solve the issue where cgminer would sometimes not start hashing, and have to be restarted. I was doing some config changes which let to a bunch of restarts last night, and it started hashing every time.

Tesla71

sr. member

Activity: 302

Merit: 252

Quote from: -ck on July 03, 2013, 08:06:51 AM

Quote from: Tesla71 on July 03, 2013, 07:59:56 AM

Nice thanks, maybe that fix my issue:

Quote from: Tesla71 on July 03, 2013, 01:50:31 AM

- my cgminer process seems to restart after every 4 hours or so.. must watch longer to see if it happens regulary. could it have something to do with the --avalon-auto, maybee the freq gets to high and it restarts? I am using --avalon-freq 300-340

One possibility. There are a few different ways that it restarts. One is an actual error in the code that makes it hang and stop submitting work, which should be fixed in this latest firmware. The other is multiple pool or network outages - and this is where the watchdog is trigger happy, as any period of 2+ minutes without work is enough for cgminer to stop being able to make work and the watchdog is not smart enough to detect what it is. Another is fpga screwups, but they are getting less likely with more fixes going into the cgminer direct USB code than they used to be with the old serial interface thereby bypassing one potential point of failure. An operating system error is also possible, and seems more common with the wifi enabled for reasons that aren't clear. Finally there's true hardware failure of one sort or another - overheat, inadequate power etc.

I could confirm that the newest firmware 2130703 fixed the restarts of cgminer. It's running since 18 hours so far.

invader

sr. member

Activity: 266

Merit: 250

Backported my changes to latest cgminer source ( --avalon-invert-pwm , --avalon-hysteresis ), build new firmware.
Looks uberstable since reflash, 8+ 16+ hrs cgminer works without restart
( previous version was usually restarting in 2-3 hrs )

Syke

legendary

Activity: 3878

Merit: 1193

Quote from: -ck on July 01, 2013, 06:24:23 PM

This rolls back to the previous hardware error target of <2% when using avalon-auto which is worth about 1.5GH more on average.

How about making the target error rate a parameter?

Topic: Avalon ASIC users thread - page 136. (Read 438596 times)