Bitcoin Forum
November 19, 2017, 01:30:27 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 [128] 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 ... 221 »
  Print  
Author Topic: Avalon ASIC users thread  (Read 432310 times)
mrSprinkles
Full Member
***
Offline Offline

Activity: 166


View Profile
August 18, 2013, 06:04:38 AM
 #2541

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?

you missed --avalon-cutoff 80

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

that did the trick.
1511055027
Hero Member
*
Offline Offline

Posts: 1511055027

View Profile Personal Message (Offline)

Ignore
1511055027
Reply with quote  #2

1511055027
Report to moderator
A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511055027
Hero Member
*
Offline Offline

Posts: 1511055027

View Profile Personal Message (Offline)

Ignore
1511055027
Reply with quote  #2

1511055027
Report to moderator
1511055027
Hero Member
*
Offline Offline

Posts: 1511055027

View Profile Personal Message (Offline)

Ignore
1511055027
Reply with quote  #2

1511055027
Report to moderator
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2338


Ruu \o/


View Profile WWW
August 18, 2013, 06:10:34 AM
 #2542

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?

you missed --avalon-cutoff 80

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

that did the trick.
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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
asjfdlksfd
Full Member
***
Offline Offline

Activity: 129


View Profile
August 18, 2013, 10:37:51 AM
 #2543

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,
asjfdlksfd
Full Member
***
Offline Offline

Activity: 129


View Profile
August 18, 2013, 10:57:12 AM
 #2544

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 <ip> 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 Sad
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...
PaJo2000
Newbie
*
Offline Offline

Activity: 13


View Profile
August 18, 2013, 11:58:20 AM
 #2545

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

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

Looking for idea what to check.
tarui
Sr. Member
****
Offline Offline

Activity: 294


View Profile
August 18, 2013, 12:02:11 PM
 #2546

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?
silverston
Hero Member
*****
Offline Offline

Activity: 602


Hi


View Profile
August 18, 2013, 12:08:54 PM
 #2547

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?
put --avalon-temp 48 or something and you will be happy Smiley but noise  Shocked
my setup is
--avalon-auto --avalon-temp 48

zoro
Full Member
***
Offline Offline

Activity: 226


View Profile
August 18, 2013, 05:10:59 PM
 #2548

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?!  Roll Eyes

"killer app" of BTC = MasterCoin https://bitcointalk.org/index.php?topic=265488.0Mastercoin(A new protocol layer on top of Bitcoin)
thejestre
Member
**
Offline Offline

Activity: 74


View Profile
August 18, 2013, 05:22:13 PM
 #2549

