|
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. |
|
|
|
|
It's curtains for scrypt mining.
|
|
|
|
That can't happen.
Oki You are the boss.. Thank you for your comments. Heh no problem  Appreciate extra eyes on the code, always. BTW if it wasn't obvious: The cg write lock variant would have grabbed the mutex successfully but be unable to grab the write lock while the other thread holds the read lock. |
|
|
|
Hello Con,
I have played with #define LOCK_TRACKING 1 - GREAT WORK THANK YOU!
Here are my findings:
First Issue
From the following code
[snip]
It seems that when a thread acquires a read lock (_cg_rlock) another thread can acquire a write lock (_cg_wlock)
Actually the unfortunate thing is that cglocks are unique upgradeable read write locks, and it is normal for a write lock to be able to grab the mutex component of the cglock while a read variant is holding the read lock - but it will not be able to grab the write lock. The same rules don't quite apply as per regular locks. Yes they are an implementation of my own, originally developed for the linux kernel scheduler code I maintain. See: http://ck-hack.blogspot.com/2012/06/upgradeable-rwlocks-and-bfs.htmlSo what will happen when if (strcmp(work->job_id, pool->swork.job_id)) and free(pool->swork.job_id); are executed simultaneously? That can't happen. |
|
|
|
If they would sell that Boden hashpower at a decent rate, or fulfill orders with it...it would create a huge diff increase offset, and be a huge benefit to Neptune holders and the community as a whole, because it's already a part of the cloud, and would cause zero diff increase, yet at the same time offer a great deal. They do have the ability to turn it into a HUGE customer advantage in this way. I hope they "Do the right thing"
That would be HUGE imho, and may even happen.
Your hope is misguided based on the fact you were one of the lucky early ones to get hardware that ended up being profitable. They are not here to help their customers or bitcoin at large. The same thing happened to the first Avalon buyers/miners. There is a small window for a handful of people to make money off the first scrypt miners that knc produces, but every other customer will make a loss from here on in. |
|
|
|
Hello Con,
I have played with #define LOCK_TRACKING 1 - GREAT WORK THANK YOU!
Here are my findings:
First Issue
From the following code
[snip]
It seems that when a thread acquires a read lock (_cg_rlock) another thread can acquire a write lock (_cg_wlock)
Actually the unfortunate thing is that cglocks are unique upgradeable read write locks, and it is normal for a write lock to be able to grab the mutex component of the cglock while a read variant is holding the read lock - but it will not be able to grab the write lock. The same rules don't quite apply as per regular locks. Yes they are an implementation of my own, originally developed for the linux kernel scheduler code I maintain. See: http://ck-hack.blogspot.com/2012/06/upgradeable-rwlocks-and-bfs.html |
|
|
|
And it is done. Thanks for support.
Well I guess the good guys do win every now and then. Congrats. Kinder words have not been said, thank you very much   |
|
|
|
|
New version: 4.2.1, 24th March 2014
Bugfixes.
Human readable changelog:
- Bitcoind did not like lots of persistent connections at once meaning it would fall over if more than one cgminer instance was trying to mine at the same time from the one bitcoind instance. Cgminer now opens and closes the connection every time it talks to bitcoind allowing any number of cgminer instances to mine solo from the one instance. Confirmed working with 200TH of miners aimed at the one bitcoind...
- Big endian hosts (like the antminer S1, avalon) did not work with solo mining.
- Solo mining setups will not mine unless a btc address is specified now, and the address is displayed on startup if it exists.
- Solo mining disconnections to bitcoind are handled better, not spawning more polling threads every failure.
- Low level optimisations for solo mining
- AntminerS1 fixes to decrease CPU usage and actually honour overheat conditions.
- Network diff when submitting a block is shown correctly on screen when >2billion.
- Build fixes for avalon2
- miner.php improvements
Full changelog:
- Fix various ava2 build issues generically
- Minimise the amount of heap memory allocations/frees when submitting gbt
shares.
- Make varint in gbt submission a stack object.
- Fix big endian problems with gbt submissions.
- Fix 32bit overflow on relative diff shown.
- ants1 - stop results read hard looping
- ants1 - slow down mining if overheat occurs
- miner.php allow gen before (bgen) and after (gen) grouping
- Change default solo mining to failing when no btc address is specified.
- Use upgrade cglock variants in get_gbt_curl
- Provide a cg_uilock to unlock the intermediate variant of cglocks.
- Use the one curl instance for all gbt solo operations, protecting its use with
a bool set under gbt lock.
- Only start block detection with gbt solo if setup succeeded
- One less block detection message
- Toss out the curl handle after each solo poll
- Don't reuse any curl handles for solo mining and break out of the lp thread if
the pool is removed.
- Make sure to only start the lognpoll thread once on gbt solo.
- Don't keep RPC connections open for solo mining since bitcoind doesn't like
having many persistent connections.
- GBT solo pools should be considered localgen pools.
- miner.php - speed up formatting and allow calc on gen fields
- Always show the address we're solo mining to to avoid confusion for when no
address is set.
|
|
|
|
Gpu's rigs are not for scrypt anymore but for n-factor and sha-3 coins
Where have I heard this before  |
|
|
|
Read the readme section on the --usb command. You can specify how many devices to mine with and which specific device types and usb slots if you like.
Eg:
--usb :1
will limit it to mining only on the very first usb device it finds that it supports.
If you're talking GPU mining then you're in the wrong place.
Nah, not gpu. Just got a bunch of ASICMINER block erupter usb's and a few of the antminer usbs. I don't want cgminer touching the antminers because it has no real support for them. I looked through docs, i'm just tired of reading them. Didn't see that in there, for some reason. thanks Eh? Cgminer works fine with antminer USBs unless you're using a much older version. 4.2.1 is the latest. |
|
|
|
|
They know the score, and that's why they offer no refunds for the scrypt miner. Titan will kill all scrypt mining since its only alleged advantage is that it is not mined by ASICs. Once ASICs are mining it in vast quantities, the only people who will have any interest in LTC and friends are those who already own a lot of it. If there is no real advantage or purpose to LTC and the profit margins for mining disappear and turn into absolute losses, those who preordered with a no-refund policy will get royally shafted.
|
|
|
|
He was rewarded 25 BTC = $14 000 USD Just a little bit of money Well he was mining with almost 200TH (aimed at just one bitcoind!) confirming nicely the scaleability of cgminer's solo mining. And here's another just for good measure: https://blockchain.info/tx/1f59b91615ea0f9e6c633f7c426daa367cde119b03a36ad235def2236b9c0f7dThere are a number of small improvements/fixes going into the solo mining code as a consequence of this testing which should be wrapped up into a minor bugfix release soon. There is one showstopper that makes solo mining not work properly on big endian machines (like antminers) which warrants this release. The other limitation is that bitcoind does not like a lot of persistent connections at the same time so I have reworked the code to drop connections as much as possible allowing multiple cgminer instances to connect to the one bitcoind. |
|
|
|
I think at least the u1's were 2 watts each and that the eroupters I replaced the u2's with are 2 watts so I think I should be fine. I have all set at 250. Here the devices. When I run it there should be 8 anu's and 3 amu's among other devices and an unsupported tecnobit device(*yes theres an unsupported patch but compiling has been a pain so far). [2014-03-23 07:46:18] USB all: found 26 devices - listing known devices
.USB dev 0: Bus 1 Device 10 ID: 03eb:2404
Manufacturer: 'Drillbit Systems'
Product: 'Thumb'
.USB dev 1: Bus 1 Device 18 ID: 03eb:2404
Manufacturer: 'Drillbit Systems'
Product: 'Eight'
.USB dev 2: Bus 1 Device 3 ID: 10c4:ea60
Manufacturer: 'Silicon Labs'
Product: 'CP2102 USB to UART Bridge Controller'
.USB dev 3: Bus 1 Device 4 ID: 10c4:ea60
Manufacturer: 'Silicon Labs'
Product: 'CP2102 USB to UART Bridge Controller'
.USB dev 4: Bus 1 Device 7 ID: 10c4:ea60
Manufacturer: 'Silicon Labs'
Product: 'CP2102 USB to UART Bridge Controller'
.USB dev 5: Bus 1 Device 8 ID: 10c4:ea60
Manufacturer: 'Silicon Labs'
Product: 'CP2102 USB to UART Bridge Controller'
.USB dev 6: Bus 1 Device 9 ID: 10c4:ea60
Manufacturer: 'Silicon Labs'
Product: 'CP2102 USB to UART Bridge Controller'
.USB dev 7: Bus 1 Device 14 ID: 10c4:ea60
Manufacturer: 'Silicon Labs'
Product: 'CP2102 USB to UART Bridge Controller'
.USB dev 8: Bus 1 Device 15 ID: 10c4:ea60
Manufacturer: 'Silicon Labs'
Product: 'CP2102 USB to UART Bridge Controller'
.USB dev 9: Bus 1 Device 16 ID: 10c4:ea60
Manufacturer: 'Silicon Labs'
Product: 'CP2102 USB to UART Bridge Controller'
.USB dev 10: Bus 1 Device 17 ID: 10c4:ea60
Manufacturer: 'Silicon Labs'
Product: 'CP2102 USB to UART Bridge Controller'
.USB dev 11: Bus 1 Device 19 ID: 10c4:ea60
Manufacturer: 'Silicon Labs'
Product: 'CP2102 USB to UART Bridge Controller'
.USB dev 12: Bus 1 Device 20 ID: 10c4:ea60
Manufacturer: 'Silicon Labs'
Product: 'CP2102 USB to UART Bridge Controller'
[2014-03-23 07:46:18] 13 known USB devices They're all seen there so it's not a usb recognising issue. Amuse me and run them at default clock without specifying 250 since you are then overclocking them compared to the default. |
|
|
|
|
If you're only going to make money cloud hashing by gambling on the value of BTC rising, then you are absolutely always guaranteed to make a bigger profit just converting your money into BTC and bypassing the whole hashing part. Cloud hashing is a genius business model that only ever benefits the cloud, not the miner.
|
|
|
|
|
And it is done. Thanks for support.
|
|
|
|
|
Show Posts
