if someone interested, here is the firmware for tp-link mr3020 with u3 support, no web ui, no router functionality, just system and cgminer 4.9.2
I am wondering why would someone wants to have a firmware on his/her router without router functionality. I have my TL-WDR3600 running fine as a router with a lot of functionalities including openvpn and also running either cgminer or bfgminer controlling 2 of myAntminer U3s. I initially used bfgminer 5.2.0 then switched to cgminer 4.9.2, but the Antminer U3s became more unstable and I cannot control the USB interface usage. So I switched back to bfgminer 5.3.0. |
|
|
|
I have just reported an issue on BFGMiner 5.3.0 on https://github.com/luke-jr/bfgminer/issues/633. However, I would like to check whether my understanding is correct or not. From what I understood, if a new block is being detected by the pool, the miner software should trash the current works and results. It then should request new works from the pool for building the next new block and distribute them to the miners under its control. It should not submit any previous results to the pool because it might not be valid any more as a miner some where on the earth had already solved it. So I am confused when I see the following messages on my BFGMiner 5.3.0. [2015-09-13 16:02:47] Stratum from pool 0 detected new block
[2015-09-13 16:02:47] Pool 0 is hiding block contents from us
[2015-09-13 16:02:47] Rejected 000d52d1 CBM 0d pool 0 Diff 4.92k/256 (unknown-work)
Could any one confirm whether my understanding is correct or not? If that would be wrong, could you please enlighten me on that? Thanks in advance. |
|
|
|
You're right I am not familiar with cross-compiling process and for using dpkg-buildpackage and the all dependencies require is still unclear even read that!
The method using dpkg-buildpackage is the prefer method to build the package (duh!) in Debian and its derivatives. If you are not familiar with that as well and you still want to try it, you can natively compile BFGminer source from github on Raspberry Pi using the provided build scripts. Someone has actually already done that for gridseed device and explained what he/she had done on this topic. Good luck! |
|
|
|
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. |
|
|
|
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. 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. 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 |
|
|
|
It is just running for about 30 minutes. I feel like version 5.3.0 is not as responsive as version 5.2.0 from the way it updates the hash rates. The name of the devices of my Antminer U3 have now changed to CBM where previously they were shown as AMU on version 5.2.0.
Eek, that's a bug.  Not a major bug, though. I'll fix it whenever the next version happens to be. Ah..ha?!?!? Which one? The name changed to CBM? I have decided to always use the HEAD of your github repository so that I don't need to always update the Makefile of BFGMiner package on my OpenWRT build directory. So you can actually commit the fix any time without waiting for the next major version. |
|
|
|
I forgot to give an update. I have just compiled BFGMiner 5.3.0 for OpenWRT 14.07 and it looks there is no issue. I used the source from github repository up to commit 484db74. Perhaps because of that the version on the UI is shown as 5.3.0-unknown.  It is just running for about 30 minutes. I feel like version 5.3.0 is not as responsive as version 5.2.0 from the way it updates the hash rates. The name of the devices of my Antminer U3 have now changed to CBM where previously they were shown as AMU on version 5.2.0. |
|
|
|
Hi Luke, I am interested in mining on raspberry PI 2 with latest version of bfgminer. I read readme and I unsure to the dependencies that I need to built miner as shown on bellow to enable scrypt and gridseed asic 80 chip! I left some other commands out in below code to build miner as I am not sure what need entered after dependencies installed. git clone https://github.com/luke-jr/bfgminer.git
cd bfgminer
... Can you help by providing complete codes? I assume everything is completed, bfgminer will disable CPU and radeon GPU? Well, I know enough how log in PI 2 at least! I assume that you are not familiar with cross-compiling process. So I would suggest to natively compile BFGMiner on Raspberry PI itself, but you must be patient as it will take a long time. I am not sure how long as I have never compiled BFGMiner on Raspberry Pi. If you would like to try that, you practically can just use dpkg-buildpackage to do that as if you would do that on Debian based PC, because the debian build files for BFGMiner are already being provided on the github repository, i.e. everything under debian directory. |
|
|
|
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>. .
.
[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. |
|
|
|
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? |
|
|
|
"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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
As far as I understood, the effective hash rate has little to do with the miners, perhaps it is only related to the hardware error. I think it has more to do with BFGMiner and the pool that it is connected to. Is that correct? If so, how could we control it so that we can speed it up or slow it down? What are the parameters affecting it? In relation to my questions above, I get more confused with the all-time effective average hash rate figure. It does not seem to be related to the all-time average hash rate figure as it remains at around 50 GH/s no matter what the all-time average hash rate is on. With the above settings (voltage=x750, clock=x0782), I got the figures as shown on screenshot below. I expect that the all-time effective average hash rate would be a certain percentage below the all-time average hash rate. It does not look that way. Is this all-time effective average hash rate reliable? Hi Luke, Perhaps you can just ignore my previous questions. But I would really appreciate if you could have a look on the Feature request - Provide warning indicator when the miner is dying on your github repository that I just raised, and think about it when you have spare time. Cheers, Anto |
|
|
|
Hi Luke, Both of my Antminer U3' crashed again today after running with 60 GH/s all-time average hash rate, non-continuously (stop for 10 minutes every 11 hours and 50 minutes with cron job). I just started to under-clock them to 200 MHz (x0782) at 0.75 V (x750) and managed them with a single BFGMiner process. I plan to run them continuously and I will keep reducing the hash rate until I get them running stable, or just trash them if the stable hash rate will be below 80 GH/s. As far as I understood, the effective hash rate has little to do with the miners, perhaps it is only related to the hardware error. I think it has more to do with BFGMiner and the pool that it is connected to. Is that correct? If so, how could we control it so that we can speed it up or slow it down? What are the parameters affecting it? In relation to my questions above, I get more confused with the all-time effective average hash rate figure. It does not seem to be related to the all-time average hash rate figure as it remains at around 50 GH/s no matter what the all-time average hash rate is on. With the above settings (voltage=x750, clock=x0782), I got the figures as shown on screenshot below. I expect that the all-time effective average hash rate would be a certain percentage below the all-time average hash rate. It does not look that way. Is this all-time effective average hash rate reliable? As I mentioned above, as soon as both miners crash again I will lower down the all-time average hash rate. Let's see how the all-time effective average hash rate figure will look like. Cheers, Anto  |
|
|
|
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.
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. |
|
|
|
Hi Luke, First of all, thanks a lot for the great miner software that you have shared with us. I have been using BFGMiner 5.2.0 in the last 3 weeks to manage my 2 Antminer U3'. I only found one annoying issue so far (if that would be indeed an issue) that I have already reported on your github repository. So there is no critical issue on your software that I experience so far. I am just a hobbyist with a little budget so I would like to get the best performance out of my 2 Antminer U3'. After all attempts so far, I have finally managed to control their all-time average hash rate. However, I cannot figure out how to manage their effective hash rate. I hope you could explain in more detail about this. As far as I understood, the effective hash rate has little to do with the miners, perhaps it is only related to the hardware error. I think it has more to do with BFGMiner and the pool that it is connected to. Is that correct? If so, how could we control it so that we can speed it up or slow it down? What are the parameters affecting it? For your reference, below are what I have observed and what I would expect to happen related to those questions. Thanks a lot in advance. Cheers, Anto Set all-time average hash rate to 55 GH/s on each miner, I got 50 GH/s effective hash rate.  Increased all-time average hash rate to 60 GH/s on each miner 2 days ago, I still get 50 GH/s effective hash rate. I would expect to get higher effective hash rate with 5 GH/s more, very low hardware error and 0 rejected+stale shares.   The graph on Eligius pool site confirms that there is no increase on the hash rate.  |
|
|
|
I am using BFGMiner 5.2.0
What is your command line to use the U3 w/5.2.0? Do you use the timing function, or ignore it? Thanks. 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. bfgminer --scan antminer:/dev/ttyUSB0 --set antminer:voltage=x775 --set antminer:clock=x0882 --set antminer:timing=0.0162 -o <mypool> -u <myusername> -p <mypassword> 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 |
|
|
|
How about disabling/enabling USB port?
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 |
|
|
|
|
Show Posts