On my batch #3 three blade miner the miner #24 looks like not working well:
   [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.


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

   [match_work_count3] => 0

EDIT: Batch #2 unit running 20130818
Bogart
Legendary
*
Offline Offline

Activity: 952


View Profile
August 18, 2013, 05:53:38 PM
 #2550

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.

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

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

Looking for idea what to check.

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.

"All safe deposit boxes in banks or financial institutions have been sealed... and may only be opened in the presence of an agent of the I.R.S." - President F.D. Roosevelt, 1933
spiccioli
Legendary
*
Offline Offline

Activity: 1355

nec sine labore


View Profile
August 18, 2013, 08:39:33 PM
 #2551

Hi,

the other day I've upgraded three batch #1 three modules Avalons from 20130519 to 20130814... I've lost a good 10% of hashing capacity Sad

Inside Avalon GUI I still see 70 GH, I'm not using --avalon-auto (nor any other option) given that I'm still using the stock PSU, but on pool graph you can clearly see when I've updated them



My question is: can I go back to 20130519 without problems or do I risk to brick them?

TIA

spiccioli

ps. I see that there is now 20130818, but I'd prefer to go back to what was working before trying next firmware.
Carlton Banks
Legendary
*
Offline Offline

Activity: 1820



View Profile
August 18, 2013, 08:44:58 PM
 #2552

My question is: can I go back to 20130519 without problems or do I risk to brick them?

Logically, there's no way for the TP-LINK router to be aware of the difference between "backwards" FW flashes and "forwards" FW flashes. Still, if you don't take my word for it, then I won't take responsibility for your new brick  Cheesy. If it helps any more, I've already heard about people successfully re-flashing to older FW, in this thread I think.

Vires in numeris
thejestre
Member
**
Offline Offline

Activity: 74


View Profile
August 18, 2013, 09:42:54 PM
 #2553

Hi,

the other day I've upgraded three batch #1 three modules Avalons from 20130519 to 20130814... I've lost a good 10% of hashing capacity Sad

Inside Avalon GUI I still see 70 GH, I'm not using --avalon-auto (nor any other option) given that I'm still using the stock PSU, but on pool graph you can clearly see when I've updated them

My question is: can I go back to 20130519 without problems or do I risk to brick them?

TIA

spiccioli

ps. I see that there is now 20130818, but I'd prefer to go back to what was working before trying next firmware.

I used --avalon-auto without upgrading my batch #2 PSU.  I have flashed older firmware after newer firmware successfully without much hassle.  20130818 is awesome firmware, I'd say try that at least before going backwards.

_theJestre
ProfMac
Legendary
*
Offline Offline

Activity: 854



View Profile
August 18, 2013, 09:47:15 PM
 #2554

Hi,

the other day I've upgraded three batch #1 three modules Avalons from 20130519 to 20130814... I've lost a good 10% of hashing capacity Sad

Inside Avalon GUI I still see 70 GH, I'm not using --avalon-auto (nor any other option) given that I'm still using the stock PSU, but on pool graph you can clearly see when I've updated them



My question is: can I go back to 20130519 without problems or do I risk to brick them?

TIA

spiccioli

ps. I see that there is now 20130818, but I'd prefer to go back to what was working before trying next firmware.

20130703 worked very well for me.
20130814 & 20130814-1 worked poorly.
20130818 was an improvement.  It has run 24+ hours.


I try to be respectful and informed.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2338


Ruu \o/


View Profile WWW
August 19, 2013, 12:05:54 AM
 #2555

Some of you have already spotted I uploaded a new firmware, 20130819

http://ck.kolivas.org/apps/cgminer/avalon/20130819/

There was a substantial rewrite of the timing code going into 20130818 which is where the hashrate rise from that version came from. I extended the timing code to encompass all the aspects of the usb communications with the avalon in 20130819 so it's more robust with respect to staying in sync with results and not losing data. However, overall it performs identically in my testing since the previous version dropped results only very rarely anyway since it is only likely to be a problem when CPU load is high and since the recent changes to cgminer it hardly uses any CPU now - it's only the background services on the avalon that may cause spikes in CPU and affect cgminer indirectly. So consider this a minor upgrade only.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
Satobit
Jr. Member
*
Offline Offline

Activity: 42


View Profile
August 19, 2013, 12:58:14 AM
 #2556

Some of you have already spotted I uploaded a new firmware, 20130819

http://ck.kolivas.org/apps/cgminer/avalon/20130819/

There was a substantial rewrite of the timing code going into 20130818 which is where the hashrate rise from that version came from. I extended the timing code to encompass all the aspects of the usb communications with the avalon in 20130819 so it's more robust with respect to staying in sync with results and not losing data. However, overall it performs identically in my testing since the previous version dropped results only very rarely anyway since it is only likely to be a problem when CPU load is high and since the recent changes to cgminer it hardly uses any CPU now - it's only the background services on the avalon that may cause spikes in CPU and affect cgminer indirectly. So consider this a minor upgrade only.

I just flashed this firmware, and I can say that the HW rate has dropped about 30%-50%. Pretty amazing!
E
Full Member
***
Offline Offline

Activity: 220



View Profile
August 19, 2013, 01:20:40 AM
 #2557

Some of you have already spotted I uploaded a new firmware, 20130819

http://ck.kolivas.org/apps/cgminer/avalon/20130819/

There was a substantial rewrite of the timing code going into 20130818 which is where the hashrate rise from that version came from.

Just flashed 20130819 onto my Block 2 which is in ~25 Ambient. --avalon-auto stabilized around:

349 for 20130703 (Got more than 35 days of uptime from this one)
345 for 20130814-1, with similar utility as 20130703
357 for 20130819, with much lower eligius rejects! Like, 1/3rd the reject rate.

Have yet to get a 3hr update from eligius, but my 22.5 minute accepted rate is...

88MHash/s!!

Dunno if the lights are blinking, and I'm not going to check so it won't bug me if they are Smiley
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2338


Ruu \o/


View Profile WWW
August 19, 2013, 01:35:18 AM
 #2558


Dunno if the lights are blinking, and I'm not going to check so it won't bug me if they are Smiley

I can save on Christmas decorations as well as heat.

They are blinking at regular intervals.  They look synchronized as they blink
Still trying to figure out what your lights are. Would it be approximately every 1.2 seconds? What batch avalon do you have?

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
regular
Sr. Member
****
Offline Offline

Activity: 297


View Profile
August 19, 2013, 02:23:59 AM
 #2559

My batch 2's orange light in blinking now too.  It's still hashing away though.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2338


Ruu \o/


View Profile WWW
August 19, 2013, 02:32:34 AM
 #2560


Dunno if the lights are blinking, and I'm not going to check so it won't bug me if they are Smiley

I can save on Christmas decorations as well as heat.

They are blinking at regular intervals.  They look synchronized as they blink
Still trying to figure out what your lights are. Would it be approximately every 1.2 seconds? What batch avalon do you have?

Yes, that is it.  I measured roughly 10 blinks in 11.6 seconds.  Both batch 2 and 3.  My batch 1 design does not have the light but the fan with the blue light stopped.
Well that is then corresponding with when the avalon is ready/getting more work then. Why it suddenly started showing that, I don't know. Nor do I know why it doesn't show it on mine.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
Pages: « 1 ... 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 [128] 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 ... 221 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!