Topic: ANTMINER U3 Discussion and Support Thread - page 29. (Read 149364 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?

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.

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

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

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.

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

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.

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

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.