TO dispell overheating issues
i run 10 side by side very close, no fan, in 80deg ambient
Topic: USB ASIC ERUPTER - Setup & Config. BCG Miner, cgminer & Hubs "Oh Pi"! (Read 156864 times)
September 22, 2013, 10:45:38 PM
September 21, 2013, 04:40:25 AM
I always wonder when was the first time someone said 'dude I bet if I move this here and buzz it here and jibrz here , I can get more hash from this thing'
I mean that dude must be a little crazy in the head to jeoperdize a miner with playing , who can guarentee that it wont break 
September 21, 2013, 04:32:16 AM
...
Interesting. Makes sense. Could you share your cron job ? It's not ideal but should get me hashing again until Raspbian gets a fix.
...
I have a program I wrote > 10 years ago (sem) that simply does nothing in the case (in this example) that the script tries to run twice at the same time - so this script would require a bit of work to get it going ... but anyway here's the concept:Interesting. Makes sense. Could you share your cron job ? It's not ideal but should get me hashing again until Raspbian gets a fix.
...
Code:
#!/bin/bash
#
#set -x
#
sem="/root/chkpisem"
#
if [ "$1" != "boo" ] ; then
touch "$sem"
/root/sem -q "$sem" "$0" "boo" >> /root/chkpi.log 2>&1
exit 0
fi
#
last="/root/lastchkpi"
#
ip1="192.168.?.?"
ip2="192.168.?.?"
ip3="192.168.?.?"
#
chk()
{
ping -n -w 5 -c 1 "$1" 2>&1
r="$?"
if [ "$r" == "0" ] ; then
echo -e "`date "+%s"`\nLast Valid Ping to $1: `date`" > "$last"
# stop checking as soon as we find one
exit 0
fi
}
#
# In case of network delays during system startup
sleep 60
#
chk "$ip1" > /dev/null
chk "$ip2" > /dev/null
chk "$ip3" > /dev/null
#
now="`date "+%s"`"
lst="`head -1 "$last"`"
#
dif="`echo "$now $lst - p" | dc`"
#
# 5 minutes
if [ "$dif" -gt "299" ] ; then
date
echo "No ping for 5 minutes (dif=$dif) ..."
chk "$ip1"
chk "$ip2"
chk "$ip3"
echo "Shutting down ..."
/root/cgdown
fi
#
#set -x
#
sem="/root/chkpisem"
#
if [ "$1" != "boo" ] ; then
touch "$sem"
/root/sem -q "$sem" "$0" "boo" >> /root/chkpi.log 2>&1
exit 0
fi
#
last="/root/lastchkpi"
#
ip1="192.168.?.?"
ip2="192.168.?.?"
ip3="192.168.?.?"
#
chk()
{
ping -n -w 5 -c 1 "$1" 2>&1
r="$?"
if [ "$r" == "0" ] ; then
echo -e "`date "+%s"`\nLast Valid Ping to $1: `date`" > "$last"
# stop checking as soon as we find one
exit 0
fi
}
#
# In case of network delays during system startup
sleep 60
#
chk "$ip1" > /dev/null
chk "$ip2" > /dev/null
chk "$ip3" > /dev/null
#
now="`date "+%s"`"
lst="`head -1 "$last"`"
#
dif="`echo "$now $lst - p" | dc`"
#
# 5 minutes
if [ "$dif" -gt "299" ] ; then
date
echo "No ping for 5 minutes (dif=$dif) ..."
chk "$ip1"
chk "$ip2"
chk "$ip3"
echo "Shutting down ..."
/root/cgdown
fi
And then the cgdown script - though I could update this to use Multicast - but I haven't
It just sends a 'quit' to all ports 4020 to 4049
Code:
#!/bin/bash
#
echo "`date`: CGDOWN"
#
i="4020"
while [ "$i" -lt "4050" ] ; do
echo "127.0.0.1 $i"
echo -n quit | nc -4 -w 1 127.0.0.1 $i
i=$[$i+1]
done
#
echo "`date` sleep 10"
sleep 10
#
date
#
echo "shutdown -h now"
shutdown -h now
#
echo "`date`: CGDOWN"
#
i="4020"
while [ "$i" -lt "4050" ] ; do
echo "127.0.0.1 $i"
echo -n quit | nc -4 -w 1 127.0.0.1 $i
i=$[$i+1]
done
#
echo "`date` sleep 10"
sleep 10
#
date
#
echo "shutdown -h now"
shutdown -h now
The whole process is quite slow - but the point is that rather than having to switch it off if you don't have a keyboard+screen, it will do it itself.
You could of course change it to "shutdown -r now" - though if the network didn't came back up alive it would keep doing it over and over.
There are probably better ways to do this - but this one is pretty simple
September 20, 2013, 05:35:51 PM
The network connection is USB also (on the motherboard of course)
You will most likely find in the system log a comment about the network device failing.
On mine I wrote a cron job that runs every minute and checks the network and if it's not working, it send cgminer a quit and shuts down the RPi
The main reason for this is that obviously pulling the power out while the RPi is running is a bad idea, and once the network dies it seems it wont restart without a reboot anyway
Sounds like Raspbian have screwed up something there with the update
The network dropout isn't unknown, just it seemed to have become quite rare at least up until recently.
I've had it happen once on Arch (but only once) but a few times on Raspbian (used to sometimes happen when I plugged in an Icarus pl2303)
You will most likely find in the system log a comment about the network device failing.
On mine I wrote a cron job that runs every minute and checks the network and if it's not working, it send cgminer a quit and shuts down the RPi
The main reason for this is that obviously pulling the power out while the RPi is running is a bad idea, and once the network dies it seems it wont restart without a reboot anyway
Sounds like Raspbian have screwed up something there with the update
The network dropout isn't unknown, just it seemed to have become quite rare at least up until recently.
I've had it happen once on Arch (but only once) but a few times on Raspbian (used to sometimes happen when I plugged in an Icarus pl2303)
Interesting. Makes sense. Could you share your cron job ? It's not ideal but should get me hashing again until Raspbian gets a fix.
The last few entires in my syslog before I have to hard reset is as follows :
Quote
Sep 20 16:00:22 raspberrypi kernel: [ 59.983209] netlink: 20 bytes leftover after parsing attributes.
Sep 20 16:00:22 raspberrypi kernel: [ 59.983245] netlink: 20 bytes leftover after parsing attributes.
Sep 20 16:00:22 raspberrypi kernel: [ 59.983392] netlink: 20 bytes leftover after parsing attributes.
Sep 20 16:00:22 raspberrypi kernel: [ 59.983245] netlink: 20 bytes leftover after parsing attributes.
Sep 20 16:00:22 raspberrypi kernel: [ 59.983392] netlink: 20 bytes leftover after parsing attributes.
I have done some more testing. I can't get the RPi to loose its network connectivity and need resetting apart from when running cgminer. I've tried hammering the NIC with heavy downloading and it handles it fine. I've removed all but 3 Block Erupter USB's just in case it was a power issue but it's not. Im running a D-Link DUB-H7 with 5 Erupter's total.
I wonder whats so specific about cgminer that causes the nic to hang under the current Raspbian...
September 20, 2013, 05:08:30 PM
The network connection is USB also (on the motherboard of course)
You will most likely find in the system log a comment about the network device failing.
On mine I wrote a cron job that runs every minute and checks the network and if it's not working, it send cgminer a quit and shuts down the RPi
The main reason for this is that obviously pulling the power out while the RPi is running is a bad idea, and once the network dies it seems it wont restart without a reboot anyway
Sounds like Raspbian have screwed up something there with the update
The network dropout isn't unknown, just it seemed to have become quite rare at least up until recently.
I've had it happen once on Arch (but only once) but a few times on Raspbian (used to sometimes happen when I plugged in an Icarus pl2303)
You will most likely find in the system log a comment about the network device failing.
On mine I wrote a cron job that runs every minute and checks the network and if it's not working, it send cgminer a quit and shuts down the RPi
The main reason for this is that obviously pulling the power out while the RPi is running is a bad idea, and once the network dies it seems it wont restart without a reboot anyway
Sounds like Raspbian have screwed up something there with the update
The network dropout isn't unknown, just it seemed to have become quite rare at least up until recently.
I've had it happen once on Arch (but only once) but a few times on Raspbian (used to sometimes happen when I plugged in an Icarus pl2303)
Interesting. Makes sense. Could you share your cron job ? It's not ideal but should get me hashing again until Raspbian gets a fix.
The last few entires in my syslog before I have to hard reset is as follows :
Quote
Sep 20 16:00:22 raspberrypi kernel: [ 59.983209] netlink: 20 bytes leftover after parsing attributes.
Sep 20 16:00:22 raspberrypi kernel: [ 59.983245] netlink: 20 bytes leftover after parsing attributes.
Sep 20 16:00:22 raspberrypi kernel: [ 59.983392] netlink: 20 bytes leftover after parsing attributes.
Sep 20 16:00:22 raspberrypi kernel: [ 59.983245] netlink: 20 bytes leftover after parsing attributes.
Sep 20 16:00:22 raspberrypi kernel: [ 59.983392] netlink: 20 bytes leftover after parsing attributes.
I have done some more testing. I can't get the RPi to loose its network connectivity and need resetting apart from when running cgminer. I've tried hammering the NIC with heavy downloading and it handles it fine. I've removed all but 3 Block Erupter USB's just in case it was a power issue but it's not. Im running a D-Link DUB-H7 with 5 Erupter's total.
I wonder whats so specific about cgminer that causes the nic to hang under the current Raspbian...
September 20, 2013, 09:49:07 AM
The network connection is USB also (on the motherboard of course)
You will most likely find in the system log a comment about the network device failing.
On mine I wrote a cron job that runs every minute and checks the network and if it's not working, it send cgminer a quit and shuts down the RPi
The main reason for this is that obviously pulling the power out while the RPi is running is a bad idea, and once the network dies it seems it wont restart without a reboot anyway
Sounds like Raspbian have screwed up something there with the update
The network dropout isn't unknown, just it seemed to have become quite rare at least up until recently.
I've had it happen once on Arch (but only once) but a few times on Raspbian (used to sometimes happen when I plugged in an Icarus pl2303)
You will most likely find in the system log a comment about the network device failing.
On mine I wrote a cron job that runs every minute and checks the network and if it's not working, it send cgminer a quit and shuts down the RPi
The main reason for this is that obviously pulling the power out while the RPi is running is a bad idea, and once the network dies it seems it wont restart without a reboot anyway
Sounds like Raspbian have screwed up something there with the update
The network dropout isn't unknown, just it seemed to have become quite rare at least up until recently.
I've had it happen once on Arch (but only once) but a few times on Raspbian (used to sometimes happen when I plugged in an Icarus pl2303)
September 20, 2013, 07:42:48 AM
So I got a kinda weird issue.
I started mining on my Raspberry Pi (O/S: Raspian) with 5 Block Eruptors on a DLink DUB-7 on August 19th using cgminer 3.3.4 and followed the included instructions on how to compile the libusb libraries myself. It worked great and it ran non-stop for a few weeks. The other day I decided to update cgminer to 3.4.2. After mining for about 20 minutes the Pi seemed to locked up. My SSH session died and I couldn't ping the Pi anymore. I figured it was just a fluke so I restarted the Pi but, again, after mining for about 20 minutes the Pi locks up.
I figured that this must have just been an issue with the newest version of cgminer so I went back to 3.3.4 with no luck. 3.3.4 now causes the Pi to lock up as well. I thought that maybe the Pi was overheating so I tried doing something else intensive; watching a 1080p movie over my LAN for 2hrs+ but it worked great and never locked up. I also tried mining just with 1 miner but the Pi still locked up.
Perhaps there is an issue with the newest packages for the Pi? How can I provide some more detailed info to see what is going on? Anything else I can try to resolve the issue?
I've also posted this issue in the cgminer thread https://bitcointalksearch.org/topic/m.3121424
I started mining on my Raspberry Pi (O/S: Raspian) with 5 Block Eruptors on a DLink DUB-7 on August 19th using cgminer 3.3.4 and followed the included instructions on how to compile the libusb libraries myself. It worked great and it ran non-stop for a few weeks. The other day I decided to update cgminer to 3.4.2. After mining for about 20 minutes the Pi seemed to locked up. My SSH session died and I couldn't ping the Pi anymore. I figured it was just a fluke so I restarted the Pi but, again, after mining for about 20 minutes the Pi locks up.
I figured that this must have just been an issue with the newest version of cgminer so I went back to 3.3.4 with no luck. 3.3.4 now causes the Pi to lock up as well. I thought that maybe the Pi was overheating so I tried doing something else intensive; watching a 1080p movie over my LAN for 2hrs+ but it worked great and never locked up. I also tried mining just with 1 miner but the Pi still locked up.
Perhaps there is an issue with the newest packages for the Pi? How can I provide some more detailed info to see what is going on? Anything else I can try to resolve the issue?
I've also posted this issue in the cgminer thread https://bitcointalksearch.org/topic/m.3121424
I'm getting the same problem here. Everything was running fine for weeks until I decided to apt-get update; apt-get upgrade the Pi and recompile from cgminer v3.3.1 to v3.4.3. I've also tried reverting to v3.3.1 and I still get a problem. This only seems leaves one of the raspbian (jessie) updates as the possible culprit.
September 17, 2013, 12:15:05 AM
32 Erupters running on Weezy and cgminer 3.1.1
14 more to go...
September 16, 2013, 06:20:45 PM
I have windows 32 bit on a netbook but the winusb driver install via Zadig keeps failing
Win7 or XP?
There are two different versions of Zadig, one for Windoze XP and the other for everything else.
I had very poor results with WinXP. Win7 was really easy.
September 16, 2013, 11:30:56 AM
I have windows 32 bit on a netbook but the winusb driver install via Zadig keeps failing
has anyone had an issue with this
and if so how did you fix it
thankyou
has anyone had an issue with this
and if so how did you fix it
thankyou
September 14, 2013, 10:45:23 PM
Cgminer 3.1.1 with 20 erupters I have 10 more waiting for my new hubs on Monday. Getting close to my 49 goal.
September 14, 2013, 12:47:24 PM
As I write this, I'm plugging in a 4th erupter into one of the dlinks and... zombie. Surprisingly, that only look less than 1 minute to happen.
I had a similar issue too. I had 5 Rosewill 5 port hubs with 4 erupters each running perfectly stable. Then I got 3 Anker 9+1 hubs and added my remaining Erupters and ran into the same symptoms.
In another thread Trongersol suggested daisy chaining the problem Hubs off of reliable hubs, more or less. So I plugged my Ankers into the Rosewills and all is stable once again.
I'm not quite sure why, I it may be related to impermanence mismatch or organization of devices behind controllers, dunno, but my setup is stable again.
Sam
September 14, 2013, 12:29:59 PM
How can everyone run 5 or 6 erupters on a dlink and I can't?
I'm running Windows 7 (64 bit), cgminer 3.4.2, zadig, system fan pointing at all erupters.
I had 8 erupters running smoothly off of two Belkin 4 port hubs for several days (hw under 1%). I have 12 more erupters so I thought I would grab a couple d-link 7 ports (same one everyone has been talking about).
My issue.... I can't seem to get more than 3 running on a dlink... no idea why. Right now I have 14 running smoothly (8 on two Belkin hubs, 6 on two dlink hubs) for 28 minutes now. As I write this, I'm plugging in a 4th erupter into one of the dlinks and... zombie. Surprisingly, that only look less than 1 minute to happen.
Errors I see:
AMU1: Comms error (werr=-7 amt-0)
AMU4: Comms error (werr=-7 amt-0)
AMU 4 failure, disabling!
AMU5: TIMEOUT GetResults took 1001ms but was 100ms
My cgminer command line is:
cgminer-nogpu.exe -o http://stratum.bitcoin.cz:3333 -u xxx -p xxx
I don't have the icarus commands because the newer versions don't need it and just ignore it anyway.
Thoughts?
I'm running Windows 7 (64 bit), cgminer 3.4.2, zadig, system fan pointing at all erupters.
I had 8 erupters running smoothly off of two Belkin 4 port hubs for several days (hw under 1%). I have 12 more erupters so I thought I would grab a couple d-link 7 ports (same one everyone has been talking about).
My issue.... I can't seem to get more than 3 running on a dlink... no idea why. Right now I have 14 running smoothly (8 on two Belkin hubs, 6 on two dlink hubs) for 28 minutes now. As I write this, I'm plugging in a 4th erupter into one of the dlinks and... zombie. Surprisingly, that only look less than 1 minute to happen.
Errors I see:
AMU1: Comms error (werr=-7 amt-0)
AMU4: Comms error (werr=-7 amt-0)
AMU 4 failure, disabling!
AMU5: TIMEOUT GetResults took 1001ms but was 100ms
My cgminer command line is:
cgminer-nogpu.exe -o http://stratum.bitcoin.cz:3333 -u xxx -p xxx
I don't have the icarus commands because the newer versions don't need it and just ignore it anyway.
Thoughts?
September 10, 2013, 08:56:43 AM
So I got a kinda weird issue.
I started mining on my Raspberry Pi (O/S: Raspian) with 5 Block Eruptors on a DLink DUB-7 on August 19th using cgminer 3.3.4 and followed the included instructions on how to compile the libusb libraries myself. It worked great and it ran non-stop for a few weeks. The other day I decided to update cgminer to 3.4.2. After mining for about 20 minutes the Pi seemed to locked up. My SSH session died and I couldn't ping the Pi anymore. I figured it was just a fluke so I restarted the Pi but, again, after mining for about 20 minutes the Pi locks up.
I figured that this must have just been an issue with the newest version of cgminer so I went back to 3.3.4 with no luck. 3.3.4 now causes the Pi to lock up as well. I thought that maybe the Pi was overheating so I tried doing something else intensive; watching a 1080p movie over my LAN for 2hrs+ but it worked great and never locked up. I also tried mining just with 1 miner but the Pi still locked up.
Perhaps there is an issue with the newest packages for the Pi? How can I provide some more detailed info to see what is going on? Anything else I can try to resolve the issue?
I've also posted this issue in the cgminer thread https://bitcointalksearch.org/topic/m.3121424
I started mining on my Raspberry Pi (O/S: Raspian) with 5 Block Eruptors on a DLink DUB-7 on August 19th using cgminer 3.3.4 and followed the included instructions on how to compile the libusb libraries myself. It worked great and it ran non-stop for a few weeks. The other day I decided to update cgminer to 3.4.2. After mining for about 20 minutes the Pi seemed to locked up. My SSH session died and I couldn't ping the Pi anymore. I figured it was just a fluke so I restarted the Pi but, again, after mining for about 20 minutes the Pi locks up.
I figured that this must have just been an issue with the newest version of cgminer so I went back to 3.3.4 with no luck. 3.3.4 now causes the Pi to lock up as well. I thought that maybe the Pi was overheating so I tried doing something else intensive; watching a 1080p movie over my LAN for 2hrs+ but it worked great and never locked up. I also tried mining just with 1 miner but the Pi still locked up.
Perhaps there is an issue with the newest packages for the Pi? How can I provide some more detailed info to see what is going on? Anything else I can try to resolve the issue?
I've also posted this issue in the cgminer thread https://bitcointalksearch.org/topic/m.3121424
September 10, 2013, 04:22:22 AM
I am currently hashing with 20 erupters on my pi running weezey and cgminer 3.1.1 and seeing around 2% errors. My plan is to run 50 sticks on this unit and run several in tandem. My electricity is free (solar in the summer and hydro in the winter) minus propane cost when I need to run the gen. Im wondering if anyone has maxed a pi out yet? I have read a lot of speculation about this but no one who has actually done it.
September 09, 2013, 10:13:27 PM
Running win 7. Currently have 3 instances going. one with 4 miners, two with 6 each. Adding more soon. Would be nice if my bfl miner ever got here.
September 09, 2013, 09:45:39 PM
The 14+ device issue on windows is due to not resizing the command prompt.
September 09, 2013, 09:44:43 PM
hey guys. Currently running CGminer 3.1.1 I can only get 13 erupters going.
What OS are you using?
I'm running Win7 64 bit with 23 Erupters, so far, with CGMiner 3.4.2.
I tried WinXP, I wanted to setup backup PC but had trouble and couldn't get more than 13 running either. So I setup a Win7 32 bit laptop as my backup and it works fine too.
September 09, 2013, 07:33:50 PM
hey guys. Currently running CGminer 3.1.1 I can only get 13 erupters going. I have the power to do more, but the program wont start if there are more of them. Also the box seems to be too small to show all the devices.
C:\Users\****\Desktop\cgminer-3.1.1-windows\cgminer-nogpu.exe -o stratum.btcguild.com:3333 -u *** -p *** --icarus-options 115200:1:1 --icarus-timing 3.0=100 -S \\.\COM36 -S \\.\COM7 -S \\.\COM38
Except I have a bunch more -S\\.\COM##.
At 13 it runs flawlessly, but as soon as i add the 14th unit the program wont launch. I really would prefer to not have 2 machines having to mine, considering the second only has 3 erupters in it.
EDIT:
Set up 2 different instances, and now all is well, hashing on the same machine.
C:\Users\****\Desktop\cgminer-3.1.1-windows\cgminer-nogpu.exe -o stratum.btcguild.com:3333 -u *** -p *** --icarus-options 115200:1:1 --icarus-timing 3.0=100 -S \\.\COM36 -S \\.\COM7 -S \\.\COM38
Except I have a bunch more -S\\.\COM##.
At 13 it runs flawlessly, but as soon as i add the 14th unit the program wont launch. I really would prefer to not have 2 machines having to mine, considering the second only has 3 erupters in it.
EDIT:
Set up 2 different instances, and now all is well, hashing on the same machine.
September 03, 2013, 01:39:07 AM
Update to 3.4.2
(Just in case you have any BFL SC mining with them also)
However, if they overheat, there is indeed no temperature sensor ...
(Just in case you have any BFL SC mining with them also)
However, if they overheat, there is indeed no temperature sensor ...
I'll update and see how they run for the next day or so. I don't think its overheating, as I've got a usb fan pointed at them, and the desk is fairly well ventilated. Also, the sticks cut out after a random period time, rather than more predictably, leading me to believe it's not heat related.
Jump to: