ANTMINER U3 Discussion and Support Thread

[bmoscato]

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?

[.anto.]

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?

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.

[bmoscato]

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?

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.

[mileywiley]

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...

[.anto.]

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 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.

[mileywiley]

"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.

[bmoscato]

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.

[.anto.]

"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.

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.

[mileywiley]

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.

[.anto.]

I forgot to mention one thing.

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?

[mileywiley]

I forgot to mention one thing.

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

[Mikestang]

"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.

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.

[bmoscato]

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.

[.anto.]

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 have finally managed to compile cgminer for OpenWRT 14.07. I decided to use the one from Con Kolivas's github repository up to commit 87d3ce9. It runs fine on my WiFi router. However, I am quite sure that your method does not work, at least for the setup that I want because the way cgminer manages USB devices.

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 <Bus ID>:<Device ID>. I found this a quite strange approach as we all know that the <Device ID> 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 <Device ID> of the Antminer U3' USB was initially 087 when cgminer was happily connected to it.



I expected this problem, that is why I wrote above this is a strange approach. The dmesg output confirms that the <Device ID> keeps changing when I unpluged/re-pluged the USB cable. So we basically have to restart cgminer with the new <Device ID>.

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.

[-ck]

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 <Bus ID>:<Device ID>. I found this a quite strange approach as we all know that the <Device ID> 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 <Device ID> 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.

[.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 <Bus ID>:<Device ID>. I found this a quite strange approach as we all know that the <Device ID> 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 <Device ID> 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 <Bus ID>:<Device ID> in specifying the USB device that we want to use as the <Device ID> always change on Linux. I am not sure if that happened as well on Windows or other OS'.

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

[hurricandave]

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.

[.anto.]

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.

[hurricandave]

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.

The only other thing I can think of trying is to try adding --usb :1 , then see if you  can open a second instance with the same --usb :1 and if your trying to automate this in a start up routine then make sure there is at least a 60 second delay between the two instances of cgminer  trying to launch.

[efodix]

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?