CryptoCurrency Mining with GPUs *spawn*

I just remembered I have a GTX 660 Ti laying around, and it supposedly does close to 300 H/s at 130W. And my desktop motherboard does have a bunch of free PCIe slots

Hmmm....

Are you currently using the "XMR-Stak - Monero/Aeon All-in-One Mining Software"?
https://github.com/fireice-uk/xmr-stak

XMR-Stak is a universal Stratum pool miner. This miner supports CPUs, AMD and NVIDIA gpus and can be used to mine the crypto currency Monero and Aeon.

I really like that this miner handles AMD and Nvidia GPUs along with CPU mining.

On my two T5600's I have added in three additional nVidia GPU's each. The T5600 seems to have a problem in getting stuck with a "2" led error which means problem initializing a video card if I put in four. So one T5600 I have three Quadro 600's and the other T5600 I have a Quadro 2000 and two Quadro 600's. The base hash rate for the Quadro 600's is 86 H/s and 108 H/s for the Quadro 2000. I am overclocking them and now get 129 H/s on the Quadro 2000 and 113 H/s on two Quadro 600's and 106 H/s on the other three (I had to reduce the overclock because the miner was reporting Nvidia errors.

I do have them enabled, but does this have anything to do with page file?
I don't have any page file configured for 2 reasons: I'm running low on my my C:\ drive and I have 64GB RAM so I never really need page files.
I tried to configure a page file into a RAM Drive I have, but it won't let me unfortunately.

I believe that you do need a page file. It doesn't actually use the page file but seems to need it for the "Large Pages" locking to work. You can try with the system suggested page file size first. If that improves the hash rate you could then try setting a min/max at 25MB (the L3 size) and then maybe min/max at 8MB to see if the hash rates stay steady.

Also when you first start the miner do you see any warnings?
 
Last edited:
That's interesting. I just came back to CPU mining after a hiatus of 2 years and have the exact same Xeon as you, two of them actually.

Do you have hyperthreading disabled? With my system I was doing close to 900 H/s with 20 cores and both hyperthreading and low power mode disabled. Looking forward to see how this would compare to my newly ordered Titan V :)

You do not have to disable hyperthreading just be sure to lock the mining to even numbered cores. Also don't have the miner exceed the L3 cache size.
Remember "low_power_mode" : true uses 4MB cache and "low_power_mode" : false uses 2MB cache.

Example configuration on a Dell T5500 workstation with dual Xeon X5687 quad-core w/HT that have 12MB L3 cache.

"cpu_threads_conf" :
[
{ "low_power_mode" : true, "no_prefetch" : true, "affine_to_cpu" : 2 },
{ "low_power_mode" : true, "no_prefetch" : true, "affine_to_cpu" : 4 },
{ "low_power_mode" : true, "no_prefetch" : true, "affine_to_cpu" : 6 },
{ "low_power_mode" : true, "no_prefetch" : true, "affine_to_cpu" : 10 },
{ "low_power_mode" : true, "no_prefetch" : true, "affine_to_cpu" : 12 },
{ "low_power_mode" : true, "no_prefetch" : true, "affine_to_cpu" : 14 },
],

I only use three real cores (2, 4 and 6) in each cpu and leave core 0 free. These three mining core use a total of 12MB cache and the system is still responsive since it has two real and eight HT cores unused.
 
Are you currently using the "XMR-Stak - Monero/Aeon All-in-One Mining Software"?
https://github.com/fireice-uk/xmr-stak
Yup.

I believe that you do need a page file. It doesn't actually use the page file but seems to need it for the "Large Pages" locking to work. You can try with the system suggested size first. If that improves the hash rate you could then try setting a min/max at 25MB (the L3 size) and then maybe min/max at 8MB to see if the hash rates stay steady.

I tried it but couldn't see much of an improvement.

Regardless, the system is a bit unstable as I need to reload the graphics driver rather often, otherwise the miner will sharply decrease the GPU's performance.
What I need to do now is get that 660 Ti up an running, though.


My only problem with the Vega is how loud it must be to keep the HBM2 below 70ºC. This is where I see that a 3rd party cooler would come in handy. Thank god I have some great noise cancelling QC35 otherwise I'd have headaches at the end of the day.
 
