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

I installed 20310818 on my 4-module batch 1 and 3-module batch 2, and they're both humming along fine.  The batch 2 unit runs faster now, reporting WU 1182 now after 15 hours, where before WU was 1161.  I think the batch 1 unit does also, though I didn't measure.


If it were me, I would remove the board from the heatsink and reseat it.  Maybe exchange it with one in a different position on the same module, and hope it was just a connector problem.

I'd also look at it to see if anything's obviously fried or otherwise damaged.

Shoot, I checked my logs to see what was going on and found this:

   [match_work_count3] => 0

EDIT: Batch #2 unit running 20130818

it seems that with 0818 FW the avalon-temp in batch 1 and 2 is set by default to 52. this setting with previous FWs
resulted in cgminer restarts and lots of rejects. This is not the case with this FW.
ckolivas did something magic?! 

put --avalon-temp 48 or something and you will be happy but noise  
my setup is
--avalon-auto --avalon-temp 48

is it possible to have a temp log of the unit?

my avalon batch 1 seems to have random reboots where the miner just stops hashing and by the time i realised it, it has cooled down from possible overheating or just cooled down from all hashing, so i can't really tell if it's overheating.

if my miner is set --avalon-temp 54 , what is the cutoff temps for the miner to shutdown?

when it does overheat and shutsdown or goes idle, do i have to manually power down to let it cool or can i just let it run on idle and it will start hashing again once it's cool?

Same problem here, batch #3 three blade miner:
[match_work_count24] => 0

other worker are fine, but box is hashing 1/24 less

Looking for idea what to check.

Hi,

on my upgraded batch #2 miner (3 + 1 blade) the fw of the router board was working well up to yesterday evening german time (between 18 and 20 UTC). After them mining was stopped and would not further started.
I found that dns was not further working so adding direct entries to hosts fixed it as work around.
I wonder me a little bit but I used the downtime to upgrade the fw to the latest stable one (23.07.2013). But with them the problem still exists.

I compared all the entries now one by one with my other batch#2-same fw 3 blade avalon an correct some entries.
But still the problem exists.

Both miners are installed on different server housing locations so the ip addresses are different.
Both use static ip on local interface eth0
Both use same nameserver entry on eth0 to 8.8.8.8
Both are not allowed to service dhcp.
3blade Miner is running well without problem
4blade Miner will not start cgminer soft (there is another issue with latest stable fw by the upgrade; I will describe it seperatlly)

I checked with nslookup and could see that on 127.0.0.1 after near by one minute feeling an answer got from the nslookup command e.g. for stratum.btcguild.com.
nslookup stratum.btcguild.com 8.8.8.8 answer is not paused.
I guess a problem in the dnsmask configuration. But comparing with the 3blade miner gives me no difference.

So I removed the resolve.conf link from /etc and create an own by using direct nameserver which now helped me shortly to first fix the problem.
Also I've disabled dnsmasq hopefully permanently by /etc/init.d/dnsmasq disable. I do not really need dnsmasq also I'm a little bit unhappy with that
Now nslookups are now fast as before and potentiallly mining is now available again with hostnames instead of direct ip adresses or using /etc/hosts.

My first question:
What could it happen that dnsmasq needs so much time to answer the forwarding lookup. I use 8.8.8.8 nameserver for static eth0 interface on both.

Cheers...

On my batch #3 three blade miner the miner #24 looks like not working well:

   [match_work_count1] => 682
   [match_work_count2] => 684
   [match_work_count3] => 711
   [match_work_count4] => 722
   [match_work_count5] => 700
   [match_work_count6] => 621
   [match_work_count7] => 719
   [match_work_count8] => 641
   [match_work_count9] => 720
   [match_work_count10] => 698
   [match_work_count11] => 674
   [match_work_count12] => 666
   [match_work_count13] => 684
   [match_work_count14] => 679
   [match_work_count15] => 722
   [match_work_count16] => 658
   [match_work_count17] => 667
   [match_work_count18] => 639
   [match_work_count19] => 700
   [match_work_count20] => 686
   [match_work_count21] => 670
   [match_work_count22] => 710
   [match_work_count23] => 643
   [match_work_count24] => 0

Any idea what I can do to check them or to test them?

I've disabled it simply now by using only configuring Miner Count = 23 because it is latest miner which is not working.

Cheers,

It's probably because the default for cutoff is 60 and your settings are invalid if you set the target temperature to higher than the cutoff temperature.

that did the trick.

Have powered down and back. Was blinking with settings --avalon-temp 50 --avalon-auto --avalon-freq 256-365.

Since removed and now have --avalon-auto no blinking. Maybe a conflict in settings or as ckolivas said maybe it knows its over driving etc.

Have added back --avalon-auto --avalon-freq 256-365 must be to do with avalon freq setting iver its conflicting or as ckolivas said it knows its overclocking over drive etc.

Can you power the system down then back up and have it work with version 20130818?
Does the orange light flash on your system?
 

Sorted problem not sure wtf went on tho.

1 flashed to new firmware had running then all sudden when flashing system powered down powered back up solid red light and solid orange light had to telnet the fucker and firstboot didnt work mount_Root said a bunch of stuff then checked for ip and reverted to 192.168.0.100 so changed and manged to get access again.

The unit is saying its stuck on dchp on 192.168.1.65 and does not connect to it.

At 8h 15m uptime with version 20130818

   [timeout] => 35
   [frequency] => 353
   [fan1] => 2520
   [fan2] => 3720
   [fan3] => 3840
   [temp1] => 22
   [temp2] => 47
   [temp3] => 48
   [temp_max] => 51

   [match_work_count5] => 23945
   [match_work_count17] => 24590

you missed --avalon-cutoff 80

it needs both -cutoff and -temp options to run.

You probably already tried this, but have you tried to access it on the 192.168.0.100 IP as well as whatever static IP you had it on before the upgrade?  After one of my flashes I experienced the strange behavior that the unit remembered the old IP settings even though I told it to not remember the settings.

Good luck,

_theJestre

well powed down and I have it powered up but now solid red light and orange and cant connect to device. Its as tho its crashed partly through firmware upgrade and gone tits up now unable to access even when trying to put into fail safe

I don't see an orange light.  It isn't very dark around my unit, so I'll check again later, but I see the white light and no orange.

For some reason mine won't accept the --avalon-auto option. I've tried it with 20130703 20130814 and now 20130818. For example this works:

--avalon-temp 70 --avalon-cutoff 80

but this:

--avalon-auto --avalon-freq 256-275 --avalon-temp 70

results in the following cgminer API log error:

[Firmware Version] => 20130818
cgminer-f3b75b0
luci-d854edc+
cgminer-openwrt-packages-800cc58
Socket connect failed: Connection refused

any ideas?