ANTMINER U3 Discussion and Support Thread

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

[bmoscato]

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

[mileywiley]

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

[Blackbird0]

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?

Yes. Mine zombies when running alone. It is a piece of crap piece of hardware. Period. Full stop.

There is no software solution to this "zombie" problem we have all encountered.

[bmoscato]

I have to agree, the U3 is a piece of crap... I'm sorry I bought them.

[efodix]

Has there been any talk of the successor, now that the new chips are coming in?

[Mikestang]

Yes, it's the gekkoscience compac, get them while they're hot: https://bitcointalk.org/index.php?topic=1126705.0

Best usb miner available right now, and you're supporting our "local" community.  Unlike the U3, these work!

[speedt_ouch]

Hi.
Its me again looking for help with my U3  

I have been getting a pretty decent average from my two U3 for some time.
Most of the time 115/120GHz that is pretty good I believe.

Since monday, average dropped to 100GHz most times even lower.

I changed USB cable also the same result and many reboots (computer and u3)
I wonder if maybe a chip is dead? could it be?

They are been cooled and I run default comand in Windows 7 has follows

Code:

cgminer.exe -o POOL -u USER -p pass

WU value is always lower than the other, before I thing they were pretty much the same.

Is there something I can do to get better results has before although nothing changed?

At the end of the day it makes quite a difference in my earnings with this lower average.

Thanks in advance.  

[Mikestang]

Most of the time 115/120GHz that is pretty good I believe.

Since monday, average dropped to 100GHz most times even lower.

GHz?  Do you mean GH/s?  The hash rate, not a measure of frequency.

There is no answer, U3s do what they do, be lucky you have two that work at the same time.

[bmoscato]

Since monday, average dropped to 100GHz most times even lower.

Thanks in advance.  

Have you tried resetting the U3's (unplug both power and USB) and then restarting CGMiner?

[speedt_ouch]

Since monday, average dropped to 100GHz most times even lower.

Thanks in advance. 

Have you tried resetting the U3's (unplug both power and USB) and then restarting CGMiner?

Yes I have rebooted all hardware.
Removed power and usb cables.
Tried with other cables. All the same.
Plugged USB cables in different USB ports.

No difference.

Most of the time 115/120GHz that is pretty good I believe.

Since monday, average dropped to 100GHz most times even lower.

GHz?  Do you mean GH/s?  The hash rate, not a measure of frequency.

There is no answer, U3s do what they do, be lucky you have two that work at the same time.

LOL yes I mean GH/s. Sorry.

I guess I mite be lucky then. It took a lot of trial and error and a decent hardware computer:
https://bitcointalk.org/index.php?topic=827356.msg11803834#msg11803834

[Mikestang]

Try running each U3 by itself and see if its hashrate is different than when they are plugged in together.

[bmoscato]

I have 3 of the U3's and they all run at different speeds.

I've tried:

225MHz 775mV
225MHz 800mV
225MHz 830mV
250MHz 800mV
250Mhz 830mV

on 3 separate PC's and they all clock different speeds against the same pool and same settings.

[speedt_ouch]

I have 3 of the U3's and they all run at different speeds.

I've tried:

225MHz 775mV
225MHz 800mV
225MHz 830mV
250MHz 800mV
250Mhz 830mV

on 3 separate PC's and they all clock different speeds against the same pool and same settings.

Those values are equal for both and they seem to be fixed values
The WU value is always changing, but after a while running there is always one that remains quite lower than the other resulting in a lower hashrate.

I will also test them seperatly has suggested by Mikestang