Interesting that one can dictate L3 cache usage by using/not using cores/threads. I assumed the CPU filled L3 to capacity with stuff regardless of the amount of threads working... (Perhaps with some locality prioritization for frequently used data for good measure.)
 
Interesting that one can dictate L3 cache usage by using/not using cores/threads.
IIRC you can make a program that allocates X amount of memory, and if it's single-threaded then it'll run inside the fastest memory pool that can fit X.
So if I have a program loop that allocates 1MB, it'll run on the L2 if it fits the L2, otherwise it'll go to the L3. If there's no L3, it'll go to the system RAM.

In the end, I can dictate a 20MB L3 cache usage by running a program on the CPU that allocates 20MB.

I assumed the CPU filled L3 to capacity with stuff regardless of the amount of threads working...
Yup, it does.
And that's why I was only getting ~70H/s per core instead of the ~80Hs/ it should be able to do. And then I started to use my desktop that hashrate went down to 55 H/s or less (330 H/s total).
What was probably happening was that 1MB left of L3 cache wasn't enough for windows to maintain coherency between cores, so those cores needing 4MB were all getting less and waiting for the system RAM as a result.

As soon as I turned off "low_power_more" in one of those cores and ended up with 3MB of "free" L3 cache, all the others jumped to 80H/s. Now I have 1 core at 45H/s and 5 cores at 80H/s, for a total of 445 H/s.



BTW, an interesting thing about Vega is that if you try to overclock the HBM from its default values and it reaches 70 Cº, it'll enter some kind of power saving mode and drop hashrate considerably.
But if you don't overclock, it'll be comfortable up to 75Cº and won't drop the hashrate.
This gets me only ~1750 H/s on the Vega 64, but at a fan noise level that won't drive me nuts.



So now I'm getting 1750 H/s on the Vega + 445 H/s on the CPU and 285 H/s on the 660 Ti.
Almost 2500 H/s on 465W at the wall.
Not bad for a heater.
 
BTW, an interesting thing about Vega is that if you try to overclock the HBM from its default values and it reaches 70 Cº, it'll enter some kind of power saving mode and drop hashrate considerably.
Hm, that's interesting. From what I've heard, 85C was the thermal limit for the HBM, when it would up the DRAM refresh rate to a point where it would noticeably interfere with memory access performance, this is the first time someone's reporting of performance issues at even lower temps. And as we all know, it's difficult to keep temps from galloping well above 70-75C on air cooling on a high-powered GPU...
 
From what I've heard, 85C was the thermal limit for the HBM, when it would up the DRAM refresh rate to a point where it would noticeably interfere with memory access performance, this is the first time someone's reporting of performance issues at even lower temps.

I should have clarified it's a performance issue in one very specific case:
- Going over 70ºC will cause a 300-400 H/s rate drop in XMR mining if using the 6 month-old beta blockchain driver in a Vega and if the HBM2 is overclocked.

And it seems to be a known issue:

MIN FAN SPEED: 3000 (you'll need it way high and loud to keep HBM below 70ºC) If you're using additional cooling like A/C, additional fans or you just have a low ambient temperature, this value might be lower.


Right now my Vega 64 is doing ~1740 H/s with the 945MHs HBM2 at 74ºC just fine.
I didn't see this drop when I was using the latest adrenalin drivers even when I clocked the HBM2 at 1025MHz. But then again those drivers would only get me around 1200 H/s on my Vega.


I think it might be an additional safeguard AMD put into these drivers because they knew people would tend to push the HBM2 to the limit, and it's cheaper to change an ageing fan than an entire card.
 
I've started CPU mining XMR on my Ryzen 7 and I'm getting 560HS/s @3.8GHz and 610HS/s at 4GHz using 8 threads and Claymore miner. Is that good or are there any tweaks I can do to improve it?
I don't want to switch to blockchain driver, so I probably will stick with ETH GPU mining as XMR gave me mere 1120HS/s with 1.1GHz HBM2 using Adrenaline driver.
 
In the meantime, I also found out that as soon as I ramp up the miner exectuable (and without overclocking the memory), I can lower the Power Limit all the way down to -50% which only lowers Vega's hashrate by about 40 H/s but brings the power consumption down by a whopping 60W.
The best thing about this is I can lower the fan down to 2450 RPM and which doesn't even bother me that much, and the HBM2 stays at about 62º C.



I don't want to switch to blockchain driver, so I probably will stick with ETH GPU mining as XMR gave me mere 1120HS/s with 1.1GHz HBM2 using Adrenaline driver.
Adrenalin is terrible for XMR, unfortunately.
It seems some people are getting the "Compute Mode" toggle in their Adrenalin drivers (I didn't, not even after a clean install with registry cleaning, etc.), and that seems to help. But XMR on Vega is only worth it if you have the blockchain driver installed.

The advantage of XMR is that you can just use everything to mine to the same wallet. And since all pools require at least 0.3 XMR for payout then at least you'll get your cryptocurrency sent to your wallet a lot faster. 600 H/s on Monero 24/7 means you'll only get your 0.3 XMR transfer in about 2 months or more. The coin could be dead by then, for all we know....
I don't know how's the minimum payout on Ethereum though..
 
You do not have to disable hyperthreading just be sure to lock the mining to even numbered cores. Also don't have the miner exceed the L3 cache size.
Remember "low_power_mode" : true uses 4MB cache and "low_power_mode" : false uses 2MB cache.

Example configuration on a Dell T5500 workstation with dual Xeon X5687 quad-core w/HT that have 12MB L3 cache.



I only use three real cores (2, 4 and 6) in each cpu and leave core 0 free. These three mining core use a total of 12MB cache and the system is still responsive since it has two real and eight HT cores unused.

I've tried that, but after 20 threads the performance deteriorates whatever I do. The best I could get with HT on was around 850 H/s, and that was only with the real even numbered cores. With HT turned off, I can get 960 H/s with "low_power_mode" : false on all cores.
 
Of late, I've been trying out the auto-profit-switching mining software route connecting to a multipool with auto-exchange to Vertcoin (this one because of relative price stability and low transaction fees) and this has been working out well. I've been getting a payout to my personal Vertcoin wallet ~ every 20 hours that is in excess of what I was getting before every 24 hours mining it directly. Being able to use my CPUs mining Monero to "buy" Vertcoins is helping. I may experiment with other coins besides Vertcoin to use as a "value mule". Anyone have any suggestions? Priorities are low transaction fees, speed of transactions/confirmations and price stability.

Beyond this, does anyone have any experience or thoughts on mining to obtain value and then transferring that value to a POS coin to hold and accrue additional value?
 
There are no rock-solid PoS coins ATM, IMO. Also the PoS coins I've seen return 25% yearly, at most. Which could be offset by price increases
DCR may be an option thought, perhaps?

On the other hand, the more different coins you hodl, the safer you'll be. So you should cycle VTC with some others. Why not also XMR & ETH. They loook among the safest
 
I'd say ETH and Ripple seem the safest right now. Ripple won't have the equity-growth potential of ETH, but it seems, more and more, to be moving towards the preferred back-end ledger. I also see long-term potential for RDD to take over where Patreon has sort of fallen flat. It's only a staking coin.
 
I'm not that sure about safety with Ripple. It's going up so high now that I feel a correction is coming (got more than 100% back by buying $XRP & $XLM less than two weeks ago).
But yeah, I agree that over long term it shoul not loose (much) value. It could yet also gain a lot still, on the flipsite

( Ripple is also boring tech since it's a corporation's take on BTC. But yeah, it pays off so good now that it's hard to resist)
 
RDD is kind of appealing to me, actually. The staking system doesn't lock up your coins and I can Shapeshift to it from VTC and Shapeshift from it to BTC for any purchases I might make. Maintaining liquidity is important for me, because I am going to try to use mining earnings to opportunistically fund future GPU purchases.
 
Isn't Ripple practically against everything cryptocurrencies stand for?
It's a corporate-backed and currency with the highest transfer fee out there. You can't mine it because it's already 100% owned from day one.
 
Isn't Ripple practically against everything cryptocurrencies stand for?
It's a corporate-backed and currency with the highest transfer fee out there. You can't mine it because it's already 100% owned from day one.

The bulk of the people investing at this point don't seem to care about these principals very much.
 
Back
Top