Topic: ANTMINER U3 Discussion and Support Thread - page 30. (Read 149364 times)

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.

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?

What would you guys say is the optimum Difficulty for a U3.  I have a set of 3 mining on Slush's that i bought before my other big miners.  Just cant stomach to turn them off.   What do you think I should try to set the difficulty in order to maximize them. 

As I mentioned on my first ever post on this forum, I am using usbreset utility of OpenWRT on my WiFi router where the miners are plugged in. I thought that could help resetting the state of the USB interfaces. But there seems to be no problem on the USB interface at the miners' side as they are always alright since the reset commands always returns "Ok". I guess there must be something else inside the miner that is randomly stuck.

Yeah, I know, just mentioned it in the case you missed something

Oh well, then Arduino relay is the only way to go.

There is no such mechanism that can be done in software. I already said cgminer did everything it could do via software.

Well, this other guy said he was able to get his working again only by unplugging and replugging the USB cable, no power cycle whatsoever. So I was thinking, disabling and enabling USB can be done programatically, if it does the same thing.

Hi Mikestang,

As I wrote on the issue list page of BFGMiner that I previously pointed out, I am using the parameters voltage=x775, clock=x0882 and timing=0.0162. As far as I understood, all 3 parameters are critical to the performance of Antminer U3. I have played around with all of those 3 parameters, but I didn't have time to try all possible combinations. I usually use the config file as it is easier to maintain the settings. But if I would use a command line which includes those 3 parameters, I would do it as below assuming that the miner is connected to /dev/ttyUSB0.


My target is to have stable miners at around 55 GH/s average hash rate. From what I have observed, Antminer U3 is more stable with VDD below 0.8 V. But if we set it too low, e.g. below 0.75 V (minimum VDD of BM1382), it does not behave as expected. That is why I chose 0.775 V as 225 MHz clock (x0882) requires at least 0.75 V according to Antminer U3 user guide.

Now, the timing parameter is the most difficult one to define for me. Perhaps because there seems to be no documentation about it or I could not find any. There seems to be no relation between the timing parameters and the other two.

I did quite a lot of trial and errors to get the right figure (as I thought it so). Even on the same Antminer U3, after changing the timing parameter to some different values, I could not get relatively same hash rate when I set it back the the previous value. I sometime need to power cycle the miner. So the timing parameter seems to be varied amongst different Antminer U3. You possibly would not get the same hash rate as I did. Perhaps you could use my figure above as your reference. You will get lower hash rate if you increased that figure, and vise versa. As I mentioned before, if the hash rate didn't change after you change the timing, you might need to power cycle the miner. And you need to wait at least 10 minutes until the hash rates stabilised.

Cheers,

Anto

What is your command line to use the U3 w/5.2.0?  Do you use the timing function, or ignore it?  Thanks.

I am wondering of what would you expect to happen by doing that, as I doubt that will solve the issue.

In the last 2 weeks, I have trying myself to find the solution for the issue on my 2 Antminer U3 which are intermittently stuck after hashing for more than 12 hours at 55 GH/s all-time average. I can push the hash rate to above 60 GH/s, but they become more unstable. When they are stuck, as everybody else on this thread have mentioned, the only solution is to power cycle them. Perhaps I could build automatic power switch controlled by Arduino board, but I think that is too much of hassles. I also tried to clean and re-apply the best thermal compound that I could find, but that only helps stabilise a little bit.

Unlike everybody who experienced the same issue, I am using BFGMiner 5.2.0 on my WiFi router which is running OpenWrt 14.07 where I plugged both miners to. If you would like to read the story of my experience, you could have look on this issue page.

I am using the usbreset utility to try to flush anything on USB interface before restarting BFGMiner process. But when Antminer U3 refuses to work, BFGMiner cannot communicate with the ASIC chips even when the USB interface is up and running.


OOhh... by the way, this is my first post here in this forum, so hello everybody

Cheers,

Anto

How about disabling/enabling USB port?

Cgminer will succeed, too.  You'll notice this as the AU3 # changes.  It starts at AU3 0, then AU3 1, AU3 2, etc.  But eventually only a hard reset will cure the ZOMBIE.

Cgminer tries to reset it every way possible - watch for the reset messages which occasionally work. This cannot be fixed on the software end.

Hm..that's quite odd. What *may* be happening is that unplugging the USB creates a temporary voltage drop which resets the USB chip even though it is still powered from the other side. It takes time (a few milliseconds, but seemingly enough) for power supply to compensate for the power drop. When the red wire is cut, the chip is working, but unplugging the wire makes no effect on the current flow, and therefore there is no voltage spike.

Can the device be reset programatically from within cgminer?

I don't understand why I had one unit hashing for literally months and once I add 2 units they all zombie out within a few hours of each other. I have yet to have all three units last more than 30 hours without them going ZOMBIE. It seems like it's a driver issue.

It was the first time I actually seen them do it 1 right after the other. Most times (during the night or when I'm not home) it might be 2 - 3 hours (or days) in-between.

And yes, before I cut the wire, I just unplugged USB and they reset (don't know if I was just lucky or what). With the wire cut, it was the first time I had to unplug the power to get it back.

Another observation, if when checking on them, if you see any hashing around 25 - 30GH or lower, you might as well pull the USB and reset it. If not, it might take 10 minutes, 2 hours, or longer for it to zombie and it'll probably wait until your not around.

So before the device could be reset just by unplugging the USB while leaving the power supply on, and now that the wire is cut, it's reset by unplugging power? That's...odd.

Maybe some current is flowing through the black wire too? Though if you cut it, you might end up messing up the potential difference. Maybe it would work if you'd connect the black USB wire with the black PSU wire.

Also, I can't help but notice the devices zombied out almost simultaneously. Is that often the case?

By the way, they are pointed at solo.ckpool 

Ok, I wasn't sure of the options for the configure, so I copy/pasted them blindly.

Thank for the corrections, I will edit the previous message !

You're giving confused advice there. Neither the --enable-bmsc option nor the --enable-bitmain option is in the master cgminer you're cloning so it won't do anything. Only --enable-icarus does anything on master cgminer and is the only thing required for this device.