Look up GNU Screen - it's already installed on the S5. |
|
|
|
hey anyone got complied version of BFG for the S5 i can give a try , i can't figure out how to compile one.
http://luke.dashjr.org/tmp/code/bfgminer-ants5-299e2f7.tbz2tar -xjvpf bfgminer-ants5-299e2f7.tbz2
cd bfgminer-ants5-299e2f7
/etc/init.d/cgminer.sh stop
LD_LIBRARY_PATH=$PWD ./bfgminer --queue 8192 -S bitmain:auto --set btm:layout=32:8 --set btm:timeout=3 --set btm:clock=350 --set btm:reg_data=0d82 --set btm:voltage=x0725 -c /config/cgminer.conf
|
|
|
|
Kindly Help me, Antminer u1 seen on cgminer, but not seen on BFGminer.. what can I do?  If it's seen on cgminer, then you Zadig'd it. Need to find some way to undo that and get back to the official driver. |
|
|
|
|
Just a quick update: there is now an "ants5" branch on GitHub that is working on the S5.
This is based on the Bitmain code, and I still plan to do a lot of cleanup and refactoring before a release, but it does work at least.
To use it, you will need to compile it for the S5 and run something like this:
bfgminer --queue 8192 --api-listen -S bitmain:auto --set btm:layout=32:8 --set btm:timeout=3 --set btm:clock=350 --set btm:reg_data=0d82 --set btm:voltage=x0725
No promises these will be the final parameters yet.
(Anyone happen to know what reg_data is/refers to? Or how voltage is encoded?)
|
|
|
|
never tried Luke-Jrs BFGMiner, cks cgminer seems way more easy with cgminer/zadig How is it easier to do more things to set it up? O.o BFGMiner is plug-and-play... :p bfgminer needs a command line to just fire up, no? I do read READMEs. cgminer does not. BFGMiner needs a command line in the same circumstances that cgminer needs a command line. Normally, one can simply run BFGMiner and plug in miners, and it will just work. No need to mess with drivers (like cgminer's Zadig) or anything. this is from the READMEASIC in your miner for compac [b]These USB sticks are based on Bitmain's BM1384 chip, and use the antminer
driver.[/b] You can set the clock frequency with
--set compac:clock=x0782
[b]The same values for Antminer U3 (above) are valid for the BM1384.[/b]
this is from your README for U3 [b]The U3 does not support autodetection, so you will want to use --scan-serial to
manually probe it. For example, to scan all devices, you can use:
-S antminer:all [/b] am I understanding it wrong. I do not mind being wrong as I learn from it, well usually You're confusing the clock values with detection options. Is there some way to make this clearer to avoid such confusion? |
|
|
|
never tried Luke-Jrs BFGMiner, cks cgminer seems way more easy with cgminer/zadig How is it easier to do more things to set it up? O.o BFGMiner is plug-and-play... :p bfgminer needs a command line to just fire up, no? I do read READMEs. cgminer does not. BFGMiner needs a command line in the same circumstances that cgminer needs a command line. Normally, one can simply run BFGMiner and plug in miners, and it will just work. No need to mess with drivers (like cgminer's Zadig) or anything. |
|
|
|
never tried Luke-Jrs BFGMiner, cks cgminer seems way more easy with cgminer/zadig How is it easier to do more things to set it up? O.o BFGMiner is plug-and-play... :p |
|
|
|
I have a little info for Luke-Jr: My use of -d? -D produced about 20K bytes of output that I haven't tried to post here. I'll find a way to provide the whole file. I am however providing the last few lines which may provide a clue:
[2015-09-17 18:30:05] lowlevel_scan: Found vcom device at com:12 (path=\\.\COM12, vid=0000, pid=0000, manuf=(null), prod=(null), serial=(null))
[2015-09-17 18:30:05] lowlevel_scan: Found vcom device at com:11 (path=\\.\COM11, vid=0000, pid=0000, manuf=(null), prod=(null), serial=(null))
[2015-09-17 18:30:05] lowlevel_scan: Found vcom device at com:10 (path=\\.\COM10, vid=0000, pid=0000, manuf=(null), prod=(null), serial=(null))
[2015-09-17 18:30:05] Devices detected:
What's noteworthy about these is that COM10-COM12 are the device names that Windows assigned to the sticks. I can see them in a Control Panel display, and they are found as "AMU" if I add them using the \\.\COMxx path name after bfgminer is started.
One thing I just thought of: This system is actually my work laptop, and it's Windows 7 Enterprise. I am however NOT the Administrator of this box. I wonder if perhaps device detection is impacted by that?
Thanks for your interest.
Hmm, seems like getting the device info failed. A full log would be possibly helpful to figure out why. If hotplugging just works, this suggests it should be possible to get it... |
|
|
|
What BIP is Eligius going to vote for? You ruled out 101 so only 101 is left or do you wait for an updated/new BIP?
Miners have no say on hardforks, and it's not a vote. Your question is a false dichotomy. Not quite true though. Pools can basically vote based on which software they run now that xt exists. And miners can vote based on what pool they mine on. No, pools/miners that use software producing or accepting invalid blocks simply cease to be Bitcoin miners. if you look at it in the light that miners drive the network forward, and if the miners decide that "x" hardfork simply isn't going to happen, then they do indeed have a say in it. Depends on the hardfork... Post-hardfork miners can indeed softfork-veto any rule removal by re-adding the rule, but some hardforks (particularly ones that add/remove PoW or equivalent algorithms) potentially redefine the set of miners. |
|
|
|
What BIP is Eligius going to vote for? You ruled out 101 so only 101 is left or do you wait for an updated/new BIP?
Miners have no say on hardforks, and it's not a vote. Your question is a false dichotomy. Not quite true though. Pools can basically vote based on which software they run now that xt exists. And miners can vote based on what pool they mine on. No, pools/miners that use software producing or accepting invalid blocks simply cease to be Bitcoin miners. It is literally no different than if they start mining Freicoin instead. if you look at it in the light that miners drive the network forward, and if the miners decide that "x" hardfork simply isn't going to happen, then they do indeed have a say in it. Depends on the hardfork... Post-hardfork miners can indeed softfork-veto any rule removal by re-adding the rule, but some hardforks (particularly ones that add/remove PoW or equivalent algorithms) potentially redefine the set of miners. But that isn't relevant to the point: there is nothing positive miners can do to support a hardfork. |
|
|
|
What BIP is Eligius going to vote for? You ruled out 101 so only 101 is left or do you wait for an updated/new BIP?
Miners have no say on hardforks, and it's not a vote. Your question is a false dichotomy. Not quite true though. Pools can basically vote based on which software they run now that xt exists. And miners can vote based on what pool they mine on. No, pools/miners that use software producing or accepting invalid blocks simply cease to be Bitcoin miners. It is literally no different than if they start mining Freicoin instead. if you look at it in the light that miners drive the network forward, and if the miners decide that "x" hardfork simply isn't going to happen, then they do indeed have a say in it. Depends on the hardfork... Post-hardfork miners can indeed softfork-veto any rule removal by re-adding the rule, but some hardforks (particularly ones that add/remove PoW or equivalent algorithms) potentially redefine the set of miners. |
|
|
|
I have been tinkering with my 3 sticks, and been using bfgminer on a couple of different Windows 7 boxes. I observed a kind of odd behavior that I thought folks might find useful/interesting..
I had assumed it would always be best to have the sticks plugged in prior to starting bfgminer. I have yet to have example where bfgminer discovers anything on it's initial pass at start up. I then have gone through the process of "adding" them after bfgminer was started. I hade to use the \\.\COMxx reference. They would usually add just fine, and they showed up as an AMU.
Without actually realizing what I was trying, I plugged in a 2nd stick while bfgminer was running. I noticed in a couple of seconds, the LED started to flash. I then looked back at the screen, and bfgminer had automagically added a new miner to it's list and started using it. In this case though, it was a "CBM" miner and not an AMU. I then hot-plugged the 3rd miner and it to was detected and added as a CBM.
I then shut it all down, and unplugged the sticks after letting them cool (no fan). I started bfgminer with no sticks and over the course of 10-15 seconds hot-plugged all 3 sticks and I now have 3 CBM miners running at about 10-11GH each.
It appears to me that hot-plugging is actually "better", which I found surprising.
Can you post the output from: bfgminer -d? -D |
|
|
|
What BIP is Eligius going to vote for? You ruled out 101 so only 101 is left or do you wait for an updated/new BIP?
Miners have no say on hardforks, and it's not a vote. Your question is a false dichotomy. |
|
|
|
The sample sticks won't actually work with BFG or cgminer-gekko. The new softwares use our modified manufacturer and device strings in the CP2102 (that's the hex files Luke-Jr provided) to ID the sticks uniquely from other devices. Should work fine, just won't autodetect. So you'll need -S compac:\\.\COM1 (or whatever; compac:all is fine too). |
|
|
|
I received my 3 sticks today. WOOT!  Just want to confirm I'm running these properly. I compiled the latest version of bfgminer & starting with the following... bfgminer -S all --set-device antminer:clock=x0782 ... 2 of my sticks seem OK, but the 3rd shows up as having 2 chips & lots of HW errors...  Note at the very least, you will need to use --set-device compac:clock=x0782 |
|
|
|
Now that you got the BM1384 covered, any chance for other antminer support in openwrt? Unfortunately, it's not that simple. All the Antminer S* (only ones unsupported yet?) have a FPGA in between the chips and software. I'll see if I can throw together something working based on the cgminer driver in the meantime, until I get time to do a proper reverse-engineering job of the interfaces. |
|
|
|
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. |
|
|
|
NEW VERSION 5.3.0, SEPTEMBER 5 2015Human readable changelog:- compac: Support for the GekkoScience Compac BM1384 USB stick miner
Full changelog:- README.ASIC: Compac docs
- antminer: Explicit support for GekkoScience's Compac BM1384 Bitcoin Miner
- icarus: Use all null padding when probing work division (BM1384 reacts strangely - using part as start nonce?)
- antminer: Match Product strings including "Antminer"
- Bugfix: icarus: Never set timeout to 0, since it disables the timeout altogether
|
|
|
|
|
Show Posts
