Search content
Sort by
Showing 20 of 621 results by salfter
Re: Let's share some of our Bitcoin Pizza moments for the new ATH
⭐ Merited by DdmrDdmr (1)
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.
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.
I'm getting back in after a bit of a hiatus. The ASICs I bought a few years ago are only really good as space heaters now, but GPUs have strangely become profitable again, so here's a restart...click for high-res shots:
Base system's a Celeron G3920 (the slowest Skylake) with 8 GB RAM and a 128 GB M.2 SATA SSD. It's running on a single GeForce GTX 1070, but if I unplug the front-panel USB 3.0 jacks (for clearance...or maybe I can use one of these), I can add three more. It's all-new components except for the power supply, which was last used with a bunch of Gridseeds. I haven't plugged it into a Kill-a-Watt yet, but depending on the numbers it returns, a new power supply might be needed along with the fourth GPU. The case was only $55 and has the eight expansion slots needed...cheaper than a Spotswood frame, everything's well-protected, and it doesn't look too riced-out (though I would've preferred plain black fans over ones that light up).
Base system's a Celeron G3920 (the slowest Skylake) with 8 GB RAM and a 128 GB M.2 SATA SSD. It's running on a single GeForce GTX 1070, but if I unplug the front-panel USB 3.0 jacks (for clearance...or maybe I can use one of these), I can add three more. It's all-new components except for the power supply, which was last used with a bunch of Gridseeds. I haven't plugged it into a Kill-a-Watt yet, but depending on the numbers it returns, a new power supply might be needed along with the fourth GPU. The case was only $55 and has the eight expansion slots needed...cheaper than a Spotswood frame, everything's well-protected, and it doesn't look too riced-out (though I would've preferred plain black fans over ones that light up).
I used to have my gear stashed in a wooden bar in the dining room. After that, it found a home for a while in a changing table (normally used when changing a baby's diaper) in the office/spare bedroom. Now it's in the laundry room, where all of the heat and some of the noise are kept away from people:
Some of the boards in the Bitfury rig are missing heatsinks because they arrived a few days before the heatsinks, but they're hashing OK without them. The BFL Jalapeños are controlled by the RPi in the Bitfury rig. The Bitfury and BFL hardware are running off a 550W Seasonic, while the Antminer has a 600W Corsair. Total hashrate is about 450 GH/s; power consumption is about 700W. Since the laundry room doesn't have a network run going to it, I'm using a powerline network adapter (not shown) for access.
Up to a point, more Bitfury hardware will just slot in...it's already expanded from 2 cards to 6, and then to 9. For more Antminers or other hardware, though, I'll probably need to figure out something better than just using the shelf that's already in the room. For more power, I'd most likely need to run another circuit. The room was set up for a gas dryer only, so there's no 240V 30A service in place. Adding a 14-30R outlet wouldn't be out of place, and it could feed a subpanel (?) with four independent 120V 15A circuits.
Some of the boards in the Bitfury rig are missing heatsinks because they arrived a few days before the heatsinks, but they're hashing OK without them. The BFL Jalapeños are controlled by the RPi in the Bitfury rig. The Bitfury and BFL hardware are running off a 550W Seasonic, while the Antminer has a 600W Corsair. Total hashrate is about 450 GH/s; power consumption is about 700W. Since the laundry room doesn't have a network run going to it, I'm using a powerline network adapter (not shown) for access.
Up to a point, more Bitfury hardware will just slot in...it's already expanded from 2 cards to 6, and then to 9. For more Antminers or other hardware, though, I'll probably need to figure out something better than just using the shelf that's already in the room. For more power, I'd most likely need to run another circuit. The room was set up for a gas dryer only, so there's no 240V 30A service in place. Adding a 14-30R outlet wouldn't be out of place, and it could feed a subpanel (?) with four independent 120V 15A circuits.
I finally brought the Jalapeños home (had them at work for the first few months) and set them up with my GPUs on a headless, diskless (only storage is a 16GB USB flashstick) mining rig.
The motherboard, processor, and memory are castoffs I had on hand: a 3-GHz Pentium 4 on an Intel D945GNT with 3 GB of DDR2 (IIRC). In addition to the Jalapeños for SHA-256 mining, it has a 6870 and a 7750 for scrypt mining. A Seasonic SSR-550RM sits behind the Jalapeños.
The next photo is from an intermediate step in setting up the rig, without all the mining hardware plugged in (just the 6870 and one Jalapeño, off-frame):
Since I don't have a network jack close by, it's using a USB WiFi dongle. I might replace that with a PCI WiFi card. The flashstick doesn't show up, but it's plugged in underneath the WiFi dongle. Patriot Autobahn flashsticks barely stick out of the port when they're plugged in.
For software, it's running Gentoo Linux. Two instances each of cgminer and CryptoSwitcher mine the most profitable SHA-256 coin and scrypt coin.
I intend to make up a frame with some aluminum extrusions to hold the motherboard, GPUs, and power supply. The Jalapeños (and the Bitfury miner that should arrive later this month) I'm thinking can just sit on one or two shelves. I'm thinking that when this happens, the rig will get moved out from under the bar and onto its own little rack of some sort.
The motherboard, processor, and memory are castoffs I had on hand: a 3-GHz Pentium 4 on an Intel D945GNT with 3 GB of DDR2 (IIRC). In addition to the Jalapeños for SHA-256 mining, it has a 6870 and a 7750 for scrypt mining. A Seasonic SSR-550RM sits behind the Jalapeños.
The next photo is from an intermediate step in setting up the rig, without all the mining hardware plugged in (just the 6870 and one Jalapeño, off-frame):
Since I don't have a network jack close by, it's using a USB WiFi dongle. I might replace that with a PCI WiFi card. The flashstick doesn't show up, but it's plugged in underneath the WiFi dongle. Patriot Autobahn flashsticks barely stick out of the port when they're plugged in.
For software, it's running Gentoo Linux. Two instances each of cgminer and CryptoSwitcher mine the most profitable SHA-256 coin and scrypt coin.
I intend to make up a frame with some aluminum extrusions to hold the motherboard, GPUs, and power supply. The Jalapeños (and the Bitfury miner that should arrive later this month) I'm thinking can just sit on one or two shelves. I'm thinking that when this happens, the rig will get moved out from under the bar and onto its own little rack of some sort.
Heat rises...besides, I'm a beer drinker.
In any case, it's not a permanent setup. I just wanted to get the GPUs out of the room they were in previously; that room was getting unbearably warm.Might just yank the GPUs altogether once the Bitfury hardware arrives; it'd lower my electric bill a fair bit. (A Raspberry Pi is bundled with it...wonder if I could have it handle the BFL hardware too, since the Bitfury is connected to it through the GPIO port.)
Re: [ANN] ** NEW SITE bitgem.pw ** BTG BitGem 0.4.9.ALPHA1 | COLORED COINS | FAUCET
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).
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.)
Re: [ANN] ** NEW SITE bitgem.pw ** BTG BitGem 0.4.9.ALPHA1 | COLORED COINS | FAUCET
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.
Re: [ANN] Bminer: a fast Equihash miner for CUDA GPUs (5.2.0)
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.
* 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-switch
It'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
https://gitlab.com/salfter/zpool-switch
It'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-switch
A 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.
https://gitlab.com/salfter/zpool-switch
A 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.
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:
I'd continue, but I'll need to look into this later as I have somewhere to be in a bit.
Code:
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'
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:
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:
This appeared to build OK, but then it conked out again:
I'd continue, but I'll need to look into this later as I have somewhere to be in a bit.
Code:
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]
...
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:
Code:
--- 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,
+++ 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:
Code:
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'
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.
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:
I went looking for another miner to handle NeoScrypt and found NSGminer:
https://bitcointalk.org/index.php?topic=712650.0
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:
(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.
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:
Code:
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
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.0
Code:
git 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
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:
Code:
"NeoScrypt":
{
"bin": "/home/m1/nsgminer/nsgminer -k neoscrypt -g 1 -w 64 -I 15 -o stratum+tcp://{HOST}:{PORT} -O {NAME}.{MINER}:x",
...
{
"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:
Code:
while true; do screen -dr miner; sleep 2; done
To exit out, hit Ctrl-A Ctrl-D, then hit Ctrl-C within two seconds.
Re: [ANN][POOL] Mining Pool Hub - Multipool. Multialgo, Auto Exchange to any coin.
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.