I am going to share the process I use to keep my AntMiners running/hashing without any interaction on my part. I have 8 AntMiner U3's that are constantly running for me without an issue with the process I came up with.
Specs: Windows 7 Ultimate 64 BIT, 8 AntMiner U3 2nd Gens, latest version of cgminer, 2 non-powered 4 port USB hubs, zadig utility for the driver
First thing I did was made a batch file with the following:
:loop
cgminer.exe -o etc etc etc etc etc etc
timeout /T 10
goto loop
Next thing you will need to do is download "devcon.exe" from microsoft and drop that in c:\Windows\
Here is my 2nd batch file, which is called by a scheduled task every 2 hours...
taskkill /f /im cgminer.exe
devcon disable *PID_EA60
ping -n 15 127.0.0.1 >nul
devcon enable *PID_EA60
The first batch file is always running, once the second one starts it kills cgminer...the first script will restart cgminer after 10 seconds....
The second script kills cgminer so that devcon may disable the miners, then wait 15 seconds and re-enable them...
After a few seconds cgminer will pick back up with all the miners and start hashing again...
If anyone finds this useful and would like to tip here is my btc address: 1LqrCgqSWuHaJuZEkD5ViqD6UQ94nMA3nD
Topic: ANTMINER U3 Discussion and Support Thread - page 29. (Read 149480 times)
I'm kinda getting a feeling that the only problems arise when there's more than one U3 plugged in? Has anyone had the same problem with just one U3 running?
This is pretty much what I've encountered. I have 3 miners running for 7 days and 1 hour on three different computers, in that time, one slipped from port 0 to port 1, but it's still hashing fine.
http://solo.ckpool.org/users/14LxDWtRRdQAbnJdd4Ew5jwag8Bx9UfNRd
I'm kinda getting a feeling that the only problems arise when there's more than one U3 plugged in? Has anyone had the same problem with just one U3 running?
If you are trying to mine more than One pool at a time you can use the --load-balance strategy. The pools can send different values for min. diff. and it will not bother your devices. You do not need to address the miners separately either.
Thanks for the advice. But that only works if you had stable miners, not like the 2 Antminer U3 that I have which are always dead in just a few hours if I had it running above 60 GH/s each. The main idea to manage my 2 miners with 2 separate processes is mainly to be able to restart them separately when one of them is dead. The principle is the same as if I wanted to connect them to 2 different mining pools in parallel.If you are trying to mine more than One pool at a time you can use the --load-balance strategy. The pools can send different values for min. diff. and it will not bother your devices. You do not need to address the miners separately either.
Thanks for the advice. But that only works if you had stable miners, not like the 2 Antminer U3 that I have which are always dead in just a few hours if I had it running above 60 GH/s each. The main idea to manage my 2 miners with 2 separate processes is mainly to be able to restart them separately when one of them is dead. The principle is the same as if I wanted to connect them to 2 different mining pools in parallel.
If you are trying to mine more than One pool at a time you can use the --load-balance strategy. The pools can send different values for min. diff. and it will not bother your devices. You do not need to address the miners separately either.
I want cgminer to use Antminer U3 that is plugged in to /dev/ttyUSB1. But I can only specify which USB device to use with parameter --usb :. I found this a quite strange approach as we all know that the always changes when we unplug/re-plug USB device. So I got my first ZOMBIE message on cgminer's UI as below when I did the test to unplug my Antminer U3 when it was running with /dev/ttyUSB1, and then re-plugged it again. The of the Antminer U3' USB was initially 087 when cgminer was happily connected to it.
The reason is direct USB bypasses the serial device driver entirely taking out one more potential point of failure and decreasing latency and communication issues to the device. Direct USB doesn't use ttyUSB* at all. It also makes hotplug possible without needing to "scan ports". If the device doesn't reappear and work properly after failure on another usb device id, it won't work at all, regardless of which ttyusb it tries to attach to since the ttyusb is an extra layer on top of whichever device usb it appears as.Thanks for your explanation, Con.
I completely agree that there are some advantages by bypassing the use of ttyUSB*. So I do believe that this is a good approach. However, what I don't think a good one as I pointed out before is the use of
I know that we can let cgminer to claim all serial devices of the miners that are connected. But the problem in doing that is (as far as I understood it until now) if we had multiple miners, it is not possible to set a group of them to one mining pool and the other group to other mining pool with two different cgminer processes. In my case, I have only 2 Antminer U3' and I want each of them to connect to different mining pools.
Perhaps we could use different ID which is very likely to remain like the "Port ID" shown below.
Code:
root@wlan01:~# lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 79, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 92, If 0, Class=Vendor Specific Class, Driver=cp210x, 12M
|__ Port 2: Dev 94, If 0, Class=Vendor Specific Class, Driver=cp210x, 12M
root@wlan01:~#
I am not a programmer so I have no clue how to get that so that we can use it as the argument for --usb parameter like below.
Code:
For the 1st miner: --usb 1-1.1.1
For the 2nd miner: --usb 1-1.1.2
You might notice that I am using external USB hub (Port 1: Dev 79). Some people might use multiple of them, so the argument could be long. But I believe their values remain the same, unless we move them to different ports or switch them off and on in different sequence.
Cheers,
Anto
I want cgminer to use Antminer U3 that is plugged in to /dev/ttyUSB1. But I can only specify which USB device to use with parameter --usb :. I found this a quite strange approach as we all know that the always changes when we unplug/re-plug USB device. So I got my first ZOMBIE message on cgminer's UI as below when I did the test to unplug my Antminer U3 when it was running with /dev/ttyUSB1, and then re-plugged it again. The of the Antminer U3' USB was initially 087 when cgminer was happily connected to it.
The reason is direct USB bypasses the serial device driver entirely taking out one more potential point of failure and decreasing latency and communication issues to the device. Direct USB doesn't use ttyUSB* at all. It also makes hotplug possible without needing to "scan ports". If the device doesn't reappear and work properly after failure on another usb device id, it won't work at all, regardless of which ttyusb it tries to attach to since the ttyusb is an extra layer on top of whichever device usb it appears as. I have only ever had to unplug/replug the usb, was running 8 U3's all at once on one machine...a few would be zombied...I could tell which were zombied by actually feeling the power supplies...whichever ones were cool I simply unplugged/replugged in the USB and cgminer would pick it back up and start hashing
I want cgminer to use Antminer U3 that is plugged in to /dev/ttyUSB1. But I can only specify which USB device to use with parameter --usb
I expected this problem, that is why I wrote above this is a strange approach. The dmesg output confirms that the
Code:
.
.
[8147725.450000] usb 1-1.1.2: new full-speed USB device number 87 using ehci-platform
[8147725.590000] cp210x 1-1.1.2:1.0: cp210x converter detected
[8147725.690000] usb 1-1.1.2: reset full-speed USB device number 87 using ehci-platform
[8147725.830000] usb 1-1.1.2: cp210x converter now attached to ttyUSB1
[8147920.210000] cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1
[8147920.230000] cp210x 1-1.1.2:1.0: device disconnected
[8155037.580000] usb 1-1.1.2: USB disconnect, device number 87
[8155047.390000] usb 1-1.1.2: new full-speed USB device number 88 using ehci-platform
[8155047.530000] cp210x 1-1.1.2:1.0: cp210x converter detected
[8155047.630000] usb 1-1.1.2: reset full-speed USB device number 88 using ehci-platform
[8155047.770000] usb 1-1.1.2: cp210x converter now attached to ttyUSB1
[8155390.440000] usb 1-1.1.2: USB disconnect, device number 88
[8155390.450000] cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1
[8155390.460000] cp210x 1-1.1.2:1.0: device disconnected
[8155395.810000] usb 1-1.1.2: new full-speed USB device number 89 using ehci-platform
[8155395.950000] cp210x 1-1.1.2:1.0: cp210x converter detected
[8155396.050000] usb 1-1.1.2: reset full-speed USB device number 89 using ehci-platform
[8155396.190000] usb 1-1.1.2: cp210x converter now attached to ttyUSB1
Your method might work if I setup cgminer to claim all available miners connected to my WiFi router and use the hotplug function. But I want cgminer to connect to a specific USB device so that I can have better control over it. When I did that at the time the other miner was running with BFGMiner on /dev/ttyUSB0, cgminer just took it. Stopping cgminer and restarting BFGMiner does not help BFGMiner to connect to /dev/ttyUSB0 any more. BFGMiner can only recognise Antminer U3 that is connected to /dev/ttyUSB0 after I power cycled it.
The problem with the U3 is what works for some does not work for others. Heck, even for me what works on one U3 does not work the same if I use another U3 in its place.
Agreed, it blows my mind that I literally mined for around 3 months with no issue at all with a single device and once I added multiple devices to the same PC, they all went Zombie in a few hours.
"zombie" is exactly what it shows in cgminer when the unit no longer hashes...
Also the method I have stated is working flawless for me, i am not resetting the port...
I am disabling the port altogether, killing the actual cgminer.exe, re-enabling the port...
The other script loops and catches that cgminer has been terminated and then restarts it...once port is re-enabled it picks up the miner and starts hashing immediately...
Believe what you wish, and to each their own, but I am saying my U3 now runs 24/7 without any interaction what so ever on my part.
Also the method I have stated is working flawless for me, i am not resetting the port...
I am disabling the port altogether, killing the actual cgminer.exe, re-enabling the port...
The other script loops and catches that cgminer has been terminated and then restarts it...once port is re-enabled it picks up the miner and starts hashing immediately...
Believe what you wish, and to each their own, but I am saying my U3 now runs 24/7 without any interaction what so ever on my part.
Good for you. Perhaps our setup is different as I use BFGMiner on my OpenWRT WiFi router. But if you scrolled through this thread, there are a lot of other people who are using cgminer on Windows and they have been trying a lot of things to solve this zombie issue but they failed (or maybe the one who successfully solved it just keep quite). Maybe your method could help them.
If anybody could confirm this, that would be great. I will try again to compile cgminer for OpenWRT 14.07, especially the bitmaintech's cgminer fork.
The problem with the U3 is what works for some does not work for others. Heck, even for me what works on one U3 does not work the same if I use another U3 in its place.
I forgot to mention one thing.
This is the part that makes me doubt it works because in my case (and some other people), even physically unplug and replug the USB cable does not bring up Antminer U3 unless we also unplug and replug the power. So how would software be able to do that?
I am disabling the port altogether, killing the actual cgminer.exe, re-enabling the port...
This is the part that makes me doubt it works because in my case (and some other people), even physically unplug and replug the USB cable does not bring up Antminer U3 unless we also unplug and replug the power. So how would software be able to do that?
I have only ever had to unplug/replug the usb, was running 8 U3's all at once on one machine...a few would be zombied...I could tell which were zombied by actually feeling the power supplies...whichever ones were cool I simply unplugged/replugged in the USB and cgminer would pick it back up and start hashing
I forgot to mention one thing.
This is the part that makes me doubt it works because in my case (and some other people), even physically unplug and replug the USB cable does not bring up Antminer U3 unless we also unplug and replug the power. So how would software be able to do that?
I am disabling the port altogether, killing the actual cgminer.exe, re-enabling the port...
This is the part that makes me doubt it works because in my case (and some other people), even physically unplug and replug the USB cable does not bring up Antminer U3 unless we also unplug and replug the power. So how would software be able to do that?
I doubt that the "zombie" (not sure where this term came from) issue can be solved programatically. I have tried similar method in the last 3 weeks by stopping BFGMiner, reset usb port, wait 10 minutes and restart BFGMiner via cron job every 7 hours and 50 minutes, but it did not help if Antminer U3 is stuck. The only solution is to power cycle it. I have 2 Antminer U3' and both behave exactly the same. So unless you also programatically do the power cycle using Arduino relay for instance, I don't think your method works.
Were you running 1 or multiple U3's? I can tell you that I had one unit running for months on CGMiner 4.8.0 that was packaged by Bitmain (cgminer-run-windows-20150107), my ZOMBIE issue started when I introduced more U3's on a computer. Any PC that I run with a solo U3 has no issues.
Currently I have one running, I would come in the next day and it would be zombied. The same concept should apply for multiple U3's, instead of disabling the one port I would disable the entire powered hub, then re-enable. I will test my findings and report back...my whole reason for selling the U3's was because they would zombie so I decided to look into a solution other than unplug/replug the usb. My method sounds a bit strange but I am saying it is working for me flawlessly.
"zombie" is exactly what it shows in cgminer when the unit no longer hashes...
Also the method I have stated is working flawless for me, i am not resetting the port...
I am disabling the port altogether, killing the actual cgminer.exe, re-enabling the port...
The other script loops and catches that cgminer has been terminated and then restarts it...once port is re-enabled it picks up the miner and starts hashing immediately...
Believe what you wish, and to each their own, but I am saying my U3 now runs 24/7 without any interaction what so ever on my part.
Also the method I have stated is working flawless for me, i am not resetting the port...
I am disabling the port altogether, killing the actual cgminer.exe, re-enabling the port...
The other script loops and catches that cgminer has been terminated and then restarts it...once port is re-enabled it picks up the miner and starts hashing immediately...
Believe what you wish, and to each their own, but I am saying my U3 now runs 24/7 without any interaction what so ever on my part.
Good for you. Perhaps our setup is different as I use BFGMiner on my OpenWRT WiFi router. But if you scrolled through this thread, there are a lot of other people who are using cgminer on Windows and they have been trying a lot of things to solve this zombie issue but they failed (or maybe the one who successfully solved it just keep quite). Maybe your method could help them.
If anybody could confirm this, that would be great. I will try again to compile cgminer for OpenWRT 14.07, especially the bitmaintech's cgminer fork.
I doubt that the "zombie" (not sure where this term came from) issue can be solved programatically. I have tried similar method in the last 3 weeks by stopping BFGMiner, reset usb port, wait 10 minutes and restart BFGMiner via cron job every 7 hours and 50 minutes, but it did not help if Antminer U3 is stuck. The only solution is to power cycle it. I have 2 Antminer U3' and both behave exactly the same. So unless you also programatically do the power cycle using Arduino relay for instance, I don't think your method works.
Were you running 1 or multiple U3's? I can tell you that I had one unit running for months on CGMiner 4.8.0 that was packaged by Bitmain (cgminer-run-windows-20150107), my ZOMBIE issue started when I introduced more U3's on a computer. Any PC that I run with a solo U3 has no issues.
"zombie" is exactly what it shows in cgminer when the unit no longer hashes...
Also the method I have stated is working flawless for me, i am not resetting the port...
I am disabling the port altogether, killing the actual cgminer.exe, re-enabling the port...
The other script loops and catches that cgminer has been terminated and then restarts it...once port is re-enabled it picks up the miner and starts hashing immediately...
Believe what you wish, and to each their own, but I am saying my U3 now runs 24/7 without any interaction what so ever on my part.
Also the method I have stated is working flawless for me, i am not resetting the port...
I am disabling the port altogether, killing the actual cgminer.exe, re-enabling the port...
The other script loops and catches that cgminer has been terminated and then restarts it...once port is re-enabled it picks up the miner and starts hashing immediately...
Believe what you wish, and to each their own, but I am saying my U3 now runs 24/7 without any interaction what so ever on my part.
I resold all of my U3's except one because they kept going zombie regardless of what I tried...
I kept one at work to play around with...
I have noticed when it zombies, I can unplug the usb out and back in and it restarts...
Being a coder/engineer...here is a solution that I came up with that works for me...I will be a bit brief but if anyone would like more details let me know...
I downloaded devcon utility from microsoft...
Then basically made a batch file that does the following: kills cgminer, disables the miner usb port, waits 15 seconds, renables the miner usb...
I have a second batch file that has my standard command to run cgminer but it has a loop...so when cgminer dies it will restart...this allows it to re-add the miner and start hashing again...
Basically I setup a few scheduled tasks that run to call my bat file a few times a day...was sick of coming in the next day only to discover my U3 had zombied...
All in all I like that the U3 is small and can be powerful...but over all I consider it an epic fail on account of the zombie issues...
Anyhow this method has worked flawless for me, so thought I would share...
I kept one at work to play around with...
I have noticed when it zombies, I can unplug the usb out and back in and it restarts...
Being a coder/engineer...here is a solution that I came up with that works for me...I will be a bit brief but if anyone would like more details let me know...
I downloaded devcon utility from microsoft...
Then basically made a batch file that does the following: kills cgminer, disables the miner usb port, waits 15 seconds, renables the miner usb...
I have a second batch file that has my standard command to run cgminer but it has a loop...so when cgminer dies it will restart...this allows it to re-add the miner and start hashing again...
Basically I setup a few scheduled tasks that run to call my bat file a few times a day...was sick of coming in the next day only to discover my U3 had zombied...
All in all I like that the U3 is small and can be powerful...but over all I consider it an epic fail on account of the zombie issues...
Anyhow this method has worked flawless for me, so thought I would share...
I doubt that the "zombie" (not sure where this term came from) issue can be solved programatically. I have tried similar method in the last 3 weeks by stopping BFGMiner, reset usb port, wait 10 minutes and restart BFGMiner via cron job every 7 hours and 50 minutes, but it did not help if Antminer U3 is stuck. The only solution is to power cycle it. I have 2 Antminer U3' and both behave exactly the same. So unless you also programatically do the power cycle using Arduino relay for instance, I don't think your method works.
I resold all of my U3's except one because they kept going zombie regardless of what I tried...
I kept one at work to play around with...
I have noticed when it zombies, I can unplug the usb out and back in and it restarts...
Being a coder/engineer...here is a solution that I came up with that works for me...I will be a bit brief but if anyone would like more details let me know...
I downloaded devcon utility from microsoft...
Then basically made a batch file that does the following: kills cgminer, disables the miner usb port, waits 15 seconds, renables the miner usb...
I have a second batch file that has my standard command to run cgminer but it has a loop...so when cgminer dies it will restart...this allows it to re-add the miner and start hashing again...
Basically I setup a few scheduled tasks that run to call my bat file a few times a day...was sick of coming in the next day only to discover my U3 had zombied...
All in all I like that the U3 is small and can be powerful...but over all I consider it an epic fail on account of the zombie issues...
Anyhow this method has worked flawless for me, so thought I would share...
I kept one at work to play around with...
I have noticed when it zombies, I can unplug the usb out and back in and it restarts...
Being a coder/engineer...here is a solution that I came up with that works for me...I will be a bit brief but if anyone would like more details let me know...
I downloaded devcon utility from microsoft...
Then basically made a batch file that does the following: kills cgminer, disables the miner usb port, waits 15 seconds, renables the miner usb...
I have a second batch file that has my standard command to run cgminer but it has a loop...so when cgminer dies it will restart...this allows it to re-add the miner and start hashing again...
Basically I setup a few scheduled tasks that run to call my bat file a few times a day...was sick of coming in the next day only to discover my U3 had zombied...
All in all I like that the U3 is small and can be powerful...but over all I consider it an epic fail on account of the zombie issues...
Anyhow this method has worked flawless for me, so thought I would share...
I put the three U3's that I own on 3 different Windows 7 Pro PC's running CGMiner 4.9.2. I had 2 running volt 830 freq 225 and 1 running volt 830 freq 250 and all ran for over 36 hours without rotating to a different USB port, i.e.; 0, 1, 2, 3... I noticed that the 2 running at 225 had very little hardware errors at 14 for the day and a half, where the unit running at 250 had over 1500 hardware errors. I then moved 2 units to one machine running freq 225 about 36 hours ago and the miners keep slipping through the USB ports. They started as 0 and 1 and now 36 hours later I'm at 3 and 4, keep in mind that they all stayed on 0 when they ran for 36 hours on separate computers and the one that was still running separately had to be restarted due to Microsoft Security Essentials detecting a file packaged within CGMiner as a Trojan 15 hours ago, but prior to that it was still at port 0 for 55 hours and is still at 0 for the last 15 hours and 31 minutes.
I don't understand why the U3's slip ports once you are running more than 1 device?
You seem to be lucky to be able to have all 3 Antminer U3' running for over 36 hours with voltage > 0.8 V and frequency > 200 MHz. I have 2 of them running with voltage = 0.75 V and frequency = 175 MHz at around 46 GH/s each, and the best they could achieve is only 38 hours before they stop hashing and need to be power cycled. They can only run for up to 16 hours with voltage > 0.8 V and frequency > 200 MHz. How are the humidity and room temperature where your miners are located? Did you add additional cooling system or fans?I don't understand why the U3's slip ports once you are running more than 1 device?
In regards to your USB port issue, I initially had similar issue. I have both of my miners connected to my WiFi router running OpenWRT and I use BFGMiner 5.2.0. I initially just plugged both miners directly to the WiFi router. The USB ports were not stable as the router, i.e. root hub, keeps randomly disabling and re-enabling the USB ports due to (EMI?). I tried to add 1 more ferrite bead at the other end of USB cables, but that didn't help. Then I tried to insert Belkin F5U231 MTT USB 2.0 Hub with CY7C65640-LFC controller. It helped stabilising the USB ports, but the hub was so hot after running for just a few minutes. I then changed it with a cheap STT USB hub with FE1.1s controller, and it also helps stabilising the USB ports but the effective hash rate is slightly lower than with the MTT USB hub. So perhaps you could try inserting USB hub and make sure that it is the only USB device connected to your PC.
This is in my office and the room is steady at approximately 73F or 22.28C; I haven't changed or added any other cooling. When I had the units split between 3 different PCs, one of the computers ran both the U3 using CGMiner 4.9.2 and also has a Zeus Miner Hurricane X3 running CGMiner 3.1.1 and neither USB rolled through ports. I only have the rolling issue once I add an additional U3 to any PC. I will try using a USB hub, I have a 7 port Anker that I'm not using at the moment.
Right now I'm at 1D 17H 39M with the PC that has 2 U3's attached and they are still on ports 3 and 4; the PC that was restarted yesterday is at 17H 24M and still on port 0.
Jump to: