|
I left a CPU miner running on my email & webserver VPS (back when Bitcoin was fairly new and worth nothing). I managed to solo-mine 50 BTC, but forgot about it for a while.
Back in 2013, when BTC was around $13 and I was a n00b in this forum, I used most of that 50 BTC to buy a used Radeon HD 6870 (to do some GPU mining) and a couple of Butterfly Labs coffee-warmer ASIC miners. I still have these, though they're all idle as none of them are economical to mine with nowadays. (The GPU, at least, was still powering my work desktop until it got upgraded a few months ago.)
If I'd held onto those 50 BTC, they'd now be worth the better part of $2 million.
Mining proceeds mostly went into a few silver purchases at first, then into buying more ASIC miners (fastest I ever bought were a couple of Antminer S1s). None of them are economical to mine with now, so they're as much paperweights as the BFL miners.
In 2017, I decided to have another go at GPU mining and built a rig with four GeForce GTX 1070s. In about a year, it mined enough to pay for itself. In the recent runup in value, two things have happened: (1) it's once again profitable to run the rig (fired it up again last night, and it's supposed to clear $300 or so per month even with power at 12˘/kWh) and (2) the proceeds from the last round of mining have appreciated enough that they'll go a long way toward paying off my mortgage. I've also bought and held some BTC, so I'll probably only put 50-60% of current holdings toward the mortgage and let the rest of it continue to appreciate.
|
|
|
|
where can i mining this coin
My pool is still up and running: https://bitgem.alfter.us/I've not been mining on it lately because my four-year-old Gridseed miners aren't worth running (I'm doing GPU mining these days with four 1070s), but I've seen others mining from time to time. Also, I've developed some maintenance fixes for the Bitgem codebase to deal with updated libraries (Boost 1.66 is causing breakage for lots of code right about now) and to build on BSD (I've been staking on my FreeNAS box). Get them here: https://gitlab.com/salfter/bitgem |
|
|
|
Has Zpool been paying out, as it has been 2 weeks for me now and zpool.ca is not paying out. I have tried to contact Zpool.ca Support and Zpool twitter, but no response so far.  I've been mining there for about a month now with four 1070s, and getting paid every 4-5 days. I've also made about twice as much in the past month as I had been seeing in previous months at MiningPoolHub. (Software-wise, I use my own auto-switchers running on Linux. I used nvOC for a good while, but more recently switched the mining rig over to Gentoo Linux so I can more easily keep it up to date. I maintain a bunch of mining- and other cryptocurrency-related ebuilds, and I have an RSS reader that tells me when an update is available.) |
|
|
|
Having run this for about a month now, I should've written this earlier.  I'm seeing nearly twice the productivity out of zpool as I was getting from MiningPoolHub (for which I've also written an auto-switcher). |
|
|
|
|
My rig switched over to timetravel sometime this morning, but while I had benchmarked my four 1070s at about 90 MH/s (using tp-ccminer) and was seeing ~87 MH/s when I checked just now, zpool is only showing 500 kH/s or less. The 24-hour balance graph has definitely leveled off over the past few hours, compared to its usual rate of growth. Is this an issue with the pool or with the mining software? (I've disabled timetravel in the meantime; the rig's gone back to mining tribus.)
|
|
|
|
I just got 500 confirmations on a block of 68 coins, but no stakes, it took like 6 days to get to 500 confirmations...when do you think I can expect some stakes?
Once coins are in your wallet, they're eligible for PoS after 30 days. |
|
|
|
|
Looks like after a few minutes, it's settling in around 1.68 kS/s on my rig:
* four 1070s: three MSI Gaming Xs and a PNY reference design
* Gentoo Linux
* mining at zpool
The MSI cards are power-limited to 115W and underclocked by 100 MHz. The PNY card is power-limited to 95W and running at stock speed. Total power consumption for the rig is 525W.
With the EWBF miner, I was seeing 1.52 kS/s. tpruvot's ccminer was running closer to 1.2, so even with a devfee, it looks like you're still coming out ahead.
|
|
|
|
Just got this up and running last night, and so far it looks like it's running like it should: https://gitlab.com/salfter/zpool-switchIt'll work anywhere you can run Python. It's developed and tested on Linux, so it'll be easiest to get it running there, but Mac OS X should be nearly as simple (so long as miner binaries are available). It's untested under Windows, but as long as Python abstracts away things like starting and stopping processes well enough, it ought to work with no more than minimal modification. No devfee. If you like it, you can always throw something in the tipjar (see below). The stock configuration handles most of the algorithms zpool supports. I left out sha256d and scrypt because it's pointless to GPU-mine them anymore, and there are maybe one or two others where I either couldn't get a GPU miner running under Linux or zpool appeared to have problems on its end. The miners I picked ran fastest for me on my 1070s; if you're running AMD GPUs, you'll want to substitute different miners (and benchmark them to see which ones run fastest for a given algorithm). Power management for nVIDIA GPUs is included. I do have an AMD GPU (an RX460) in my desktop machine...might need to experiment with that a bit. Speaking of getting miners running on Linux, I've put up Gentoo ebuilds for the ones that I'm using (and a few more besides): https://gitlab.com/salfter/portage |
|
|
|
I now have a working zpool auto-switcher: https://gitlab.com/salfter/zpool-switchA note of caution: the description of their API is pretty much non-existent, and the normalized-profit statistic they report isn't in the same units from one algorithm to the next (it's BTC/day per MH/s for most, per GH/s for several, per PH/s for sha256d, and per kS/s for ethash). Based on the data I've seen elsewhere, I think I have the right correction factors to correct all of them to BTC/day per GH/s, which matches up with the hashrates (in GH/s) in my miner configuration file. If you notice that a particular algorithm seems high or low by some multiple of 3 orders of magnitude, let me know. Further development of my auto-switchers will be under Gentoo instead of nvOC, but they should still work under nvOC with no changes to the Python code and just binary path updates in miners.json to reflect the different miner locations (the miner binaries live under /usr/bin on Gentoo). Also, the shipping miners.json refers to a miner (at https://github.com/krnlx/ccminer-xevan) that nvOC doesn't currently provide. Blake2S can be reconfigured to use tpruvot's ccminer at a minor performance hit. XEvan is a relatively new algorithm only supported by the aforementioned ccminer-xevan; as a fork of ccminer, it should be relatively simple to get running under nvOC if desired. |
|
|
|
I've had some issues recently with nvOC eating itself when Ubuntu pushes out an upgrade. Mostly it's updates to the nVidia drivers with mismatched libraries or something similar keeping miners from starting. The timing of the first two such incidents was particularly bad, as the first was right before I left for a cruise. I thought I'd fixed it, but it ate itself again a day or two later while I was somewhere off the coast between Long Beach and Ensenada.  I've kinda always had a bit of a preference for Gentoo. It's what most of my Linux boxes run (other than the Raspberry Pis, and I've even had Gentoo running on those from time to time), and it's what I'm most comfortable handling. I put an M.2 SSD back in my mining rig, got Gentoo up and running, and knocked together some ebuilds for the latest versions of several GPU miners. (The sp-mod ccminer needed some fixes to build against CUDA SDK 9, and I've also patched it so that it exits on the first SIGINT (like every other miner) instead of requiring you to press Ctrl-C twice.) I pulled in my MiningPoolHub switcher, and with changes to the miner paths (they all live in /usr/bin now), it works as it does on nvOC. I currently have the GPU fans on automatic, but I might port the fan-control code in nvOC to run the fans faster to keep the GPUs cooler. I've also benchmarked the different miners and algorithms again to see which ones are faster, and this might be of interest to nvOC users. The single-purpose miners (ktccminer-cryptonight, EWBF's equihash miner, and ethminer) are the fastest at their respective algorithms. Of the various forks of ccminer (tpruvot, sp-mod, KlausT, and alexis78), for the algorithms I've currently configured to mine at MiningPoolHub, sp-mod is faster at 5 algorithms (groestl, neoscrypt, qubit, skein, and x11) and tpruvot is faster at 3 (keccak, lyra2v2, and myr-gr). A table of what miner supports what and which miner is faster is at https://home.alfter.us/s/58BNGWUTxfpvr5U; yellow indicates an algorithm supported by only one miner, while boldface indicates the fastest miner I benchmarked on my four 1070s. I don't have my new system wrapped up in a tarball that you can download and dump onto a flashstick as with nvOC; that isn't really the Gentoo way. You can, however, recreate it for yourself. Install Gentoo as you normally would (I used the amd64 no-multilib profile), install Layman, use Layman to install my Portage overlay, install the miners, and install my MiningPoolHub switcher. A shell script launched from within /etc/local.d (or a cron job) can be used to run the switcher periodically. Next up: benchmark the algorithms available at zpool that I don't already have in the config. |
|
|
|
This appeared to build OK, but then it conked out again: nvcc -gencode=arch=compute_52,code=\"sm_52,compute_52\" -gencode=arch=compute_50,code=\"sm_50,compute_50\" -I/usr/local/cuda/include -I. --ptxas-options="-v" -gencode=arch=compute_20,code=\"sm_21,compute_20\" --maxrregcount=80 -o scrypt/salsa_kernel.o -c scrypt/salsa_kernel.cu
nvcc fatal : Unsupported gpu architecture 'compute_20'
I'd continue, but I'll need to look into this later as I have somewhere to be in a bit. Took another whack at it just now...fixed Makefile.am to build this with compute_30 instead of compute_20. It now builds (the fixes I applied are in https://gitlab.com/salfter/portage/tree/master/net-misc/sp-ccminer/files), but a quick run mining with the quark algo conked out after a few minutes with a floating-point exception. I'm not using excessive optimization...just -O2 -march=native, and the CPU for which it's building is a Celeron G3920. |
|
|
|
While trying to get the latest version built on Gentoo, I'm getting these errors: quark/cuda_skein512.cu: In function ‘void precalc()’:
quark/cuda_skein512.cu:2712:50: error: narrowing conversion of ‘2147483648u’ from ‘unsigned int’ to ‘int’ inside { } [-Wnarrowing]
0x08b2b050, 0x9d7c4c27, 0x0ce2a393, 0x88e6e1ea, 0xa52b4335, 0x67a16f49, 0xd732016f, 0x4eeb2e91,
^
quark/cuda_skein512.cu:2712:50: error: narrowing conversion of ‘2147483648u’ from ‘unsigned int’ to ‘int’ inside { } [-Wnarrowing]
quark/cuda_skein512.cu:2712:50: error: narrowing conversion of ‘2684354592u’ from ‘unsigned int’ to ‘int’ inside { } [-Wnarrowing]
quark/cuda_skein512.cu:2712:50: error: narrowing conversion of ‘4202700544u’ from ‘unsigned int’ to ‘int’ inside { } [-Wnarrowing]
quark/cuda_skein512.cu:2712:50: error: narrowing conversion of ‘3543279056u’ from ‘unsigned int’ to ‘int’ inside { } [-Wnarrowing]
quark/cuda_skein512.cu:2712:50: error: narrowing conversion of ‘4142317530u’ from ‘unsigned int’ to ‘int’ inside { } [-Wnarrowing]
quark/cuda_skein512.cu:2712:50: error: narrowing conversion of ‘3003913545u’ from ‘unsigned int’ to ‘int’ inside { } [-Wnarrowing]
...
This is on a new build I just set up last night, building against CUDA SDK 9.0.176. I already have tpruvot-ccminer (on which sp-ccminer is based) built and running. I've never written any CUDA code, but it looks like unsigned values are being written into a couple of signed arrays. I'm trying a build now with this patch: --- quark/cuda_skein512.cu~ 2017-01-01 12:38:31.000000000 -0800
+++ quark/cuda_skein512.cu 2018-01-20 14:05:06.764299663 -0800
@@ -2704,7 +2704,7 @@
// buffer[8] = 0x7000000000000040ull; //t2;
CUDA_SAFE_CALL(cudaMemcpyToSymbol(precalcvalues, buffer, sizeof(buffer), 0, cudaMemcpyHostToDevice));
- int endingTable[] = {
+ unsigned int endingTable[] = {
0x80000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000200,
0x80000000, 0x01400000, 0x00205000, 0x00005088, 0x22000800, 0x22550014, 0x05089742, 0xa0000020,
@@ -2715,7 +2715,7 @@
0x4f0d0f04, 0x2627484e, 0x310128d2, 0xc668b434, 0x420841cc, 0x62d311b8, 0xe59ba771, 0x85a7a484
};
- int constantTable[64] = {
+ unsigned int constantTable[64] = {
0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,
0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,
0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, 0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,
This appeared to build OK, but then it conked out again: nvcc -gencode=arch=compute_52,code=\"sm_52,compute_52\" -gencode=arch=compute_50,code=\"sm_50,compute_50\" -I/usr/local/cuda/include -I. --ptxas-options="-v" -gencode=arch=compute_20,code=\"sm_21,compute_20\" --maxrregcount=80 -o scrypt/salsa_kernel.o -c scrypt/salsa_kernel.cu
nvcc fatal : Unsupported gpu architecture 'compute_20'
I'd continue, but I'll need to look into this later as I have somewhere to be in a bit. |
|
|
|
|
Maybe what follows is common knowledge, but it caught me out:
Back when I first set up nvOC, I was having trouble with it accessing things via IPv6. I worked around it by putting IPv4 addresses for things like the MiningPoolHub server in /etc/hosts.
Where I have my mining rig located, there's no network jack in the wall. Stringing a cable across the room wasn't really a long-term option either, so I bought an Asus RP-N12, configured it as a wireless bridge, and plugged the rig into a switch and the switch into the bridge. Should've worked, right? Turns out there's an issue with the way traffic gets delivered over the bridged connection that keeps IPv6 from working.
I unplugged the network cable and plugged a USB WiFi dongle (more specifically, an Edimax EW-7811Un I'd originally bought for use with a Raspberry Pi) in. Booted up, switched to a text console, fired up nmtui to configure it with my SSID and password, and rebooted...and now it's connecting directly over WiFi instead of through the bridge. IPv6 works like it should.
I've recently started work on a zpool auto-switch. I put in code to connect to their server over IPv4 specifically. Looks like I can rip that out and go with something simpler that'll use IPv6 if it's available.
|
|
|
|
I had been running v0.19 for the past few months, but an auto-update broke things such that the miners wouldn't work. I recently updated to v0.19-1.4 and found it was mostly working, but whenever it started trying to mine Feathercoin (I use my MiningPoolHub switcher), the miner still didn't kick in and the rig would sit idle until (1) another coin became more profitable or (2) I noticed by the lack of fan noise that the rig was idle. I tried firing up KTccminer manually a little bit ago, but found that it ended almost right away with an illegal-instruction error. I'm rebuilding it right now (make clean && make -j3); I'm guessing the rebuilt miner will work properly and I'll be able to reenable Feathercoin (currently the most profitable, as it happens). It was configured to use -march=native. My mining rig uses a Celeron G3920; odds are the miner was last built on a Core iSomethingorother with some additional instructions beyond what the Celeron supports. Pre-post update: it looks like make clean && make -j3 was insufficient, as it runs a couple seconds longer before it segfaults. INSTALL recommends running build.sh, so I'm doing that. Update: Now I'm getting this set of errors: ccminer 8.13-KlausT (64bit) for nVidia GPUs
Compiled with GCC 5.4 using Nvidia CUDA Toolkit 8.0
Based on pooler cpuminer 2.3.2 and the tpruvot@github fork
CUDA support by Christian Buchner, Christian H. and DJM34
Includes optimizations implemented by sp-hash, klaust, tpruvot and tsiv.
[2018-01-17 14:34:55] Starting Stratum on stratum+tcp://hub.miningpoolhub.com:20510
[2018-01-17 14:34:55] NVML GPU monitoring enabled.
0
1
[2018-01-17 14:34:55] GPU #2: waiting for data
[2018-01-17 14:34:55] GPU #1: waiting for data
[2018-01-17 14:34:55] 4 miner threads started, using 'neoscrypt' algorithm.
[2018-01-17 14:34:55] GPU #0: waiting for data
[2018-01-17 14:34:55] GPU #3: waiting for data
[2018-01-17 14:34:55] Stratum difficulty set to 2048
[2018-01-17 14:34:55] Stratum difficulty set to 523.054
Cuda error in func 'neoscrypt_cpu_init_2stream' at line 1431 : invalid device symbol.
Cuda error in func 'scanhash_neoscrypt' at line 96 : driver shutting down.
Segmentation fault
I went looking for another miner to handle NeoScrypt and found NSGminer: https://bitcointalk.org/index.php?topic=712650.0git clone https://github.com/ghostlander/nsgminer
cd nsgminer
./configure CFLAGS="-O2 -fomit-frame-pointer -DASM -DOPT -DMINER_4WAY -DSHA256 -march=native" --disable-adl --disable-nvml --without-curses
make -j3
This miner normally tries to manage clock and fan settings by itself; we disable those so the other parts of nvOC that handle those still work. curses (full-screen interface) support is also disabled. The part of 3main that writes mph_conf.json then needs to be modified: "NeoScrypt":
{
"bin": "/home/m1/nsgminer/nsgminer -k neoscrypt -g 1 -w 64 -I 15 -o stratum+tcp://{HOST}:{PORT} -O {NAME}.{MINER}:x",
...
(If you're not using my MiningPoolHub auto-switcher, make the equivalent change elsewhere.) In limited testing, NSGminer appears to run a little bit faster on my 1070s than KTccminer did, but more extensive benchmarking (to include power measurements) is needed. |
|
|
|
Is there a way to keep the miner screen persistent when using WTM profit switcher? After moving to a new coin you have to resume the miner screen manually using "screen -r miner" to monitor the process. Would it be possible to add this command at end of the switching script to bring the miner up in a new guake tab after switching to a new coin?
Try something like this: while true; do screen -dr miner; sleep 2; done To exit out, hit Ctrl-A Ctrl-D, then hit Ctrl-C within two seconds. |
|
|
|
By the way, I hate the way Microsoft updates production machines while they are working. Next, I hate that afterburner doesn't necessarily restart the fan settings. Sigh...
That's why you don't use Windows on mining rigs.  |
|
|
|
Been a while since I've popped my head in here...been running rather uneventfully with nvOC and my auto-switcher, watching coin pile up. The auto-switcher writes its activity to a file, algo-log. Yesterday, I got around to knocking together a simple tool that looks at the algo-log file and tells you what you've been mining recently: #!/usr/bin/env python3
from datetime import datetime, timedelta
import sys
import operator
end=datetime.now().replace(microsecond=0)
try:
start=end-timedelta(days=int(sys.argv[1]))
except:
start=end-timedelta(days=1)
l={}
with (open("algo-log", "r")) as f:
for i in f:
curr=datetime.strptime(i[0:19], "%Y-%m-%d %H:%M:%S")
curr_algo=i[28:].split(" ")[0]
if (curr>start):
try:
l[curr_algo]+=curr-last
except:
l[curr_algo]=curr-last
last=curr
last_algo=curr_algo
try:
l[last_algo]+=end-last
except:
l[last_algo]=end-last
for i in sorted(l.items(), key=operator.itemgetter(1), reverse=True):
print(i[0]+" {0:0.3f}".format(i[1].days*24+i[1].seconds/3600))
By default, it counts up which coins have been mined over the past day and prints a sorted list. Here's what I've been mining: feathercoin 6.901
monacoin 5.013
digibyte-skein 4.043
vertcoin 4.014
zencash 4.010
bitcoin-gold 1.508
Follow it with a number to get that many days' worth of analysis. Here's my past week (./top-algos.py 7): feathercoin 48.667
monacoin 22.975
vertcoin 17.542
zencash 16.712
digibyte-skein 16.211
groestlcoin 12.701
zclassic 8.029
bitcoin-gold 7.022
ethereum 4.514
monero 4.020
zcash 3.511
maxcoin 3.511
ethereum-classic 3.009
|
|
|
|
Crap...just realized I forgot to include a link to the article in my post.  |
|
|
|
Any one having issue with MPH_SWITCHER ??
It was working fine, but stopped suddenly; can't see any error trace!!
There was one instance a week or so ago where switching stopped; a reboot fixed that, and it's not happened again since. I don't know why it did that...temporary blockage of MiningPoolHub's API, perhaps? |
|
|
|
|
Show Posts
