Topic: Official Avalon Technical Support Thread - page 15. (Read 48868 times)
silverserpent: That looks normal, to me. Matches mine.
Are these temps normal? Seems like F3 is slow...
StatusMHS5s MinerCountAsicCountFrequency Fan1 Fan2 Fan3 Temp1 Temp2 Temp3 NMW Firmware
Alive 74377.12 24 10 282 1440 2280 2160 22 42 44 80 20130419
StatusMHS5s MinerCountAsicCountFrequency Fan1 Fan2 Fan3 Temp1 Temp2 Temp3 NMW Firmware
Alive 74377.12 24 10 282 1440 2280 2160 22 42 44 80 20130419
Thanks for letting community know. Could you give us simple step-by-step guide how to do this?
I just went to the network section of the web ui and clicked the disable button for the wifi.Others have gone as far as disabling the interface, presumably something along the lines of:
Code:
ifconfig wlan0(?) down
Although that'd only last until reboot. A permanent settings change is probably done by clicking the disable button.
A tip for anyone struggling with the USB modem/dropout issue:
Following discussions on IRC (Freenode #avalon) a few of us have seemed to have solved the issue by disabling the wifi part of the TP-Link.
Thanks for letting community know. Could you give us simple step-by-step guide how to do this? Following discussions on IRC (Freenode #avalon) a few of us have seemed to have solved the issue by disabling the wifi part of the TP-Link.
A tip for anyone struggling with the USB modem/dropout issue:
Following discussions on IRC (Freenode #avalon) a few of us have seemed to have solved the issue by disabling the wifi part of the TP-Link.
Following discussions on IRC (Freenode #avalon) a few of us have seemed to have solved the issue by disabling the wifi part of the TP-Link.
Batch #2 do not have a P2 jumper on the fpga controller board.
I have Batch #2 units, and my controller boards do still have a P5 jumper. It's located just behind the USB type B receptacle. As shown in this picture.Ah!.. I seem to remember you had a "silver" case avalon. I guessing you got the last of the
Batch #2 do not have a P2 jumper on the fpga controller board.
I have Batch #2 units, and my controller boards do still have a P5 jumper. It's located just behind the USB type B receptacle. As shown in this picture. 
Q) What is this thread for?
A) This thread is for answering TECHNICAL questions only about the Avalon ASIC Bitcoin Miner
A) This thread is for answering TECHNICAL questions only about the Avalon ASIC Bitcoin Miner
Might be slighty off-topic, but still rather TECHNICAL:)
Is someone with an Avalon board willing to put a scope probe
on the REPORT_N/REPORT_P lines (pins 17 and 18) and observe
the timing of the signal? Interrested in:
- Up-going edge schape (it's a pulled-up pinch/release line,
could have RC characteristics).
- Clock period and duty cycle of 1 bit period.
- Length in bits of the sent data.
Will pay a BTC 0.10 bounty for the first, clear scope screen hardcopy.
Thx in advance,
intron
abracadabra: shunting J1 does precisely that: it powers the USB type B port on the control unit. Remove the J1 jumper when connecting the control unit to a host computer.
As to J2, I don't know its purpose.
As to J2, I don't know its purpose.
One of my Batch #2 Avalons is having trouble. Every so often (~15 minutes on average) I get a long burst of these kinds of messages in the System Log (dmesg):
While that is occuring, all mining stops. Either it eventually goes back to normal, or I see a message in the System Log saying that ttyUSB1 was disconnected, and then reconnected as ttyUSB0 (and vica-versa). cgminer dies if that happens, and restarts.
I have another Batch #2 running smoothly. So far, I have checked all of the connectors on the TP-LINK, PDU, and control unit. I replaced the PSU, left the cover off, and left the PSU outside of the unit. No joy. All of the version numbers match my other Batch #2, so there are no differences in software/firmware. One odd thing is that I notice mention of a usb hub on the wiki page, but there is no hub inside either of my black Avalons. Is the hub built into the control unit?
I can only think of two other things to try. Backup the working Avalon, and flash it to this Avalon, in case there's something weird in the software. Or, replace the TP-LINK with a RasPi and hope that the control unit isn't at fault.
Check the usb Cable first dude.Code:
May 18 06:42:59 avalon1 kern.err kernel: [ 3872.320000] usb 1-1: clear tt 1 (8040) error -71
May 18 06:42:59 avalon1 kern.err kernel: [ 3872.330000] ftdi_sio ttyUSB1: failed to get modem status: -71
May 18 06:42:59 avalon1 kern.err kernel: [ 3872.340000] usb 1-1: clear tt 1 (8040) error -71
May 18 06:42:59 avalon1 kern.err kernel: [ 3872.350000] ftdi_sio ttyUSB1: failed to get modem status: -71
May 18 06:42:59 avalon1 kern.err kernel: [ 3872.350000] usb 1-1: clear tt 1 (8040) error -71
May 18 06:42:59 avalon1 kern.err kernel: [ 3872.460000] ftdi_sio ttyUSB1: failed to get modem status: -32
While that is occuring, all mining stops. Either it eventually goes back to normal, or I see a message in the System Log saying that ttyUSB1 was disconnected, and then reconnected as ttyUSB0 (and vica-versa). cgminer dies if that happens, and restarts.
I have another Batch #2 running smoothly. So far, I have checked all of the connectors on the TP-LINK, PDU, and control unit. I replaced the PSU, left the cover off, and left the PSU outside of the unit. No joy. All of the version numbers match my other Batch #2, so there are no differences in software/firmware. One odd thing is that I notice mention of a usb hub on the wiki page, but there is no hub inside either of my black Avalons. Is the hub built into the control unit?
I can only think of two other things to try. Backup the working Avalon, and flash it to this Avalon, in case there's something weird in the software. Or, replace the TP-LINK with a RasPi and hope that the control unit isn't at fault.
If i were you i would remove p5 jumper, use USB powered hub and connect usb cable to batch one unit easiest or to linux PC to check. But first change usb cables and try other ports of internal usb hub if batch2 still has it
Batch #2 do not have a P2 jumper on the fpga controller board. They also do not have an external USB hub. It appears the v1.5 fpga controller boards in the batch #2 avalons have a renesas usb hub chip included to attempt to account for the usb stability problem with the tp703 See: https://forum.openwrt.org/viewtopic.php?id=39956
If anyone from Avalon reads this thread, could you please provide info on whether something can be changed on the fpga board so that it won't backfeed power on the usb port? It's been mentioned that attempting to connect the fpga board usb port to a desktop could cause problems since the fpga usb port is still powered.
What do J1 and J2 do?
Is it possible to JTAG firmware/bitstream to the fpga? Instructions?
TIA
After I switched to a corsair GS800, cgminer never restarted 
It seems that the original power supply (Antec Earthwatt 650) is a bit inadequate
It seems that the original power supply (Antec Earthwatt 650) is a bit inadequate
Perhaps, but mine is holding up remarkably well. 300 MHz clock speed and current uptime has been 6 days..woohoo!
I agree the EarthWatts 650 isn't enough. Mine just died. The Avalon is just too much for it.
Nice. I too grabbed a AX860 (not the i version as I don't need the fancy pants control feature) but have yet to put it into action - will do so when batch delivers...sometime this year hopefully 
I must also correct my statement there. At 300 the system consumes 625 to 630 watts at 120v. I finnally got around to putting a "kill-a-watt" type power meter on my unit and that what it says. Keeping in mind that the batch 1 units came with Antec 650 Watt units, I am quite amazed my unit's PSU has lasted this lost at what is pretty much almost 100% capacity.
I must also correct my statement there. At 300 the system consumes 625 to 630 watts at 120v. I finnally got around to putting a "kill-a-watt" type power meter on my unit and that what it says. Keeping in mind that the batch 1 units came with Antec 650 Watt units, I am quite amazed my unit's PSU has lasted this lost at what is pretty much almost 100% capacity.
Consider posting what your voltage is at that effects the power draw in watt units.
I am below 600 watts on a hot day 28-31 Ambient temp at 120v with the 860i
Nice. I too grabbed a AX860 (not the i version as I don't need the fancy pants control feature) but have yet to put it into action - will do so when batch delivers...sometime this year hopefully
I must also correct my statement there. At 300 the system consumes 625 to 630 watts at 120v. I finnally got around to putting a "kill-a-watt" type power meter on my unit and that what it says. Keeping in mind that the batch 1 units came with Antec 650 Watt units, I am quite amazed my unit's PSU has lasted this lost at what is pretty much almost 100% capacity.
I must also correct my statement there. At 300 the system consumes 625 to 630 watts at 120v. I finnally got around to putting a "kill-a-watt" type power meter on my unit and that what it says. Keeping in mind that the batch 1 units came with Antec 650 Watt units, I am quite amazed my unit's PSU has lasted this lost at what is pretty much almost 100% capacity.
Enermax has a really good reputation.
Can you name the exact type
Can you name the exact type
ENM750EWT-S 80plus Gold
Are you running the miners at 300? If so this PSU might not be able to take such high level of load for a long time (at 300 the power consumption should be close to 710 to 720 watts...possibly less if your psu is 80+ platinum). It is also possible that your PSUs were in a "bad batch" (assuming you bought them from the same place all at once)
I got a Corsair AX860 but I've yet to install it. From what I read these are good PSUs.
I upgraded to Corsair AX860i and they are have had no problems with up time.
I have posted details about this here.
https://bitcointalksearch.org/topic/m.1910169
Nice tuning. How did you do this?
Check the monitoring script
/usr/bin/cgminer-monitor
which is called by cron
Quote
i believe if your vardiff is set high enough, then you might not submit a share every 5 minutes. this might happened due to random variance...but the higher your vardiff, the more likely you'll hit the 5 minutes mark.
cgminer-monitor is looking at the hardware's Diff1Shares, not shares submitted to the server, so difficulty shouldn't matter.
i believe if your vardiff is set high enough, then you might not submit a share every 5 minutes. this might happened due to random variance...but the higher your vardiff, the more likely you'll hit the 5 minutes mark.
i have a script that poles the cgminer API and reboots a power switch if my hash rate drops to a very low rate for a minute. i think the cgminer stats are more accurate than the last accepted share that the cronjob uses.
i have a script that poles the cgminer API and reboots a power switch if my hash rate drops to a very low rate for a minute. i think the cgminer stats are more accurate than the last accepted share that the cronjob uses.
Any ideas why it was set to 5 min and not something shorter?
Maybe to give it some time to cool down (?)
Nice tuning. How did you do this?
Check the monitoring script
/usr/bin/cgminer-monitor
which is called by cron
use
Code:
crontab -l
Code:
*/5 * * * * /usr/bin/cgminer-monitor
You can edit crontab files by using
Code:
crontab -e
but be carefull, it drops you into vi and for some of you that might be a
If you want to keep track of restarts, just add
Code:
DATE=`date +%Y%m%d-%H%M%S`
and
Code:
echo $DATE cgminer restart >> /tmp/cgminer-log
to the cgminer-monitor script in the right place in the loop where it calls
Code:
/etc/init.d/cgminer restart
You can even add more sophisticated mods so that the log file is parsed by server side includes and shown in the web interface but I'm just too lazy to have that done.
Setting it more aggressive to < 5 minutes might have the effect on some more unreliable pools that have network issues like Eligiust, that your cgminer restarts whenever there is a hickup
I've modified the cronjob that checks whether cgminer is running to once every minute (instead of the 5 min).
Hopefully this will increase the effective hashrate by eliminating 5 min of downtime everytime cgminer hangs.
Any ideas why it was set to 5 min and not something shorter?
Nice tuning. How did you do this? Hopefully this will increase the effective hashrate by eliminating 5 min of downtime everytime cgminer hangs.
Any ideas why it was set to 5 min and not something shorter?
Jump to: