Search content
Sort by
Showing 20 of 31 results by Ghost of USD
Re: [7000GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Hey guys - looking for a bit of advice here. Just done a complete reinstall Xubuntu 12.04 after my SSD conked out. While doing so, I decided to move my wallet data to a separate SSD in an effort to reduce strain/latency/wear on the main system SSD. When I start my *coind's (merged mining) everything syncs up fine, but when I start the p2pool program it fails to load any shares, starts going straight to work & spits out py errors about still downloading shares. All my config files are exactly the same as before so I'm wondering if I need a different setting for p2pool because the data files are on a separate drive? I start my *coind's with the added command:
-datadir=/path/to/data - everything works there, is there something I need to add to the p2pool startup command as well?
This is the first time I've had my wallet data on a separate drive, and the first time I've had any problems with my configuration not working. All dependencies/packages are installed/checked/double checked. Any ideas/advice would be greatly appreciated
EDIT: I'm sure it's a basic, simple mistake I've made - I just can't see it.......
EDIT1: Or, am I the only person using a separate drive for their wallet data on p2pool.......and this is a bug?
-datadir=/path/to/data - everything works there, is there something I need to add to the p2pool startup command as well?
This is the first time I've had my wallet data on a separate drive, and the first time I've had any problems with my configuration not working. All dependencies/packages are installed/checked/double checked. Any ideas/advice would be greatly appreciated
EDIT: I'm sure it's a basic, simple mistake I've made - I just can't see it.......
EDIT1: Or, am I the only person using a separate drive for their wallet data on p2pool.......and this is a bug?
Maybe you might have to also specify where your conf file is?
http://i.imgur.com/OlJOgGe.jpg?1
I want to ask which kind of resistor is missing here on the second chip from right?
I've been looking around,but can't finded what is the corect name and parameters of that one.
I want to ask which kind of resistor is missing here on the second chip from right?
I've been looking around,but can't finded what is the corect name and parameters of that one.
According to the docs: https://github.com/BitSyncom/avalon-ref/blob/master/PDF/SCH/hash_chip.pdf?raw=true
That is a 60 Ohm @ 100MHz Magnetic Ferrite Chip Bead
Re: CGMINER ASIC FPGA GPU overc monit fanspd RPC linux/win/osx/mip/r-pi 3.4.0
cgminer on my avalon just crashed, and I found this in the kernel log:
Code:
[375254.850000] miner/0 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[375254.850000] Call Trace:
[375254.850000] [<8006dd8c>] dump_stack+0x8/0x34
[375254.860000] [<800b6b84>] dump_header.isra.16+0x44/0x128
[375254.860000] [<800b6ec8>] oom_kill_process+0xd4/0x3b0
[375254.870000] [<800b7600>] out_of_memory+0x28c/0x2e4
[375254.870000] [<800ba698>] __alloc_pages_nodemask+0x540/0x624
[375254.880000] [<800b6194>] filemap_fault+0x294/0x3e8
[375254.880000] [<800cc380>] __do_fault+0xcc/0x444
[375254.890000] [<800cf1a8>] handle_pte_fault+0x32c/0x6dc
[375254.890000] [<800cf608>] handle_mm_fault+0xb0/0xdc
[375254.900000] [<80071208>] do_page_fault+0x110/0x354
[375254.900000] [<80060820>] ret_from_exception+0x0/0xc
[375254.910000]
[375254.910000] Mem-Info:
[375254.910000] Normal per-cpu:
[375254.920000] CPU 0: hi: 0, btch: 1 usd: 0
[375254.920000] active_anon:4982 inactive_anon:36 isolated_anon:0
[375254.920000] active_file:2 inactive_file:54 isolated_file:0
[375254.920000] unevictable:0 dirty:0 writeback:0 unstable:0
[375254.920000] free:180 slab_reclaimable:232 slab_unreclaimable:784
[375254.920000] mapped:1 shmem:130 pagetables:75 bounce:0
[375254.920000] free_cma:0
[375254.950000] Normal free:720kB min:720kB low:900kB high:1080kB active_anon:19928kB inactive_anon:144kB active_file:8kB inactive_file:216kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:32512kB managed:28856kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:520kB slab_reclaimable:928kB slab_unreclaimable:3136kB kernel_stack:392kB pagetables:300kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:88 all_unreclaimable? yes
[375254.990000] lowmem_reserve[]: 0 0
[375255.000000] Normal: 0*4kB 0*8kB 1*16kB (R) 0*32kB 1*64kB (R) 1*128kB (R) 0*256kB 1*512kB (R) 0*1024kB 0*2048kB 0*4096kB = 720kB
[375255.010000] 191 total pagecache pages
[375255.010000] 0 pages in swap cache
[375255.010000] Swap cache stats: add 0, delete 0, find 0/0
[375255.020000] Free swap = 0kB
[375255.020000] Total swap = 0kB
[375255.030000] 8192 pages RAM
[375255.030000] 921 pages reserved
[375255.030000] 30 pages shared
[375255.030000] 7014 pages non-shared
[375255.040000] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[375255.050000] [ 430] 0 430 220 15 3 0 0 ubusd
[375255.050000] [ 432] 0 432 192 13 3 0 0 askfirst
[375255.060000] [ 534] 0 534 368 44 5 0 0 netifd
[375255.070000] [ 624] 0 624 379 22 4 0 0 crond
[375255.080000] [ 632] 0 632 289 18 3 0 0 dropbear
[375255.090000] [ 648] 0 648 292 28 5 0 0 uhttpd
[375255.090000] [ 678] 65534 678 239 22 4 0 0 dnsmasq
[375255.100000] [ 690] 0 690 375 18 4 0 0 ntpd
[375255.110000] [22605] 0 22605 14642 4592 18 0 0 cgminer
[375255.120000] [29206] 0 29206 374 17 4 0 0 sh
[375255.130000] [29207] 0 29207 374 17 5 0 0 cgminer-monitor
[375255.130000] [29213] 0 29213 374 17 5 0 0 cgminer-monitor
[375255.140000] [29214] 0 29214 193 9 3 0 0 cgminer-api
[375255.150000] [29215] 0 29215 372 11 3 0 0 grep
[375255.160000] Out of memory: Kill process 22605 (cgminer) score 605 or sacrifice child
[375255.170000] Killed process 22605 (cgminer) total-vm:58568kB, anon-rss:18368kB, file-rss:0kB
[375254.850000] Call Trace:
[375254.850000] [<8006dd8c>] dump_stack+0x8/0x34
[375254.860000] [<800b6b84>] dump_header.isra.16+0x44/0x128
[375254.860000] [<800b6ec8>] oom_kill_process+0xd4/0x3b0
[375254.870000] [<800b7600>] out_of_memory+0x28c/0x2e4
[375254.870000] [<800ba698>] __alloc_pages_nodemask+0x540/0x624
[375254.880000] [<800b6194>] filemap_fault+0x294/0x3e8
[375254.880000] [<800cc380>] __do_fault+0xcc/0x444
[375254.890000] [<800cf1a8>] handle_pte_fault+0x32c/0x6dc
[375254.890000] [<800cf608>] handle_mm_fault+0xb0/0xdc
[375254.900000] [<80071208>] do_page_fault+0x110/0x354
[375254.900000] [<80060820>] ret_from_exception+0x0/0xc
[375254.910000]
[375254.910000] Mem-Info:
[375254.910000] Normal per-cpu:
[375254.920000] CPU 0: hi: 0, btch: 1 usd: 0
[375254.920000] active_anon:4982 inactive_anon:36 isolated_anon:0
[375254.920000] active_file:2 inactive_file:54 isolated_file:0
[375254.920000] unevictable:0 dirty:0 writeback:0 unstable:0
[375254.920000] free:180 slab_reclaimable:232 slab_unreclaimable:784
[375254.920000] mapped:1 shmem:130 pagetables:75 bounce:0
[375254.920000] free_cma:0
[375254.950000] Normal free:720kB min:720kB low:900kB high:1080kB active_anon:19928kB inactive_anon:144kB active_file:8kB inactive_file:216kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:32512kB managed:28856kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:520kB slab_reclaimable:928kB slab_unreclaimable:3136kB kernel_stack:392kB pagetables:300kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:88 all_unreclaimable? yes
[375254.990000] lowmem_reserve[]: 0 0
[375255.000000] Normal: 0*4kB 0*8kB 1*16kB (R) 0*32kB 1*64kB (R) 1*128kB (R) 0*256kB 1*512kB (R) 0*1024kB 0*2048kB 0*4096kB = 720kB
[375255.010000] 191 total pagecache pages
[375255.010000] 0 pages in swap cache
[375255.010000] Swap cache stats: add 0, delete 0, find 0/0
[375255.020000] Free swap = 0kB
[375255.020000] Total swap = 0kB
[375255.030000] 8192 pages RAM
[375255.030000] 921 pages reserved
[375255.030000] 30 pages shared
[375255.030000] 7014 pages non-shared
[375255.040000] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[375255.050000] [ 430] 0 430 220 15 3 0 0 ubusd
[375255.050000] [ 432] 0 432 192 13 3 0 0 askfirst
[375255.060000] [ 534] 0 534 368 44 5 0 0 netifd
[375255.070000] [ 624] 0 624 379 22 4 0 0 crond
[375255.080000] [ 632] 0 632 289 18 3 0 0 dropbear
[375255.090000] [ 648] 0 648 292 28 5 0 0 uhttpd
[375255.090000] [ 678] 65534 678 239 22 4 0 0 dnsmasq
[375255.100000] [ 690] 0 690 375 18 4 0 0 ntpd
[375255.110000] [22605] 0 22605 14642 4592 18 0 0 cgminer
[375255.120000] [29206] 0 29206 374 17 4 0 0 sh
[375255.130000] [29207] 0 29207 374 17 5 0 0 cgminer-monitor
[375255.130000] [29213] 0 29213 374 17 5 0 0 cgminer-monitor
[375255.140000] [29214] 0 29214 193 9 3 0 0 cgminer-api
[375255.150000] [29215] 0 29215 372 11 3 0 0 grep
[375255.160000] Out of memory: Kill process 22605 (cgminer) score 605 or sacrifice child
[375255.170000] Killed process 22605 (cgminer) total-vm:58568kB, anon-rss:18368kB, file-rss:0kB
Re: [7000GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Work is not lost using p2pool, those stale p2pool shares can still solve a block and still be submitted to the bitcoin network for reward. The time and work invested in them is not lost. Those shares just don't show up in the p2pool sharechain, but will show up in the bitcoin blockchain.
Doesn't a winning (bitcoin) block not override the share chain? Otherwise, that block couldn't actually be paid (by the share-chain)
Well, it depends on what you mean by "override."
A winning bitcoin block is sent to the bitcoin network and to the p2pool network. Bitcoin will payout the reward normally for the found block (including the finder's share). However, if the winning block isn't on the longest chain of the p2pool sharechain, it will get orphaned by the p2pool network.
In that case, the winning block is paid out and the solver will get credit for it for the current block (in addition to the 0.5% bonus for finding it), but the person that solved it won't get a credit for the share it for future blocks on the p2pool chain. This is fair because everyone has the same chance of it happening, and it does not mathematically affect expected payout for anyone. Additionally, this is extremely rare (<0.1% of blocks found will have this).
Ironically this just happened to me on the last block.
Re: [4000GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Cool, we just mined a block with 10.14311847 BTC in transaction fees
https://blockchain.info/block-index/406373/000000000000001514684f6f04348420660fa46ff02b36104623f9fcdfc75052
https://blockchain.info/block-index/406373/000000000000001514684f6f04348420660fa46ff02b36104623f9fcdfc75052
Re: [3500GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
An Avalon mining on P2Pool with even 3 modules does indeed take its CPU to the limit. The only real difference between P2Pool and other pools is that P2Pool's generation transaction is much larger. I'm guessing that the bottleneck is hashing the generation transaction ~16 times per second (though that isn't much...). If that's true, perhaps cgminer could be optimized to compress everything before the Stratum nonce to a SHA-256 midstate?
There's an obvious optimisation there that I didn't spot and it's only now that we have hardware being outstripped by the work generation requirements that I've looked into it. Thanks for the pointer, I shall see what I can do.Cool. Can't wait to test it.
Managed to figure out how to cross compile cgminer from the git repo.
Latest version brings down the CPU usage to ~20%, not quite as optimized as bfgminer, but now we have plenty of headroom on the TP-Link to hash at p2pool with full power.
Thank you ckolivas!
Re: [3500GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
An Avalon mining on P2Pool with even 3 modules does indeed take its CPU to the limit. The only real difference between P2Pool and other pools is that P2Pool's generation transaction is much larger. I'm guessing that the bottleneck is hashing the generation transaction ~16 times per second (though that isn't much...). If that's true, perhaps cgminer could be optimized to compress everything before the Stratum nonce to a SHA-256 midstate?
There's an obvious optimisation there that I didn't spot and it's only now that we have hardware being outstripped by the work generation requirements that I've looked into it. Thanks for the pointer, I shall see what I can do.Cool. Can't wait to test it.
If you haven't already, you have to delete/remove WiFi, not just disable/stop it. Network->Wifi->Remove
I've deleted but after few hours of mining I see the error message again:
Code:
usb 1-1: clear tt 1 (8030) error -71
usb 1-1: clear tt 1 (8030) error -71
usb 1-1: clear tt 1 (8030) error -71
usb 1-1: clear tt 1 (8030) error -71
usb 1-1: clear tt 1 (8030) error -71
Unload the wifi kernel modules.
log into ssh and rmmod the following:
Code:
ath9k
ath9k_common
ath9k_hw
ath
mac80211
cfg80211
ath9k_common
ath9k_hw
ath
mac80211
cfg80211
then cd into /etc/modules.d
and comment out, or if you're confident enough, delete the following files in that directory, to prevent them from being loaded on reboot:
Code:
20-cfg80211
21-mac80211
26-ath
27-ath9k-common
28-ath9k
21-mac80211
26-ath
27-ath9k-common
28-ath9k
Re: [3500GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
bfgminer has now been running for the past 20 hours on my Avalon @325 mining on p2pool. So far, it is working fast and stable.
Stats:
Output of top:
Stats:
Code:
Miner Status Uptime MH/s A R HW% Utility Invalid WU BestShare
001 ONLINE 0d 20:12:15 103454.057 6258 601 0.74% 5.162 8.76% 1445.371 11669957
001 ONLINE 0d 20:12:15 103454.057 6258 601 0.74% 5.162 8.76% 1445.371 11669957
Output of top:
Code:
Mem: 21880K used, 7220K free, 0K shrd, 2164K buff, 9140K cached
CPU: 3% usr 2% sys 0% nic 93% idle 0% io 0% irq 0% sirq
Load average: 0.05 0.08 0.12 3/42 1510
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
1274 1269 root S 27728 95% 6% bfgminer -S avalon:/dev/ttyUSB0 -o ht
1510 1505 root R 1500 5% 0% top
1505 1504 root S 1504 5% 0% -ash
1269 1268 root S 1504 5% 0% -ash
697 1 root S 1500 5% 0% /usr/sbin/ntpd -n -p 0.openwrt.pool.n
545 1 root S 1472 5% 0% /sbin/netifd
1 0 root S 1432 5% 0% /sbin/procd
1268 639 root S 1244 4% 0% /usr/sbin/dropbear -F -P /var/run/dro
1504 639 root S 1220 4% 0% /usr/sbin/dropbear -F -P /var/run/dro
655 1 root S 1164 4% 0% /usr/sbin/uhttpd -f -h /www -r OpenWr
639 1 root S 1156 4% 0% /usr/sbin/dropbear -F -P /var/run/dro
685 1 nobody S 956 3% 0% /usr/sbin/dnsmasq -C /var/etc/dnsmasq
432 1 root S < 904 3% 0% ubusd
434 1 root S 768 3% 0% /sbin/askfirst ttyATH0 /bin/ash --log
CPU: 3% usr 2% sys 0% nic 93% idle 0% io 0% irq 0% sirq
Load average: 0.05 0.08 0.12 3/42 1510
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
1274 1269 root S 27728 95% 6% bfgminer -S avalon:/dev/ttyUSB0 -o ht
1510 1505 root R 1500 5% 0% top
1505 1504 root S 1504 5% 0% -ash
1269 1268 root S 1504 5% 0% -ash
697 1 root S 1500 5% 0% /usr/sbin/ntpd -n -p 0.openwrt.pool.n
545 1 root S 1472 5% 0% /sbin/netifd
1 0 root S 1432 5% 0% /sbin/procd
1268 639 root S 1244 4% 0% /usr/sbin/dropbear -F -P /var/run/dro
1504 639 root S 1220 4% 0% /usr/sbin/dropbear -F -P /var/run/dro
655 1 root S 1164 4% 0% /usr/sbin/uhttpd -f -h /www -r OpenWr
639 1 root S 1156 4% 0% /usr/sbin/dropbear -F -P /var/run/dro
685 1 nobody S 956 3% 0% /usr/sbin/dnsmasq -C /var/etc/dnsmasq
432 1 root S < 904 3% 0% ubusd
434 1 root S 768 3% 0% /sbin/askfirst ttyATH0 /bin/ash --log
Re: [3500GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
The difference is staggering. HW error rate dropped from 0.95% to 0.58%, and cpu usage while mining on p2pool went from 90% down to 8% max.
Are you mining directly with stratum to p2pool?Yes.
Code:
root@OpenWrt:~# cgminer --lowmem --avalon-options 115200:32:10:43:300 -o stratum+tcp://192.168.1.77:9332 --api-allow W:127.0.0.1 --api-listen --avalon-cutoff 90 --avalon-temp 70
[2013-08-10 00:44:56] Started cgminer 3.3.1
[2013-08-10 00:44:57] Probing for an alive pool
[2013-08-10 00:44:57] Pool 0 difficulty changed to 82.382325
[2013-08-10 00:44:57] Pool 0 difficulty changed to 128
[2013-08-10 00:44:57] Stratum from pool 0 detected new block
[2013-08-10 00:44:57] Stratum from pool 0 requested work restart
[2013-08-10 00:44:56] Started cgminer 3.3.1
[2013-08-10 00:44:57] Probing for an alive pool
[2013-08-10 00:44:57] Pool 0 difficulty changed to 82.382325
[2013-08-10 00:44:57] Pool 0 difficulty changed to 128
[2013-08-10 00:44:57] Stratum from pool 0 detected new block
[2013-08-10 00:44:57] Stratum from pool 0 requested work restart
Re: [3500GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
This is the answer.
on p2pool, load average: 0.98 0.92 0.87
vs
ozco, load average: 0.19 0.16 0.20
on p2pool, load average: 0.98 0.92 0.87
vs
ozco, load average: 0.19 0.16 0.20
You do understand what the load average figures are telling you, right? It is simply a count of how many processes running on the system needed CPU time per second during that interval, it does not tell you anything at all about the actual CPU time spent servicing those processes.
Eg, if I do a
Code:
while /bin/true; do echo "."; sleep 1; done
The load average will show as 2, even though you can probably see that the actual amount of CPU time spent was likely < 0.001% ?
A high load average may be an indication of the system being CPU starved, but I'd judge "high load average" to be 10-12x the number of CPUs present in the system, depending on the type of processes the machine is running.
Of course I do.
In this case it is the cgminer process causing that load, just as ebereon suggested.
Tried bfgminer? Works better for me with my little Erupters.
Thanks for the suggestion.
After a bit of tinkering, and with the help of this script http://luke.dashjr.org/tmp/code/avalonhost-raminst, I managed to get the latest bfgminer working on my Avalon.
The difference is staggering. HW error rate dropped from 0.95% to 0.58%, and cpu usage while mining on p2pool went from 90% down to 8% max.
Re: [3500GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Are you using the latest 13.2 version of p2pool? Didn't 13.1 have issues with Avalons? Or was that something different?
My node is running from latest git commit:
P2Pool version: 0a3493d
Current local DOA is 5.9% and GBT Latency is < 0.1
Pretty sure the problem is cgminer requiring too many cpu cycles.
Re: [3500GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Please check the cpu load on your avalon. It is near 80% on my 3 module avalon and it can be 100% on a 4 module. If so, then thats the problem. The cpu is to tiny on the wrt board. If you realy want to use p2pool, then connect the avalon controller usb cable (remove Jumper J1 on the controller board) to a PC/Notebook and run cgminer on it. Everything is controlled by cgminer eg. fans, clocking etc.
This is the answer.
on p2pool, load average: 0.98 0.92 0.87
vs
ozco, load average: 0.19 0.16 0.20
Sorry if this has already been discussed:
Should I be connecting the second EPS12V CPU connection on the PDU board? It seems to be working just fine with one, but I'm not interested in toasting anything!
And if I should connect it, can I just use an 8-pin PCI-e connection? I've got only one "CPU" connection on my PSU.
Thanks all
Should I be connecting the second EPS12V CPU connection on the PDU board? It seems to be working just fine with one, but I'm not interested in toasting anything!
And if I should connect it, can I just use an 8-pin PCI-e connection? I've got only one "CPU" connection on my PSU.
Thanks all
Touch the wires. Slightly warmer than ambient is OK. Anything more is dangerous.
You absolutely CANNOT swap EPS12V for PCIE. Be careful because depending on the manufacturing tolerances, sometimes those molex plugs can fit the wrong socket. But I recommend you don't even try, it will short out the PSU.
That said, if someone knows what they are doing, they could theoretically change around the positives and negatives to make it work.
Re: [3500GH/s] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Is there anyone running an OC'd four module Avalon on p2pool?
I seem to get the same hashrate (90GH) at 325 as I do at 300, except with more heat and noise.
And I don't think it's a problem with power or cooling because if I switch to a different pool it hashes at around 105GH.
I seem to get the same hashrate (90GH) at 325 as I do at 300, except with more heat and noise.
And I don't think it's a problem with power or cooling because if I switch to a different pool it hashes at around 105GH.
Only 2 of those 24 wires carry 12VDC.
See the pinout:
http://image.pinout.net/pinout_network_rj45_files/24-pin-atx-pinout.gif
See the pinout:
http://image.pinout.net/pinout_network_rj45_files/24-pin-atx-pinout.gif
If you're looking to buy/host some Avalon batch 3 modules or if you want to sell some batch 3 clone parts (specifically a PDU and some cables), please see this thread: https://bitcointalk.org/index.php?topic=269802.msg2886697#msg2886697
So in retrospective, for those of us looking on what NOT to do and prevent accidents, why did this happen? That power supply should have handled current perfectly. Did you do custom cabling or what? I thought Avalon provided with proper cables. I still don't understand why this happened....
He ONLY installed the 24pin mainboard connector.
Sorry for my ignorance but what else was he supposed to connect? power only comes through one cable AFAIK.
I thought the same thing. And you if you try that, you'll end up with a melted miner. You have to hook up the 24pin ATX cable AND all of the power supply cables, like you would if you were supplying power to devices in your computer like a hard drive or a DVD player. Why it runs at all with only the single cable plugged in? I have no idea.
I've put this thread up as well to see how much interest is out there for buying Batch 3 modules: https://bitcointalk.org/index.php?topic=269845.0 I've gotten some serious offers, but most are lower than I was hoping.
Oh, I see. Seems kind of stupid that Corsair, OCZ and all those suppliers *assume* that the only application for their PSU is a PC.
I'd appreciate if you could point me to some thread that tells me how to "trick" the rest of the cables. I have a Corsair 750W and I read the manual but never did it say anything about connecting all of them.
However, I was planning to ONLY use the Molex connectors for my mining application anyway (I don't require the use of the 24-pin connector). Not sure if I'd be in trouble as well or whether the burning issue only happens when connecting the 24-connector cable alone...thoughts?
The problem had nothing to do with a single faulty wire or bad PSU.
The Avalon is not designed like a PC. All of its modules and controllers are all powered by that single PDU board.
Because the power supply has a single 12V rail, if you only have the ATX connector plugged in, the Avalon tries to pull all of the ~800W (66A) it requires from 2 tiny (18 gauge) leads.
That's ~33 amps per wire, but the maximum current they can safely handle is 6 amps each. The result is guaranteed melted wires, or worse as was the case here.
When all the plugs are attached to the PDU, there are 26x 12V leads sharing the load, a much more reasonable 2.5 amps each.