Difficulty jump was just 18% to 5006860589, so the great flood of hyper-TH miners has not reached the shores yet...  Think exponential function. That amounts to adding about 7000TH. Are you sure you don't call this a lot? |
|
|
|
|
Antminer uses cgminer which includes the --rotate option to switch pools at regular intervals. Just set that pool strategy, specifying how long between each pool.
|
|
|
|
I think I have named them all individually but no matter what string I use for --hfa-options I can't get it to load. Can you write me an example?
Thanks
Shall I quote the docs again? --hfa-options <arg> Set hashfast options name:clock (comma separated)
This command allows you to set options for each discrete hashfast device by
its name (if the firmware has naming support, i.e. version 0.3+). Currently
this takes only one option, the clock speed, although future options may be
added.
e.g.:
--hfa-options "rabbit:650,turtle:550"
|
|
|
|
You seriously want to solo mine instead of pool mining? Do you have some amazing mining rig or what?
I for instance solo mine with a 300 MH USB Block Erupter, because "Pool Mining" is not profitable in my case  Solo mining with 300 mh/s? That doesn't really seem like much when you compare it to the +100 gh/s ASICs. It won't earn anything mining regular, so he uses it like a lottery. |
|
|
|
Hi Con,
Firstly thanks for all the updates aimed at Hashfast devices, 4.2 has helped a lot.
As all Sierra's are not born equal I need to run them at different clock speeds. I successfully used the '--hfa-name Slug --usb 4:42' to rename one device to later allow me to use '--hfa-options "rabbit:650,turtle:550"'
If I add more renaming to the string it simply doesn't find any device. Can you tell me what I have wrong with the below?
--hfa-name NS1 --usb 1:7 --hfa-name NS2 --usb 2:7 --hfa-name NS3 --usb 2:4
Thanks
--hfa-name <arg> Set a unique name for a single hashfast device specified with --usb or the first device found Name one at a time. You only need to name them once; the names should keep for ever more even with firmware updates. |
|
|
|
Wow, this link even got newer firmware then the official one. Thanks Yes I make it and maintain it to be in line with my cgminer releases. It's up to date with cgminer 4.2.1 |
|
|
|
|
There are a lot of cgminer fixes and stability improvements with the latest firmware. The hashrate demonstrated should match the pool now, and there are far more useful stats in the advanced->stats tab. I worked with them on coordinating the cgminer updates.
No, I doubt you'll ever see more than 1.6TH out of these devices, but I have nothing to do with that aspect.
|
|
|
|
For those of you on windows who have devices that don't show up on USB3 slots, you can try the following binary (it is otherwise identical to the 4.2.1 release): http://ck.kolivas.org/apps/cgminer/temp/cgminer.exeIf it turns out to fix the problems, I might just re-package 4.2.1 for windows. |
|
|
|
I have set up local mining with 6x Antminer U1 on bitcoin, hoping for the lottery ticket to come out.
Can I do something to lower the CPU usage ?
You can mine solo with cgminer on Antminer U1s directly to bitcoind which uses a lot less CPU without needing any pool software. |
|
|
|
After patching the cgminer 4.0.0 patch (HEX16 by Technobit) I tried to "make" my cgminer-4.0.0 with MinGW/MSYS-Shell for the HEX16B. But it failed! Would be awesome if anyone could help me! We do not support external patches on the cgminer code. Seek help from whoever provided those patches. Though it looks like you just need to do what it says: install a winusb driver. |
|
|
|
Hashfast per die clock rate setting: I have noticed that in driver-hashfast.c, there seems to be adaptive clock rate setting per die: applog(LOG_INFO, "%s %d: Die temp below range %.1f, increasing die %d clock to %d",
hashfast->drv->name, hashfast->device_id, info->die_data[die].temp, die, hdd->hash_clock);
hfa_send_frame(hashfast, HF_USB_CMD(OP_WORK_RESTART), hdata, (uint8_t *)&diebit, 4); Is there a way to set per die clock from command line or conf file? Reason I'm asking is one of my dies seems to work fine up to 150MHz then it completely stops working and I would like to clock dies 0-2 with normal clock and underclock die 3. Edit: By the looks of your comments and the code it seems that per die clock setting will be possible for FW 0.5 and up. Do you already got FW 0.5 from hashfast by any chance? Older firmware 0.3+ can do per die clockspeeds as well but when there is a large difference in the clocks it causes huge dips and peaks in the metering out of work which can present temperature and other issues. It is not possible to set clock speed per die on the command line yet but it is possible to add that feature. |
|
|
|
PS:
Guy's
What about
cg_wlock(&control_lock);
.....local_work++;
.....total_work++;
cg_wunlock(&control_lock);
I think there is a need to lock them everywhere or ?
Thanks
Mostly harmless, but probably wouldn't hurt to protect them with the write lock for when mining at multiple different types of pools at once (eg GBT + stratum), yes, thanks. |
|
|
|
|
It went for many minutes and the block height reported by getblockcount didn't go higher before I finally killed it. I'd say at the very least it should be advancing block height, but ideally, rejecting them.
|
|
|
|
Cloud mining is almost never profitable, regardless of the service you might select. If you compare the amount of BTC which you would spend to lease your miner and the amount of BTC which you would get from mining, you will ALWAYS lose money. Having this in mind, it is better buying BTC and holding or investing into something else.
What you say is true... for Single Coin Mining operations. That's why [CUT GREAT BIG AD] Same shit. |
|
|
|
|
There's something really satanic about this pool's hashrate being so close to ~6660Th.
|
|
|
|
|
Your subject of "Scrypt ASICS Hardware" is provocative. At least pretend it has something to do with bitcoin mining, even if you plan not to use it so; otherwise move your thread to altcoin mining.
|
|
|
|
|
Current cgminer solo mines extremely efficiently and goes to great lengths to make sure it's working on the current block.
|
|
|
|
I recently implemented GBT solo mining with cgminer and have confirmed its ability to generate blocks on both testnet and the main bitcoin network. However I encountered an issue when I was running it with a high hashrate on a local testnet with only 2 nodes where generation was very rapid. This was on bitcoind 0.8.6 Here is the debug log: 2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 AddToWallet 7e6b9062686f1899a1c7fac650a8f8814512ca3d46dd1ddc9e9a4754b234b0c9 new
2014-03-23 13:41:47 NotifyTransactionChanged 7e6b9062686f1899a1c7fac650a8f8814512ca3d46dd1ddc9e9a4754b234b0c9 status=0
2014-03-23 13:41:47 updateWallet 7e6b9062686f1899a1c7fac650a8f8814512ca3d46dd1ddc9e9a4754b234b0c9 0
2014-03-23 13:41:47 Committing 300 changed transactions to coin database...
2014-03-23 13:41:47 SetBestChain: new best=00000000c4bf4b3cc072bd1cb614869f38b0160d6dd06a91ded695b8c42d198e height=56195 log2_work=52.435666 tx=93784 date=2014-03-23 13:41:48 p
rogress=1.000000
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 inWallet=1 inModel=0 Index=95-95 showTransaction=1 derivedStatus=0
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=getblockcount
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 received getdata for: block 00000000c4bf4b3cc072bd1cb614869f38b0160d6dd06a91ded695b8c42d198e
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:48 ThreadRPCServer method=submitblock
2014-03-23 13:41:48 ProcessBlock: ACCEPTED
2014-03-23 13:41:48 ThreadRPCServer method=submitblock
2014-03-23 13:41:48 ProcessBlock: ACCEPTED
2014-03-23 13:41:48 ThreadRPCServer method=submitblock
2014-03-23 13:41:48 ProcessBlock: ACCEPTED
2014-03-23 13:41:48 ThreadRPCServer method=submitblock
2014-03-23 13:41:48 ProcessBlock: ACCEPTED
2014-03-23 13:41:48 ThreadRPCServer method=submitblock
2014-03-23 13:41:48 ProcessBlock: ACCEPTED
2014-03-23 13:41:48 ThreadRPCServer method=submitblock
2014-03-23 13:41:48 ProcessBlock: ACCEPTED
So the first block was accepted and appeared fine in the wallet but after that, bitcoind appeared to go stupid and accepted all the blocks submitted but never really seemed to do anything with them. Is this simply a symptom of running only 2 nodes or is there a potential real problem with generating multiple valid block solves and submitting them? Note they were all almost certainly solves for the same height block and not subsequent blocks. |
|
|
|
|
Show Posts
