Okay so basically the idea was, with my gear I have laying around my place, can I actually mine? Everybody is on that Ethereum (ETH) craze but I was wanting something another step removed, something different, which landed me on Monero (XMR)!

Oct 21, 2017 - Monero mining is more efficient on GPU but its technically totally possible to do it on a Raspberry CPU. The Raspberry is an 32bit processor and the cpu miner is 64bit only, you have to recompile it. If you are able to acquire raspberry pi at no cost and have no power cost its possible and would be proficient.

Now there's two desktops, an older laptop, and I'm considering the entire network to be a power usage for this as well. Each device has it's own 1500PFCLCD that keeps it online and running clean, though the laptop and network share one. Now I want to point out before I start getting into the stats, I just started out with XMR. I've spent a good amount of time doing little tweaks and optimizations, while watching system stability throughout the day. Though I'm positive more knowledgeable miners would be able to achieve much better results then what I'm showing here, though this is how we learn! CPU #1: i7-5930K @ 4.5ghz across 10 threads = 331.5 H/s GPU #1: Geforce Titan X (Pascal) @ 2ghz/5ghz = 872.6 H/s POW #1: 396W (monitors, speakers, mics off) CPU #2: i7-5820K @ 4ghz across 11 threads = 304.8 H/s GPU #2: Geforce GTX 1080 (Gigabyte WaterForce) @ 2ghz/5ghz = 581.7 H/s POW #2: 324W (monitors & speakers turned off) CPU #3: i7-3720QM @ 3.4ghz across 7 threads = 131.1 H/s POW #3: 108W (laptop lid shut) (includes modem, router, & pi-hole) Total Hash Rate: 2221.7 H/s Total Power: 828W Now this returns after all the power is accounted for $4.99 a day, or $149.72 a month!

That's of course at this exact moments exchange rates though I'm not complaining for power that was going unharnessed beforehand. My gig internet is $200 a month, so it's paying for about 75% of my internet bill.

Though as you can see, this is not how miners build rigs! A Titan X (Pascal) on an insane custom EKWB loop? Yeah that's not helping anyone make money mining, nobody would ever purchase this gear for mining. Though like I said, they're my personal machines, so I figured why not, let's see just what they'll do! Though I know you guys are going to want screenshots on everything, some text in a box just isn't going to cut it!

So I've came prepared! Box #1 Mining. Overall this has been a fun day playing around with a newer crypto currency and looking to see what can actually be done with the gear laying around your home!

I've got a couple old xeon boxes in storage that I might have to drag out, strip down, and see what they can mine in a linux environment. These two boxes still see daily use, so the miners have been dialed down a little bit to still allow for a responsive & easy to use interface. Though those boxes I could just go full tilt inside linux as they'd serve no other purpose. If I get around to this I'll be sure to post additional results! Anyways, I hope this was helpful or atleast entertaining to some of you out there. 'Gobby Update: I had already walked away from making this post when it hit me I had made a huge omission. Look at those overclocks on the graphics cards.

Look a little odd? When you fire up the mining software it down clocks the memory on the cards. So once you've started mining (atleast on water), you can start pulling your clocks up again.

Though, make sure you close afterburner before you close your miner if you're ever going to stop. Because once the miner closes, it'll return your clocks to normal, which means you've now got some stupid AF overclocks going on.

So yeah, remember that little note. As you can see, the screenshots were taken literally like 6-7 hours into mining so the overclocks are in full force! Okay, now I'm going to walk away again. Day 2 Updates! Woke up this morning and everything was still mining just fine.

Though I wanted to see if I couldn't really optimize things, push them to the max, and overall improve the gains I'm seeing off this home mining setup. The first thing I did was download the newest graphics drivers and install them, then I started looking at max gpu overclocks from the standard online communities. Finally I looked at all my settings files looking for mistakes, or places I could try and push things further. After all this became the actual process of testing the new overclocks on the graphics cards, which went smoother then I expected. Both the Titan X (Pascal) and the 1080 WaterForce are running smoothly at 2113mhz on the Core though the memory on the Titan is at 5514mhz while the memory on the WaterForce is at 5556mhz.

This is purely because the slider in Afterburner maxes out at +1000 which is where it's sitting on the Titan post mining downclock to achieve the 5514mhz. I also went in an enabled the network stats pages so that I didn't actually have to turn on monitors to check progress of machines & could do it easily from my phone anywhere in my home.

(a nice touch!) What did all this gain me? Well a 7.57% increase in mining output! My new hash rate across the gear is 2389.9 H/s based on the 15 minute averages they record.

(not the highest hit rates alot of people seem to like to post) Though let's talk economics here! You know what really made my day? I called Comcast this morning, yup, on a Sunday, their call center was dead silent in the background. I spent 52 minutes on the phone chatting up a guy from Arizona. I got my bill reduced to $113 a month pre-TB cap fees.

So in reality, an hour on the phone spent blind fishing a better deal has turned this whole operation into an extreme win! Now I'm completely paying for my internet bill with this setup, even on the months I have to pay heavy in extra bandwidth. ($50 extra for unlimited) Sooo yeah, Monero baby, you making me pretty happy. In comparison, I saw on reddit a guy with a new RX Vega 64 who is getting hash rates of about 1150ish while burning 300w. That makes this cracked out Titan X (Pascal) feel a bit better now that it's pushing 960.6 given it's only using 60% of it's power most the time and spiking up to 84% as you can see in previous afterburner pictures. Though let's be clear, I understand, this is a freaking titan, and not a card bought to mine on. Instead of coming back with all the same pictures this time, just with different clock speeds, I've put together all the neat little network screens showing my current hash rate.

Days 3 - 6 Updates: Welcome back to the mining adventure everybody! Sorry for the long gap since updates and for not responding to questions on the different foras I posted this! So as the story goes, I did infact head across town and grab a dual xeon machine out of storage, it had sat in Colorado storage for a while meaning it had seen temps as low as -15F an as high as 100+. I'd never had a problem with it before but it was over a decade old now & when I pulled it apart looked like I'd ganked all the parts out of it once before an forgotten. I headed over to the CSU Surplus Store where they sell just about anything a nerd could want at discount prices. Ram there is $2.50 a gig, doesn't matter type, speed, or manufacturer. They just have bins labelled 'DDR 2 ECC/REG' etc.

An you dig through them. I dropped in & grabbed six sticks for the xeon box (it maxes out at 12gb so six 2gb sticks), the best video card they had in stock an old firepro V3900 for $7, & $10 for a 160GB 10K velociraptor to slap in there.

Total price was $51 for all the upgrades so in terms of stepping on the mining profits, not a cheap investment for a shot in the dark. I got home, attempted to put them in, and oh no I'm a dumbass. I had grabbed DDR2 F thinking for sure this old xeon server ran fully buffered. Though as soon as you try to put a stick in and see that you're a couple pins off on your notch you'll for sure feel like a very bad tech. It was already to late to head back so I just called it for the day & started playing around with the Titan more.

(more on that later) The next day I dropped back in and explained to the tech there testing parts the mistake I had made. He laughed, said no big deal, let me swap my ram out for the proper model. Cool deal, get home, plug them all in.

Machine beep code of doom. Look it up, memory error.

Oh cool I can't use slots 5 & 6 in this configuration, okay well whatever 8gb is still better then nothing. BEEP CODE OF DOOM.

Go into bios, look it over, proceed to spend the next hour with not just these sticks but other sticks testing everything I could imagine. Turns out from?? Things are now really screwy and not like how I last left the box before long term storage.

Memory slots 1, 3, & 5 are gonezo, no detection, nothing. Memory slots 2, 4, & 6 work but only detect 1gb sticks I pulled from another box, none of the sticks I paid $30 for work at all.

Being positive minded I'm all like, we can still make this work, fuck it! Let's just put Debian on here, start mining with 3gb of ram, and see what hash rates we get.

Well okay, make a usb boot drive, go to install. System Halted. Can't get past boot, always System Halted.

Throws a memory config error right before. Go into bios, notice that while it's reading the 1gb sticks, the system can't tell how much memory is actually installed, it's totally fucked up. This is a lost cause, but the day was late and I had other things to do. So next morning comes, I load up all the parts I bought, plus the other ram I had pulled as I didn't need it anymore & headed back to the surplus. They don't take parts back and you have to pay to recycle there.

I said well look guys, I'm going to give this to somebody on craigslist or you can just consider it a $50+ donation to the school and sell these parts to the next guy. Somebody is going to come in needing this ECC/Reg ram and I don't want to hold it for no reason at all. They said they'd make an exception and appreciated the donation.

I looked around for a while and they had a tiny little box in the corner for $75 bucks, I asked them about a deal on it & they said wait a second. Went into the tech bay for a bit, then came out with a much newer version of the same box! Went from i5 to i7. They said since I had made a donation they'd just make this a really good deal if I was interested. So I snapped it up, got home, put an old Server 2012 R2 copy I had on it for giggles, spent hours running updates even though it was a blank server install with no additional roles added / installed. Finally I got to pretty much a blank screen with nothing but my network adapter enabled. Fired up XMR-Stak, 225-250 H/s!

Turned on the stat screen for the battery it's plugged into, 63W! If you add the laptop into this you have 375+ H/s at around 100W of use which is more hash then my cranked out i7-5930K is doing at 4.5ghz across 11 threads. (though it's also still being used as a daily machine) These are some extremely interesting numbers to me! Though for the ones you guys probably want to see more then this, I went test mode over 9000 on this EKWB loop the Titan is running on. (with plenty of screenshots) One screen I grabbed with Afterburner & Taskmanager is pretty amazing because I don't think you'll see a Titan X Pascal jacked that high again without going beyond water. If there is other overclockers out there that have three+ day long mines at higher rates then I can't imagine their setups.

I'm not saying it doesn't exist, I'm just saying, IMHO, this is the limit of pascal. I was even getting my nerves shaken a bit before finding the absolute limits. Enough you say, give us the numbers!! Well 2,240mhz which was consuming 61% power draw at 36C was when the system finally crashed. Which was not instant, I had music playing on the very system as I was doing this, not just for pleasure but listening for stutter or anything to say trouble was about.

After about five minutes at this speed the music stuttered, slowed, and then stopped. System locked. I also noticed that only at 2,240mhz did I see a 61% power draw on the bottom line pre and post mining jumps. Even at 2,225 it was 60% and the temp stayed 35C, but that last additional 15mhz was the straw that broke the camels back so to speak. Which is probably pretty insane to most of you out there, as it was pretty god damn shocking to me. Post reboot, the card is a little jank over 2200, you can't go right to that speed, you need to ease into it after a minute of mining. Also the system response goes to shit over 2200, so I've decided it's probably wise to keep the card at 2,175 for a little bit of a buffer & keeping the responsiveness nice.

That is an absolutely mine numbing pascal overclock (atleast to me personally) & keep in mind, as the screenshot shows, it was mining for three days at 2214 before I just pushed it to far with the 2240 request. Truly curiosity killing the cat. Didn't make a real difference compared to the stresses placed on the card.

The highest I saw it mine was 979 H/s, but it wasn't consistent an the card liked to mine at 965-970 most the time. Dropping the overclock from the balls to the walls limits of the damn card results in a slightly higher hash rate an a more stable system. If this loop wasn't pretty much always supplying room temp water to the GPU across a full block I don't think you could hit these speeds anyways, they're a wasted investment in the bigger picture of mining, nobody would do this. Though it's gotta be interesting to more people out there then just me! Feel like some LTT/J2C/GN video up in here taking the card that far.

So back on track, now I have, two personal machines, a laptop, & a little micro workstation mining Monero. My new combined hash rate post a week of dickery is 2,624 H/s. It's been higher, it's been lower, there's alot of drop when a user is on one of the two desktops with two 4K monitors needing to be powered by the cards as well.

You'll see the big numbers after a 12 hour stretch at night when nobody has touched them at all for a long time. Though outside of adding 63W for the new i7 the power usage has pretty much stayed the same. The Titan went from 59% power usage on normal boost clocks to 60% power usage where it's at today, the 1080 hasn't changed, & the cpus don't change really. The only downside was I woke up to a windows update kick in the nuts on the laptop once as I forgot to turn automation off.

So there you have it, just about a week into mining some Monero, still figuring things out, still achieving optimizations! Pictures to follow: The Xeon Box, Fresh Out Of Storage. Questions Answered: People asked, just what my electricity is costing me? Well my city works on a tiered system where the first 500 kWh is $0.09434 from Jun-Aug & $0.08893 from Sept-May. Then after that the next 500 kWh is $0.11268 - $0.09339. Then all juice after that is $0.14904 - $0.1033. There is also a fixed monthly charge of $6.14 regardless what time of the year it is.

Another question that was asked over Steam instead of a forum was, just how profitable are the laptop & mini station since they're purely CPU mining all the way here almost into September 2017. Well I went ahead and ran the calculator on that for you! A couple things to keep in mind is that this is including the donation to the developers (2%) & pool fees (0.5%) which I fully support. (I just added the dev time into the calc with more pool fees) Couldn't do it without them! Also this is at the current market rates today, live. I'm not really interested in selling this coin asap. Ol'Laptop Profits: (i7-3720QM across 7 threads inside Win 10 Pro).

Post Week Mining Updates: Well I posted a link to this in my mining pool's chat this morning, so hello everybody from US XMR! Everything is still chugging along great but it's been a pretty rough week for the pool I'm connected to. The news ticker on the front page talks about what's going on & I even saw the admin on reddit discussing the problems and how to fix them. I like that he's proactive like that & out in the community, it's a solid touch to the small pool vibe. Do not let this entire realm of troubles slip your mind if you're thinking of getting into mining.

Sometimes it's not your fault! Sometimes, your entire setup is running perfectly & your internet goes down or the mining pool has an issue. So you don't always get that constant 24/7/365 profit the calculators are predicting. I've also been balancing the gear I own, how to run it most effective, and how user impact effects the machines. To put this into perspective, when nobody is on any machines at all, the pool is showing my setup as popping up to 3.3-3.5 K/s. Though during the day I tank really hard, I took some screenies to show off this effect after a couple minutes of light user work on a single 4K display.

I also wanted to come do a video or in failure write a section about measuring power draw appropriately and to show off the 'mining spike' as I'm just calling it randomly here. (I'm completely unfamiliar enough that if there is a proper technical term for it, well, you're getting 'mining spike' instead) (mmmm some sexy deep technical analyst up in these posts) Though the video I shot was pretty bad & as soon as I bust out a decent camera to do anything my OCD will kick in & you guys will get a 20 minute YouTube video on my entire setup, the ins and outs, and how it all works. For as much time as I'd put into it, I'm not really sure anyone cares! But I'm still considering doing it just for the few folks out there that are searching out more information on the subject. What I'm talking about can be seen in my screenshots above inside Afterburner, see the power draw I always pulled up before taking the pics? Now see the spikes in the power? This does not happen on CPU mining it's purely a GPU related activity.

So when you're doing your power calculations, most the time you're going to see a readout of one number, the lower pre and post spike required juice. Though as it's picking up work, or doing whatever, you'll see a smaller climb, a peak, and then the climb back down. This isn't my field, I don't have writers, and honestly for the places I'm posting this information there is about a thousand better people to explain this in a technical manner. Though for the novice out there, I feel like I have some decent ability to show that off to those interested. The 5820K + 1080 box currently after the week of playing around runs 333w for the baseline & spikes to a peak of 381w after a couple minutes watching it, though the vast majority of the time it's at 333w. I can't even imagine what a shitty power supply on some questionable quality power thinks of this activity for weeks, months, years on end if you plugged in say four to six graphics cards all doing this. Which is not gear I own, I'd love to show it off to you but I simple don't have it.

The 5930K + Titan X (Pascal) box uses 396w all the time but spikes to a max of 477w after a couple mins spent watching the battery. Every other device I have doesn't flux at all, I plugged in each part of the network gear out of interest. The modem & router each take 20w & the pi-hole takes 5w. (just to give you all out there an idea of overhead) To be extra safe if you're going to do this for more then a giggle, I'd probably run my max numbers in my power calcs just to make sure you're not going to be sour at the end of each month thanks to the difference per series of spikes. See, you just turned that frown upside down, now you'll be pleasantly surprised each month! So let's talk about some additional changes.

I actually changed the venting system in my place to hit the rooms with mining gear in them alot harder then the rest of the place. Do not under estimate a mining rigs ability to output heat.

Sitting next to this titan box with two giant radiators pouring heat onto your legs will make you start to sweat. I also pulled the cool magnetic dust covers out to allow for greater airflow. I don't think it actually needs it, but it makes me feel better, and I'll just be more anal about cleaning it more regularly. Also I've become an absolute power nazi, I do an OCD check of my entire place to make sure things are turned off before I go anywhere or even to bed. I also turned my fridge and freezer down to 1/10 on the dial. The idea going through my head is, this is all combating the efforts of my mining rigs!

The more I output the more I'm damning my efforts. Though in the big picture as the world has let me know thanks to the powers of the internet, I'm pretty much in mining heaven, my power is free compared to many places of the world. So I guess it's just a bit of a hippie'sh power nazi vibe (is that a thing? Can I say that?) ontop of being in the golden land for power, that is driving my quests for squeezing more out of this operation. Because of this I overclocked my 5820K back up to 4.5ghz where it use to stand. Though for gaming, it really made no difference and you could run the fans lower 24/7 when it was only clocked at 4ghz.

Though, we're mining here, so back to 4.5 it went! As seen in the screenshots below, about 10 H/s.

Yeah I said that. Additional 500mhz overclock = 10 H/s gain on a i7-5820K. Whew talking big numbers here! Ultimately I hit a new high this morning on the Titan as well, I've not changed a single setting, it's still going though the temp is currently 33C across the card thanks to it just not being hot as hell outside. 982.7 H/s with much better averages, always staying in that 980-982 butterzone. Though after just a minute of being on this machine with a single 4K screen being turned on, just reading the forums, my rate dropped to 957.3 H/s!

A swift kick in the mining nuts & imagine the additional stress it's placing on the card as people flip stuff on an off all day. Though it's solid & stable, they never turn off or crash, the graphics drivers never freak out, it's pretty much easy sailing if I'd just stop playing around constantly trying to squeeze every last H/s out of them. 5820K @ 4.5ghz Mining Across 11 Threads: (compared to the 4ghz screenshot from above). Finding another 25 H/s via good tech work: Well spite what I said about needing to stop playing around with things, here in the post week mining phase, I'm still learning! I just pulled another 25 H/s out of the same equipment through nothing more then optimization.

Now the first 20 was gained through playing with the 'low_power_mode' option inside XMR-STAK-CPU. I had previously played around with this and found it to be heavily favoring 'false' mode on all my setups. To the point where if I turn it on the mini workstation, it'll go from 225 H/s to 150 H/s. The laptop takes a dive, as well the i7-5820K, though to be fair, it only goes down by about 5-10 H/s, not the huge dives from the other two machines. I was reading the official dev boards & a guy was on there talking about how he got much better results by turning the actual cores on 'false' though putting the hyper-threads on 'true'. This sounded interesting so I tried it. On every machine.

This resulted in the most fucked up hash rates I've gotten yet, though there was a golden nugget in the frustration. I tried all 'true' mode, which from the config file: 'This mode will double the cache usage, and double the single thread performance. It will consume much less power (as less cores are working), but will max out at around 80-85% of the maximum performance.' Which for whatever reason, this time around, on the i7-5930K, boosted me another 20 H/s stable, all the time 24/7.

So yeah, try every different machine you have across that setting, see how it treats you. The next 5 H/s is really nerdy and well, we're talking finding all the nooks and crannies here. So I was looking at the threaded mining rates on the CPUs across all the systems. They all seemed really stable minus my i7-5820K that I had recently brought back up to 4.5ghz from 4ghz just for the purpose of mining. As I reported in the previous posts before this one, I only saw a 10 H/s improvement doing so. Basically there would be a really high hash rate on a single thread while other ones would be really low. There wasn't the stabilization I was seeing on the other machines.

At first I wondered what it could be but then it hit me, maybe the machine wants more juice! Now this overclock passes all the tests I can throw at it, it benchmarks, torture tests, & games like a champion at 1.275 core voltage and 1.95 input voltage.

Though here I am looking at the thing throwing odd numbers at me in the reports while mining. So I went into the bios and tried 1.28 on the core and found my rates stabilized a little bit an went up 2 H/s. I went up to 1.29 and found it went up 4 H/s.

So I went up to 1.3 and it seemed to greatly stabilize the threaded numbers but only went 5 H/s above, or overall now 15 H/s gained from the 500mhz overclock, instead of the original 10 H/s. Goes to show that your system might not lock up on you, or even give you any problems, but your CPU might still be very hungry for power while mining! Now I'm sure I could try to hit 4.6ghz on the 5820K and probably 4.75ghz on the crazy loop the 5930K is on. Though I've always respected these processors and the boards they're on as holding up great at 4.5ghz all day and night. Anytime I've taken these past, into the realm beyond 4.5ghz, they've always gotten screwy and into power monger states where the amount of return you're getting is not justifiable by the amount of overall havoc you're causing. I mean sure, alot of people run these processors at 1.35 on the core but that makes me sweat a little to much even on high end water. The objective is make a couple bucks extra here, not toast my gear that cost an arm & leg to acquire already.

If you've read this entire thread then let me just say, I'm quite pleased with that 5 H/s gained. I feel most would've missed that, or not cared, but no sir, been a nerd for way to long & those numbers just looked wrong. Even to an XMR mining noob like myself. So there you have it, yet another 25 H/s pulled out of it. Though it's gotta be getting close to just maxed.

I'll let you guys know if I come up with any other hash rate increasing tricks or tips. Gaining 93.7 H/s through more overclocking! Okay now first I want to say, this is something I'm comfortable with doing but I'm on premium equipment. This is not something I'd recommend everybody run out and do, specifically if you're not thermally prepared. Back when X99 launched I was hyping machines I built for their ability to hit those high cache overclocks, pushing the NB and everything far beyond what is actually required to post high overclocks & get on the leader boards.

I caught ALOT of shit for doing this & most the popular guides specifically pointed out that high caches DID NOT help you score higher on the leaderboards, caused tremendous amount of stress on your system including heat through the additional juice required, and overall would not help you game / enjoy your computer anymore then avoiding these overclocks. Whatever, I did my thing for quite a long time. Though being honest, I did come across some situations where that higher cache overclocks created alot of stability issues. Specifically on lower end gear trying to achieve things out of it's class. Though after my last post I left my place & grabbed some coffee. I've not had caffeine in a hot minute so while it was hitting me I kept thinking about the day & my results I've been getting. Mining is a different scenario on equipment then gaming by a long shot.

The cache bragging I was doing back in the day, might hold true here. Maybe hopping the whole system up and eating the increased power it takes would improve my hash rates. Finally I could point at the overclockers fan bois who just read forums all the time with no technical expertise and say, look, there is a reason for this guys, it's not just about benchmark software & will it run crisis. Whatever) So yeah, I headed home, turned off my 5820K rig, jacked it's cache up to 4ghz and turned it back on. CPU hash rates through the roof! I wish you guys could've seen my smile.

Turned it off, jacked it up to 4.5ghz, which is mind you, a pretty ridiculous overclock, I went to stress this, and my machine booted into Windows 10 Pro. Then as soon as I double-clicked the miner it locked up. I rebooted, went in and changed my cache voltage from 1.20 to 1.25. So to be clear, I'm running core 1.3, cache 1.25, with an input voltage of 1.95. Fired the machine up, wham 363.6 H/s. Now that is an improvement. Keep in mind I've got one thread that is just running windows in the background while managing the system & all the networking, vpn, security, etc.

It's not like I can really give that thread up, but if I could, this 5820K would be pushing 390ish H/s. I think that's pretty major, I looked at that & thought, damn that's kicking my 5930K's ass now!! Which leads to my next move, running over, shutting down the Titan rig, and booting it up with the same exact voltages, same cache overclocks, just a slightly higher system agent voltage. Get into Windows 10 Pro, flip on the mining after everything else boots up, and what do you know it's pushing 382.8 H/s!!

Once again, one thread is running the system but if it wasn't this CPU would be doing 410ish H/s. Also pretty impressive to me, though I'm just a novice in this area. For those wanting easier stats, that's a 45.2 H/s gain on the 5820K and a 48.5 H/s gain on the 5930K! Given I just wrote a lengthy post about how I squeezed 25 extra H/s out of things, this is a pretty massive improvement. Both systems have been up for a little over an hour now with the new overclocks in place, mining their ass off.

Though once again, I want to stress, this is some shit to do to a computer. Be prepared for this not to go so easy or friendly. I've got everything on batteries, there's no quality lacking, and this is not a traditional mining setup, this is a gaming and studio workstation that I'm playing around with. 5820K @ 4.5ghz Core / 4.5ghz Cache Mining w/ 11 Threads: (inside Windows 10 Pro). Post Cache Overclock Notes: Well gents (and ladies!) I did say, and I quote (myself); 'Though once again, I want to stress, this is some shit to do to a computer.

Be prepared for this not to go so easy or friendly.' Even on what I consider to be pretty decent gear the jump up to dual 4.5ghz overclocks on each machine did result in mass downtime. Not because anything broke or was damaged, but because I'm not 24/7 watching the entire setup & haven't scripted email alerts into all this yet. The 5820K would mine just fine for 2-3 hours then out of no where just lockup, same type of lockup you see when your processor is starving for more juice & just can't get enough to do what it wants.

I went in and changed the cache voltage up to 1.275 and it once again, after a couple hours in, froze. I was actually sleeping when this one hit so an email wouldn't have waken me up anyways. As soon as I noticed I rebooted the box, increased it's cache voltage up to 1.3 and then also increased it's system agent voltage by 0.05. This has resulted in a completely stable machine for the last eight hours or so mining at the higher hash rates though the heat output has also gone up (as expected) and I can't imagine the system loves that 1.3 cache voltage, that's as far as I'm concerned, some saucy shit.

The CPU clock was stable before playing with the cache, as well the graphics card, so I didn't want to touch much else in an attempt to stabilize it. Overall, unless something changes, that's going to be where it sits as I'm completely out of ideas on how to improve that hashing rate anymore without just going to a linux environment.

If anyone out there has ideas, hit me up & I'll research them. The 5930K on the other hand experienced a completely different problem! All a sudden the Titan didn't want to stay mining, it would just randomly after 3-4-5 hours turn off, which then leaves afterburner with some jacked settings which confuses the piss out of the drivers, and system stability goes down. Given the only thing we've changed here was the meaty cache overclock I went into the bios and actually decreased the system agent voltage as I was fearing it might have been a bit to high. This did not fix the issue but it not harm the system either so anytime you can turn down voltage, that's pretty solid. I was watching afterburner for a while and noticed it had naturally turned it's boost clock down another 25 mhz on it's own after the cache overclock.

I went ahead and did both, boosting it another 25 & dropping the overclock by 25 so I could observe the system's characteristics each way. +25 and the miner would close, so driving it harder was not the key here. -25 and it's never crashed since then. Showing that at the higher overclocks we've got going on, the titan is responding by saying, nope, things where fine but now they're a little different. The funny thing is, the only difference I'm seeing in this trade off is around 0.5 H/s. I mean, yeah I could've went in and played with my bios and tried juicing things some more until it stayed at it's previous setting but we've got a stable double 4.5ghz overclock going on here, losing 25 mhz of overclock on a Titan that's off in the land of 'what the fuck is going on' really doesn't mean anything when placed next to achieving long term stability.

I mean really, it's 0.5 H/s. Even a guy like me who just wrote a damn book on getting into XMR isn't sweating half a hash a second in this type of sitch. Okay so there you have it. I hope how I handled those issues & how I've handled this thread in general helps some of you out there. I'd love to hear that some of these more specific tech oriented tricks where used to help somebody else out there improve their own mining efforts. If anything, I hope this thread serves as like an 'Introduction to Mining' guide or maybe more an 'XMR Mining 101' micro blog for new comers or even outsiders to better understand the struggles, background activities, and in general knowledge you might consider useful to have a grasp on before moving into this industry.

I'm not even making more then $150-200 a month with my play toys here, imagine real miners stacking rooms of gpus or high end server farms with outdoor water tower cooling that's fins get automatically sprayed. I'd love to set that type of stuff up and play around all day, but think about the technical knowledge required. Sometimes I'm very conflicted while thinking about the mining craze. It has the image that people all over the place are just slapping their gaming boxes up on the pools and making millions, no technical skill required, or effort really!

Though look what I've just created, if this thread's wall of text factor hit any harder your eyes would be red! (that's a post legalization cannabis joke, was cached but I still tried) When I was at the surplus store there was a kid in there who had his arms full of $2-3 graphics cards from waaaay back, I said jokingly, 'what are you mining or something?' And he said 'yeah man uhh 2-3 bucks a pop, going to earn me a free beer every once in a while' and he walked off. These where all different types of cards, a bunch of PCI, a ton of AGP, a couple PCI Express, fuck he might have had an ISA in there that wasn't even video related, this guy had no idea wtf he had.

He walked right past the FirePro cards in the glass case that where $7 each and bought out like twenty cards that are tits useless. I mean this is my competition? No, this is a common misunderstanding, yet another public relations problem the crypto currency industry faces, specifically related to the mining side of it. Okay okay I'm sure nobody came here to read my thoughts on mining PR issues. Just going to keep it semi-technical, long winded, & as educational as possible. That's how you do it. You Stuck Your Hacker In My Mining Pool: Where's all the profits guys?!

Remember a couple posts ago where I was talking about how sometimes things go wrong that are simply out of your control? My pool I'm connected to, along with a bunch of others, have been under constant attack from DDOS to customized exploits. The difficulty curve on XMR has grown alot in a very short period of time as it's achieved popularity.

This means that massive mining farms that are now coping with the new difficulty are resorting to other techniques for achieving profits. At one point I saw the global mining rate had tanked and looking for explanation basically went to the chat rooms and forums for the pool operators.

The big pools, that charge a much higher fee for operation are chugging along just fine, actually, making a killing because the climbing difficulty curve just smoothed out as all the other pools around them stopped operating. Not only that, it's a domino effect, the longer they can keep other pools from working the more and more miners will swap fully over to the larger pools in order to continue making money, while just eating the large fees they're paying to the pool owners. So if you can drain a pool of it's money, equipment cycles, admin time, and finally the actual miners themselves who fundamentally build the pool then you'll crash them. It brings alot of control, profits, and dominance across XMR back into the hands of the few.

When I first started getting into this and started this thread in order to hopefully inspire other people to jump into mining, the pools where all under DDOS. There's a note on the front page of US XMR about it but you can find much better discussion elsewhere.

Then as of the last day or so, there's an exploit ramping the actual pool server software to 100% CPU usage without needing all the machines targeting them like in a ddos. This is actually working great because admins are racking their brains out trying to figure out how it's happening meanwhile all of us miners have boxes sitting around just throwing errors because even if it can connect to the pool, it's to busy to give us any work or for us to return work. Don't underestimate the volatility of working with crypto currency.

Three hours into this new attack people where already calling the smaller pools dead and a waste of everybodies time to continue on them, citing the ddos attacks before these as proof people needed to step up to bigger and badder networked pools that can handle such attacks. No doubt most of this was just posted by the people actually doing the attack themselves as a way of getting more damage out of their efforts, but it works. Keep in mind, I'm some guy with two single gpu desktops, a laptop, and a micro station. To other people this is a huuuge business and cheap darkweb hackers are a damn effective tool.

What are all these pool operators around the world going to do? Trace them across the darknet and then sue them in real life? No you just fix the exploits, beef up your gear, prepare yourself as much as you can, an keep going. Which means this is problem that I'm predicting won't go away anytime soon. Which out of my short time playing around in the industry has actually resulted in a very considerable amount of down time. If I had more gear or even a light investment into mining I'd have left my pool minutes after the attacks started. That's what makes them so effective, people who do this for a living or who are serious about it just go 'oh well that pool/coin sucks, on to the next one so I can keep my money train going' which leaves smaller pool operators in a hell of a spot.

I've been reading what Frost Monkey the admin of the US XMR pool has been going through and it's a nightmare when you have a bunch of people on the other side of the attack going 'hey what's going on, why aren't we making money, hey tell me stuff, like now or i'm leaving, okay i'm gone, peace out bitches' all before anyone really has time to even read it over the more serious issues that are occurring. Anyways, there's some perspective for you this day on the mining industry! Everybody go thank and tip their pool operators for keeping things going for us! Gaining 100+ H/s Through Prefetch Optimization: I think on the developer forums I might have misread what a guy was getting at the other day because now I'm seeing gains through playing with the prefetch settings inside XMR-STAK-CPU.

Previously I've said that the 5930K gained 20 H/s changing everything to 'low_power_mode' 'true', though it only worked on this one box, the rest of them did not see a gain but infact a loss by changing that. Though tonight while playing around I found that across all my mining rigs, no exceptions, it was more valuable to actually change all the threads to 'low_power_mode' 'false' then go into the 'no_prefetch' settings and change it from the default of 'true' to 'false' across all the real cores while leaving it as 'true' on the hypers. This actually gives a huge performance gain! I got around a 25 H/s gain across all the machines!

For instance, the 5820K went from 363.5 to 388.8 or a 25.3 H/s improvement! What happens now when I watch the threads is the hypers get a much lower hash rate but the original cores go higher, enough that we see a net gain through the trade. I had a good friend of mine duplicate this on his machines and he had almost the exact same results. We found this very interesting. Anyways thought I would share the discovery so other people could also test these results on their rigs.

Example Of Config File Post Change. Building a Mining Load Balancer & Proxy through Virtualization w/ Hyper-V: I've been trying to give you guys little factoids or interesting nuggets every day over the last two weeks, though there's a limited amount of expansion I can do with the amount of equipment I actually own. Without starting a pool, working for one, or finding a job somewhere in the industry what's really left is just buying more equipment & configuring it in new ways. Which is why I've now setup XMR-Node-Proxy which; 'allows you to manage and direct your workers in an efficient manner. The proxy will provide several improvements over currently available solutions like atrides proxy or HAproxy deployments.

Biggest improvement will be without a doubt the ability to split the requested work to individual miners. That means unlike other solutions, it will appear to the pool as a single miner requesting work at normal rate, but at the cumulative difficulty the miners connected to the backend are capable of. This not only potentially reduces the load on the pool servers dramatically, but also allows for more efficient mining.

First tests have shown a dramatic increase of hashrate especially with low hashrate miners.' Everything I've read about this says it's designed to be used with like 10+ low end mining threads that you need to boost into one acceptable thread. I may only have six threads here (2 gpu + 4 cpu) but I really love this idea completely. So I grabbed a copy of Ubuntu 16.04 LTS minimal install an off to the races I went. Now there's decent guides out there for building this into a free or $5 a year amazon cloud but I really dislike getting away from my own gear that I have access to here locally. Soooo I thought you know I have that single hyper thread (not even a real core, lol) left that is running Windows 10 Pro, a VPN, Steam, and generally a user throughout the day using a browser or listening to music.

That really only takes about half of that hyper thread. Can we sneak an entire linux OS ontop of that in the half a hyper thread remaining?

In short, yes. So I opened up Hyper-V Manager, started a new machine up, gave it one core, 10gigs of ram, and created a network switch that I dedicated the second gigabit adapter on my motherboard to specifically. Ran another cat6 cable over from the router & plugged it in, which after a pretty lengthy install for a basic linux box was downloading all the newest updates and installing the mining proxy. What I really like about this situation is I now have a single status screen that I can watch which will tell me my current global hash rate. It also allows me to manually dial in minimum and maximum difficulty rates that I'm wanting to push across my devices. I can swap pools automatically, open different ports for different pools for different difficulty levels, I mean there's some neat shit going on here. They ask for a 1% donation rate themselves, so between the 2% on your CPUs, 1% on your GPUs, 0.5-1.5% pool fee, this is yet another 1% to eat.

Though it's pretty cool software, so it's got that going on for it. I spent a long time trying to get it to work with my current pool that I've been mining on for the last two weeks but nothing I did would jive. What Is Minimum Investment In LBRY Credits LBC on this page.

All I'd get is a shitload of errors and problems. I swapped over to the supportXMR pool and it worked first try. I took some screenshots along the way though I lost one really badass multiple day uptime shot with steam in the background installing a game as well. I needed to do some maintenance on this water loop & had taken the screenshot, pasted it into irfanview, then forgotten to actually save it before shutting down.

Anyways, I really wanted to show off just how much you can get away with on a single hyper thread!! So in another one of the pics I even dragged my mp3 player over to show off how much was being done on thread 11 without any issues, stalls, or even hiccups. (both to the mining and my general use of the machine) System stability is always the greatest importance, never forget that when setting up your machines and getting into those overclocks!

Installing Ubuntu While Mining & Multitasking Across a Single Thread. Optimal Load Balancer Configuration Woes + Gaining Hash Rate Through Difficulty Curving: (aka: setting up speed racer mining) Well with this morning's I'm sure everybody is interested in picking up some new ideas on improving your hash rate. Thankfully I've been spending an embarrassing amount of time playing around with XMR-Node-Proxy and finally have alot to say about it. Now once again, I want to state, I'm not a programmer here, I don't understand mining at some intense level, and what you're getting is a guy utilizing his available time to fumble fuck results into place. Anyone more technically capable of laying down a proper and I do mean in-depth understanding of everything going on is MORE THEN WELCOME TO (and I do encourage it) come in and lay down some major information on not only what I'm saying but their own optimizations. What I really care about is bringing you all empirical data showing success, proving their is optimization to be had. Honestly for most of the last five days I've been doubting that was the case with my small amount of power I have vs.

What XMR-Node-Proxy was designed for. Though I can finally say, yes, it is worth your time using, even on the home mining front! 'Step 1' so to speak would be figuring out your load balancer's 'shareTargetTime' optimal setting for the port difficulty you're connecting too.

This is done by dividing the difficulty rating by your peak hash rate across your equipment. That's essentially what it considers to be a broad but semi-accurate starting value for the load balancing effect to start working with. EXAMPLE: You connect to a port of 25000 difficulty, you hash at 1.3 KH/s across your home, =19.2308 shareTargetTime. Through doing this and just connecting my entire home's mining operation to the balancer I saw a peak hate rate (reported on pool and verified) of 3.8 KH/s though it would still ball out low to 2 KH/s at times. So the high's where better, but the bouncing between the peaks was still rough & very much present all the time. The stabilization I was hoping for was nonexistent. The problem you'll run into as soon as you look at your default config file is it's designed to be setup where you can open multiple difficulty ports on your own proxy & it'll balance the unit it's grabbing from the pool based on what you connect.

Well the question is then, like, there's only one 'shareTargetTime' so which port and which difficulty do I optimize my timing for? So some of you might do what I did for a couple days, which was really dumb, an that was try every possible combination of difficulty changing on my side, then stacking different share times on top of whatever seemed to make a difference after 15 minutes of being left alone. (this is where the hours and hours and hours have been wasted) Also let me step back a second in case somebody missed the boat on finding what type of hash rate to expect to even type into your load balancer in the first place. Fire up WHATEVER mining program you like, as you can read I'm big on using STAK's stuff right now. Make all your overclocks, system tweaks, etc. There, before you ever even have the idea of XMR-Node-Proxy in your mind. Once you've got a setup that is stable 24/7, no crashes, no issues, look at your peak & 15 minute average hash rates.

Write them down, add them up across your gear, now you have your normal rate to expect (the 15 min average) and the peak your gear is going to pull when everything's coming up milhouse. Okay so now back on track, you've got a load balancer that is giving you new high peaks but brutal lows, and you can't figure out how to optimize your shareTargetTime for the different difficulty ports you're setting up. Well from what I can find online, most people do not care about it. They leave it at the default setting of 15 or even increase it to 30 depending on the latency timing of all their remote miners who are connecting to the proxy. Though as I'm complaining about, the peaks to valley ratio sucks doing this on my personal gear. I think it's because it was designed to run 10-2500 low end cpu connections and get a better rate through distributing the work load better.

Not four mid range to high end CPUs & two graphics cards, one being an unreasonable beast like the titan. It throws the whole balancing element out of wack, or atleast, it appears to me it does, I'm guessing there is some trouble always lining up the process for this unique split. 'Step 2' is creating multiple load balancers depending on how far off your gear is from each other. I've simply made two balancers running, one for my CPUs, another for my GPUs. Then the difficulty & port settings are stripped down to a single port, a single difficulty, and a single shareTargetTime for each load balancer, no flipping around between them, no splitting loads between pools or ports, just straight up one road back and forth.

To do this, go into your hyper-ubuntu, open up terminal where you run pm2 monit to watch it work, hit ctrl-c to close it if you still have it up and running. Then type 'pm2 stop proxy', followed by 'pm2 delete proxy' to get rid of your current running setup. Then, reconfigure your config.json file to reflect the equipment you're trying to separate out.

(cpus or gpus in this case) Once you've got a single port config ready to go head back to your terminal and repeat the process you did for firing it up the first time. This is 'pm2 start proxy.js --name=NAME OF YOUR FARM --log-date-format='DD-MM-YYYY HH:mm Z' for anyone who might currently have some wings like I do. Though you can see the new 'NAME OF YOUR FARM' part.

Here is where you're going to want to say 'PimpDaddy_GPUs_Only' or whatever you like. It's gotta be different then the next one we're setting up though. Follow this up with the same old 'pm2 save' afterwards to make sure we're good. Next copy and past the xmr-node-proxy folder in it's same location, it'll give you 'xmr-node-proxy (copy)' as a folder. You can rename this 'xmr-node-proxy2' or whatever you like. Now go into this folder and change the config.json to reflect your other shareTargetTime you'd like to achieve with the other side of the now separated hardware.

Once you've got it ready to go head back to your terminal and 'cd ~/xmr-node-proxy2/' into your new folder. (obviously, change name to reflect whatever you named it). Here we repeat the same process from above but give it a different name, so another 'pm2 start proxy.js --name=NAME OF YOUR SECOND FARM --log-date-format='DD-MM-YYYY HH:mm Z' followed by another 'pm2 save'. Boom, type 'pm2 monit' to get your back into your basic monitoring screen & now you'll have two load balancers running but reporting to the same global logs screen.

You can see this in my screenshots below. Which leads us to 'Step 3' which is another very long round of optimization of your two load balancers to achieve a sustained mining rate higher then what your gear would do on it's own without all this fuss. So I'm sure you're asking, how is this done? Well now that you've got two balancers running on your half a hyper thread (lulz) you can watch the stats popping up inside pm2 monit's dashboard. Once it's dialed in (let it run for 15-30-60 min tests) on an average difficulty that is achieving your equipments hash rate pre-loadbalancer look at what it's working with for difficulty across your machines.

Go back to your actual mining software prompts and watch for it's difficulty to change. When you look at all your machines you'll see the lowest difficulty and the highest that it's using to achieve that average in the load balancer's dashboard. Then you can go into your config files and change the min and max difficulty to be a couple hundred in either direction. With your advertised port difficulty to your machines starting where the load balancer has finally taken you after letting it sit for a while figuring out what's best.

Now you can fire your load balancers up again & see that it's taking your gear almost right to the hash rates you where getting an hour into your testing instead of the way off hash rates you got the first time you fired it up. (pre-dialing in phase) The next step is really, and I'm sorry I don't have a better explanation or technical breakdown for you, but is simply playing with your shareTargetTime, VERY SLIGHTLY, and letting it sit for 15-30-60 min stretches while you record the results. Eventually you'll see going one way will help, one way will hurt, and going to far either way will wreck your rates. Finally you'll get to a place where your gear is actually running above the hash rate it would achieve on it's own through the load balancers act of splitting blocks down into individual segments for your gear to rip through. That's called success baby and we all fucking love it. Though you're going to notice the same peak to valley system happening still, even post all this nonsense. That's the nature of the beast with mining, but what you're trying to do here is pull the valley's up to form a new higher minimum hash rate over time & to increase the peaks, climbing higher & faster through this splitting of the work.

Let's talk some real numbers, I'm still testing many theories I have on how this all works, I could've held back this post for another week easily. (but I wanted to get something out there for people to absorb and possibly bounce ideas back at me) I've currently seeing a minimum hash rate improvement of 500 H/s average during daily rate with people flipping on and off the machines. The dips use to shoot down to 2 KH/s at the worse times & now they only go down to around 2.5 KH/s during the falls. (once again, normally, on average, we're not talking always, it's not an absolute) While my peaks, they've gone mad. I hit 3.3 KH/s alot more often then I use to and I even saw a peak of 3.8 KH/s yesterday while I was playing around. (though I've not been able to reproduce this, ever) My equipment does a 15 min combined average of 2.65-2.7 KH/s when it's not on the load balancer so the objective is to tweak it to do better then that across the same 15-30-60m measurements. This also has a couple nice benefits, example would be when your miners go to their donation cycle.

Instead of just dropping the work all together, then reconnecting to it later, or just getting new work later, the mining you're doing doesn't stop as the other miners connected are going to immediately shift over to pickup the leftover work. So your average goes down a little bit on the charts (dips) but you quickly recover when whatever miner left, reconnects to your node again. It's fairly notable on the charts when the Titan X (P) drops off the GPU load balancer and just leaves the 1080 hanging yet the average hash over the day is still higher then just letting the two gpu's do their own thing connecting to the pool directly. Which after you've finally done all this, if you're like me, just won't be enough and you won't stop tinkering around. Which takes us to 'Step 4' noting that when you play around with the settings of the load balancer & get some craaazy results, they do not report to your mining pool accurately at all!

So example, I can get this whole place up to a reported 8 KH/s in the load balancer. All the machines are working hard as ever, heat pouring out of them, energy getting used, nothing changes on my mining clients, but the load balancer is going bonkers. (try dialing in high difficulties) THIS DOES NOT MEAN your pool is accepting all those results, or any of them. Often when I get crazy high numbers in the load balancer I'm getting terrible numbers reported as accepted by the actual pool. Given those are the people who pay you, if they're not counting it, it doesn't matter. So I just open up my account inside my pool & watch the double load balancers report in there. I only use their graphs, their charts, their reports, to verify if what I'm doing in the load balancers makes any dick of a difference at all.

Because the numbers in the load balancer are either 1.) lying 2.) hashing an incredible fuck rate of bad or unsuable data. You absolutely have to use your pool as your measurement for success. I basically just carry my phone around with me everywhere and every time I report back a block it tells me my current hash rate and my averages. I can tell pretty quickly if I've missed the mark with some radical setting I'm trying out or not but I like to let them run for a while to make sure it's not just some fluke. (proper testing time guys, let them run) So then you gotta be asking me, what has made a difference? Well it's speed racer low difficulty all day. I don't know if that's because my whole place is wired for gig and I have actual gig internet with an average latency of 5-10ms but for me, SPEED RACER ALL DAY.

I've got my shareTargetTime's cranked down to 1.5 & 3 seconds. They crank ultra low difficulty work all day but they fly through it just constantly spamming results back and forth between the pool & my load balancers. This seems to do about the best of everything I want, it minimizes dips when they occur, it brings the lower floor (valleys) up a considerable amount, & it tends to consistently provide hash rates that are higher then my gear does on it's own without the balancers. PERSPECTIVE, my titan was pulling like 50,000 difficulty work off the pool all the time on it's own, and crunching through it no problem. (though it took some time) Though now at this moment of typing it's speed racer burning through 1450 difficulty results like a crack addict with a brand new eight ball. Shit is on fire the console log is just a spam of results getting reported. THIS is what is getting me better averages then anything else I've tried.

The global logs in the load balancer dashboard is actually accurately reporting hash rates that are right next to what I'd get without the balancers (so I know that's working) but the rate I'm getting from the pool on my results is better overall. So once again, don't rely on the numbers inside your load balancer for anything but a basic check to see if they're in the correct ball park at all. Fine tuning needs to be done from your pool back to your balancers, not your balancers to the pool.

Here's another BIG TIP, no not make a hyper-v checkpoint in the middle of mining & then revert to it later on with your internet still enabled. It'll pick back up where it was when you saved (obviously), error the fuck out for a bit, throw some flags, and you'll get an invalid share from the pool over your previous work. I've never had an invalid share in my short but now gaining some time mining career / life, so I was really upset when I saw one pop up. So yeah, do not do that, going to cost you a share! (currently on this new pool, I have 83,982 valid shares to my 1 invalid share, but still, pisses me off to see the big red X on the stats screen with a 1 next to it) I'm not giving up yet, I'm convinced I can fine tune this thing myself into better hash rates.

I think I've just not done a proper job testing this in a scientific manner nor applied enough time across each measurement to really find optimal results over luck & the natural mining cycle. I'll be sure to let you guys know what I find in the future as I'm clearly not going to stop playing around with it until I'm pretty dead nuts that I'm getting the best out of my gear that's possible. Though let's keep in mind, this software isn't even developed for this use. From the author himself, it's not worth running if you don't have atleast 10 miners connected to it. Though I'd like to say I've provided some interesting results showing it is actually still handy to home miners like myself.

99% of people probably don't give two shits for how long this explanation has been & the required dialing in time. Though I know there's going to be somebody out there who is going to read this and be like FUCK YEAH IMPROVED RESULTS! And will join me on the load balancer quest for optimization and efficiency. Load Balancer Failure!

AKA: when things go wrong & you're not around. Bro, you been mining wrong for weeks: So this morning I joined the SupportXMR chat room, dropped the link to this thread, and said, hey new comers this might be helpful / if you're an expert please come school me. At which within about three minutes, the admin endor came in & said 'well you've got your mining configs all jacked up so that's a good place to start'. Which after this much time made me go lol wut. Then he gave me a very polite & technical breakdown of why I'm a god damn noob.

To sum-up what I've learned this morning: each mining thread you launch is going to consume 2MB of cache. My i7-5930K has 15MB L3 Cache, so it can handle 7 mining threads before only having a single meg left. Which isn't enough for another mining thread without gimping it, but could be left to help out with the OS overhead / load balancers. Which means, I've been getting poor hash rates out of my CPUs this entire time because they're dicking each other for cache no matter how fast I've got them going. It also means, that I see vastly improved hash rates using 7 threads (6c/1h) then I do using 11 threads with my previous (6c/5h) setup. This is running them all in 'low_power_mode': false & 'no_prefetch': false.

We discussed the differences in utilizing the cache through the low_power_mode since it doubles down on it. This would be handy if you needed to save threads for other activities but still wanted to use the cache. Though big picture time, when people sit down to use these machines during the day they now have five open threads instead of whatever is left of the remaining one post double load balancers. This has been a wonderful morning for my own advancement in understanding & has shown immediate positive results. So yeah, get educated.

I'd like to toss a big thank you out to endor for all his time this morning, plus all the other folks who helped out inside. Very friendly place, great community, with an active chat! Questions Round II? Round Something! How do I properly setup my GPU inside XMR-STAK-NVIDIA? Well after getting wrecked this morning on my CPU config this is a great question. (asked via steam) So when you look at your config file you're going to see; index, threads, blocks, bfactor, bsleep, & affine_to_cpu.

Now the first one index, that's simply which GPU you're configuring. Also the last one, affine_to_cpu you'll want to turn on if you're also CPU mining on the same machine.

Now it's the next four inbetween that are fun. To figure out your threads, what you're actually looking for is your graphics card SM value or the number of 'streaming multiprocessors' it has. Now this can be done simply by going to google and typing in your card and bam you're going to find reviews talking about how many SMs it's packing. OR if you want to be technical and not trust people, then go to google and search for your graphics card's 'block diagram' where you can physically count them. Which is not a bad idea because outside of testing random variables (which I do actually suggest next) you're going to need this to find your card's specific 'block' value now that you know your thread value. This is done by looking at your block diagram & counting the clusters per streaming multiprocessor. Though this is a bitch & you can type in 60, 100, 150, 200, etc.

And quickly find a few things. 1.) what crashes the miner asap 2.) what gives you the highest 10 second hash rate for the ones that do fire up.

It'll take no time at all to dial this in & the real number has never once matched my most optimal setting. So a little bit of experimentation goes a long way here! ALSO NOTE, this will greatly change how your card is using power during the mining. Kick open afterburner or your favorite tool & watch your power consumption charts as you change these & play around. The next two settings, are simply for how much system lag you want if you're using an OS with a GUI installed like Windows.

Bfactor of 8 and bsleep of 100 is the recommended settings for keeping a somewhat usable machine. Though I think alot of people would prefer a much more responsive system & would recommend dialing bfactor back to 10, or even more, until you find the level of responsiveness you can tolerate while it mines in the background. In my experience, bfactor is much more taxing then bsleep, all my machines can run bsleep at 0 and it's the same as if I run it at 100. Though that's just my equipment, so your mileage may vary. I know on my buddies 3770K/660 system he runs bfactor of 14, sleep of 100, before it feels normal to his family. Anyways, that's how you get the proper settings for your graphics cards for XMR-STAK-NVIDIA. Which is handy information to have & I hope that helped some of you out there.

Power Usage Vs. Temperature: Hey everybody! I've been sitting in the SupportXMR chatango pretty much 24/7 chatting up the good folks over there while attempting to help other newcomers as well. Gotta say once again very good community there if you need a hand & can be a polite individual. Anyways, I grabbed a screenshot this morning while I was enjoying my coffee that I found really interesting & thought I'd share. So once again on the 'nobody would buy this gear for mining' front, I'm running this Titan across an EKWB 480mm radiator from their extreme line that is extra thick.

It has eight vardar 3K's in push/pull on it & an extra high performance pump to keep those flow rates up. That's how I've been posting these insane temp & overclock screenshots for you all. Though I had left my window open over the night to let out the mining heat, and as it's getting towards late September it got chilly last night. So much so I was sipping my coffee & noticed as I was going through my morning checklist that my titan was mining at 27C!! That's uuhh 80F!!

I could've turned up the overclocks at this point but given it's already daylight out it's just going to get warmer. Though the thing that caught my eye was the power consumption dropped by 3% on the baseline from 60% while mining to 57%. That's ridiculous & very very cool to notice. If only I was up in the middle of the night when it got the coldest out, I gotta wonder what it was crunching at in terms of efficiency.

I'll be sure to keep an eye on this in the future & report back any other interesting observations. Also I want to note, have more posts coming, just want to make sure I'm technically correct before misleading anyone at all.

I worry anytime I advise people in this field that I've not got the credentials behind my name. So taking a bit of a gap between posts to learn myself, get better educated, and bring back more valuable content for everybody. 3% Power Reduction while Mining by going from 35C to 27C. Gaining Additional Hash Rate & Stability Through Affinity Configuration: So I was sitting in the Support XMR chat room lurking as people discussed various tricks they where using to mine on a range of different equipment. I was also chatting over steam with an Arsian who has been bouncing configs back and forth with me through this whole dive into mining.

I was telling him this morning how it was really interesting you could make a single core use twice the cache through low_power_mode but I couldn't double dip on my threads per cached miner. If you haven't laughed already don't feel bad because it took me a minute + reading other peoples random chat to figure out I'm a big dumbass. Of course I can do that, though I have to trust my operating system to see how well it handles it. This would be done by removing affinity to any specific thread. Which mind you, most the guides and notes I've found have advised against doing. Even going as far as saying you need to affine directly per mining thread if you where going to toss gpus into the mix as well since they don't play nicely.

PERSPECTIVE, if you've not joined along down the entire journey of this thread so far. I originally was splitting my CPU's L3 cache among all my threads but one left for OS overhead, meaning for example on my i7-5930k I was using 15 MB of L3 across 11 4.6ghz threads. I even configured it a bunch of different ways and tested them extensively as you can read above.

Then I got educated that given each thread required 2MB of L3 you would benefit from only running however many you can stack fully into your L3. Which in this case would be 15/2=7 fully enabled mining threads. Which is great because I did actually see an improvement in hash rate configuring the CPU correctly.

(lulz gents) It also left five threads open for people to use as they sat down at the computer throughout the day instead of just being left with one. Good deal all around. Though with the thought to remove affinity that would hopefully spread the same mining load using 14MB of L3 across 12 4.6ghz threads instead of the 7 I'm currently limiting them too. Would it work this way? I sure as fuck hoped so but I wasn't sure Windows was up to the task. It seems to work that way atleast within my limited testing with Windows 10 Pro and Server 2012 R2.

So, once again, this will divide your mining load across your leftover cores which will shred your machine. Just like when I was originally running it into the ground with to many mining threads. The difference is the L3 cache is now getting used properly this time around. Well what happens? My CPU mining rates are instantly almost up to their peaks and respond to userloads on the machines extremely quickly.

The latency between bad performance when they're watching youtube and good performance the second they stop and are reading their email is much much shorter then before. I mean clearly you can go into resource monitor and watch it working all your threads again, it's a big difference. Though this also works for the video card, removing it's affinity and letting it get managed by windows is also greatly enhancing their response timing to outside stress factors. (though I only have single gpu boxes here, I have no idea what this would do across a quad or more gpu setup) Both my i7-5820K @ 4.5ghz and my i7-5930K @ 4.6ghz are pulling 500+ H/s in this setup using seven mining threads utilizing 14MB of the cache but spread across the twelve threads of the processor. I mean huge thumbs up on the continued tweaking of the same exact gear from when I started. I'm really learning alot here, most of which should have been obvious, though if anything this thread can stand as a proving grounds for others to come & not feel as bad. If I'm making these mistakes there must be others out there doing the same.

I also want to note that I fixed a configuration error today when I was testing this concept. My laptop while being the same i7-3770 series as the mini workstation actually has 2MB less L3, so I've been over working it this entire time still!!

I dropped it to three mining threads instead of the four I had turned on & it's hashing rate immediately went up again, yeah because surprise like the others it's now properly configured. Then once again, flipping it's three mining threads to be spread across it's eight total threads through lack of affinity settings saw another improvement in hashrate. So yes, you can do that, you always could, I'm just a noob who looked right past it in the settings.

Getting Your Feet Wet In Monero, Starter Edition: Okay everybody so there's alot of sources I've been using to get through my introduction to Monero. I thought instead of just tossing helpful advice in this thread I'd also give you guys a breakdown of the places I've been using.

Keep in mind there is ALOT MORE OUT THERE then this, but these are the places & pieces of software I particularly like or have found useful. Official Website: - This is the starting grounds for all things Monero. If you want to learn more, find software, or just see who's behind things. Official Monero Forums: - The natural extension of the above website, these are the official community forums for everything from PR to Dev. Official Offline Wallet Installers: - Download a wallet to receive/hold/spend your XMR from that is stored & protected locally on your machine. 3rd Party Online Wallet: - An online only wallet to receive/hold/spend your XMR from that is stored & protected in the cloud.

Monero Coin & Market News: - This is a great source of news for all things Monero! Recommended for getting your dive into the culture on.

XMR Profitability Calculator: - Put in your equipment's hash rate, your local power cost, and what your pool fees are to see hour, day, week, month, & year long estimations of profits. XMR Hardware Benchmarks: - Not sure what you'll earn? Here's a wide list of broadly configured equipment hashing Monero. PPLNS Explanation: - Thinking of joining a pool instead of solo mining? This explains how you get paid vs everybody else in the pool.

XMR Pool List: - A giant world wide list of pools you could join, what they charge, how they work, & where to find them. Support XMR: - This is the pool I'm currently running in & I mention it out of respect because it's extremely well maintained with intelligent & helpful admins. SupportXMR Droid App: - If you happen to join our pool then this is a cool android application you can download to watch your mining & the pool from afar via your phone. Droid Market Management: - If you're larger then one pool or really into day trading across multiple coins this is another great application to watch all the markets & your investments.

XMR-STAK-CPU: - This is the leading CPU mining program, it's the one I've been using throughout this entire thread so far. Windows Compile Notes: - If you're looking to get onto the Dev branch or change variables with a self compile, here's some great instructions! XMR-STAK-Dependencies: - You're going to need these as well if you're looking to start compiling your own versions.

XMR-STAK-AMD: - This is the leading AMD based GPU mining program, it's made by the developer of the one I've been using throughout this entire thread so far. XMR-STAK-Nvidia: - This is the leading Nvidia GPU mining program, it's the one I've been using throughout this entire thread so far. Nvidia Config Breakdown: - This is a Step By Step breakdown of how to properly config your Nvidia graphics cards inside STAK w/ pics.

Windows Compile Notes: - Same idea as above, here's some great instructions for nvidia compiles. NOTE: this process is quite a bit longer to setup then the CPU one, but just as easy so nothing to fear.

XMR-Node-Proxy: - This is the load balancer and proxy I've been using to split workloads across my equipment & configure difficulty curving. SilentXMR Win: - Monero (XMR) Wrapper to mine when a computer is idle. Will utilize STAK then claymore's as a failover.

Goblin's ARS Thread: - This is the very thread you're reading right now if for some reason you wanted to know that. Goblin's LTT Thread: - This is literally the same thread from here on Ars Technica but running over at Linus Tech Tips. (vastly different communities) Anyways that'll probably do it for helpful places to get started that don't require to much from you.

Once you've got that all conquered and you've read this thread a couple times learning from my mistakes, well, you'll be a god damn coin wizard. Why does my network suck? Oh hello speed racer mining! So I've got a Nighthawk X10 router, it's a quad 1.7ghz with active cooling, at which I've gone into the debug settings and cranked the fan to max 24/7 as I like my gear running cool. I have gig internet from Comcast, I felt this would be the appropriate non-professional router for a small home network. I was going to hand build a pfSense machine but the X10 was $400 and there was no way I was going to go that cheap on a home built.

So yeah it's great for standard use, pushes 950 down all day and night unless it hiccups which it seems to occasionally do. Given it's behind a 1500PFCLCD of it's own I find that interesting though there's only a single build of DD-WRT out there for it and it's currently behind with suggestions from the community to stick on the default firmware for now. ANYWAYS, the entire home network has felt sluggish for a bit, since getting into that speed racer low difficulty work it seems. This is half anecdotal from user reports & half empirical from what I've tested in a very short time period once connecting it to the mining.

So my speed racer setup is doing 0.25ms on the CPU load balancer and 1ms on the GPU balancer. This is flooding shit around the local network as you can imagine. Six miners total just going nuts trying to toss around that low difficulty work and get it back to the pool asap. My primary television is used for nothing but online streaming really and it generally pulls about 200 down when it's first starting to cache up 4K. Though when I'm speedracer mining it seems to have trouble getting up past 100. It'l hang out at like 80-90 then somewhat burst.

That's pretty disappointing for a flagship model even if it is a consumer level device. Though I don't have alot of options here, I'm not going to build an actual real router for six miners in my pad. Then it hit me that maybe, I could double dip on some of the processing power I've got here and divide the work load among two cat7 cables instead of one. Keep in mind I wasn't really sure this would have a positive impact at all, it was going to complicate matters across the network that's for sure.

What's the haps you ask? Well, what if I turned my modem back from bridged mode into normal mode & used it's quad 1ghz processor too?

They only have three modems that are authorized for comcast gig in my area and the one I've got has two eth ports on it. (lol) It's been bridged directly into the Nighthawk X10 and life has been pretty peachy minus the speed racer network spamming.

Though what if I took my virtual load balancers and dedicated the second eth port on the modem to them, setup some basic security, & then DMZ'd the Nighthawk back into place on the first port. Would this actually free up my local network a bit? I mean all the clients are still coming in from the Nighthawk and being passed up through the same cable to the modem, down a new cable to the balancers, and then back down that same cable to the modem again. It seems stupid as fuck, though the idea is, that the modem's quad 1.0 ghz cpu will chew up that mining work off the load balancers since they're being routed an handled outside the NightHawk, even though they pass through the NightHawk. This includes their DNS servers, as previously they where behind the Pi-Hole, with failure fall backs of Google & OpenDNS.

Though now those load balancers are just going straight to Comcast and more Comcast. Though the rest of the network would still be on the X10 & Pi-Hole, sharing files between each other, streaming, etc. Appear to be a win after two days of testing.

The television immediately goes back up to 200ish when it wants to pickup a big chunk of content for caching. File transfers are more responsive, streaming is smoother, etc. I gotta imagine it's simply from placing the load balancers a level up on the different processor.

Seems kinda counter-intuitive, I'm happy I tried this but I felt dumb while setting it up wondering what would happen. If nothing else it goes to show if you're going to get into some real equipment producing some real hash rates you're not going to want to neglect your network setup. It's as important as your miners as your backbone to the internet is how you get to and from the jobsite. Nobody going to pay you if you can't even show up on time or stay there for longer then two seconds. Though, as smooth as it appears to make things run, it does actually run the nighthawk harder, by 1% in the CPU utilization numbers presented in the debug screen. The load balancers are reporting a lower latency time as well so they appear to be functioning slightly faster this way.

I mean it's six miners running around like they've smoked a bunch of crack, I can't imagine that causes any real stress on the Nighthawk but apparently it actually does. Experiment says it's a win though what I'm taking away from this is I really just gotta build a real router an stop using this consumer level crap. As the provocative image description says, this is my equipment's peak performance. Which matches up nicely with the previous image, though you can't just make your equipment peak for a screenshot & you're not always watching your stats. I was actually just walking by my phone (which I tend to leave a mining stats or market watch screen up on) when I noticed I was peaking. I grabbed this screenshot & I also grabbed another one where the CPU & GPU farms traded.1 KH/s back and forth but still maintained the same peak.

We all like seeing our numbers when they're balling large & this is as good as it gets in my world right now. This is 1 KH/s faster then the same equipment averaged on it's own before the hyper-v load balancers and 500 H/s higher peaks then I ever saw before bringing everything together inside XMR-Node-Proxy. This last round of changes are reproducing that one freak time I got this high of a hash rate previously but said I could never get it back. Well, finally I have & these peaks keep returning now. Which makes me believe I've finally started to dial all this in.

Changes to the setup since the last post have been pretty slim. I installed some better security on the load balancers including putting the entire setup behind VPN. I really dislike ever having stuff coming out of my network that's not encrypted & generally limit it to televisions only & at that for netflix as explaining to users how to switch the TV's VPN address to get it to work is often more trouble then just swapping the TV off VPN while people want to watch stuff. This also gets rid of comcast's DNS servers which I was complaining about before. So now both the NightHawk and the Load Balancers are outputting 99% encrypted data again, atleast until it gets dumped out on the other side of my VPN. Which is actually pretty handy as I can now park my load balancers right next to any pool I want around the world.

A feature I was really missing after making these network changes, but even better now because I don't have to route unnecessary non-miner related traffic to where ever I'm wanting to drop off the loadbalancers. Now the NightHawk can be on VPN to one location & the mining traffic off to a completely different location. Pretty happy with this actually, got some security reports getting flung back to my phone as well. Though it's not as good as just having a proper pfSense box setup as a router which clearly I need to build as I've pushed my entire household to the max over this Monero experiment.

Anyways just wanted to show off that those peaks where real & all this effort spent putting together / tweaking this operation has paid off. Those are (to me anyways) some monster peaks an everything has the stability I crave. Users come turn on monitors, turn off monitors, watch videos, do whatever, and the system scales up & down with them perfectly. This has been a very fun educational ride down the XMR tunnel. The funny thing is, I'm still a total novice.

I sit in that Support XMR chat room and talk to the developers when they're around an they're still over my head, there's just sooooo much to learn out there. I'm sure I'll make another post when the next hash improving something optimizing thing catches my eye but given all the overclocks and crazy shit happening behind the scenes I'm pretty pleased with these results. Let's reinvestigate that whole statement about phones being useless: Oh boi you had to know it was coming right? What if we spun up another load balancer, replicated the high pace low difficulty configuration (just scaled real low), and stuck say two phones on it?

Would it be better then two phones running on their own? Could it do anything at all of value? How low power can we go and still flip a hash? Well like always I've came prepared with screenshots!

So yeah I did just that, I lowered the starting difficulty to 5, min to 1, max to 100, then put the shareTargetTime at 1. I'd like to go lower but given these are cell phones that tend to roam around the house as people want to watch youtube here or there I kept them at 1.

(still pretty fast) If you turn on the mining without the load balancers they'll do about 1 block a minute which man, that's just moving some data. Though firing them through the speed racer config they start pushing up to a couple hundred blocks a minute. It also greatly benefits from the other benefits of the balancer, as in, somebody can take a phone & completely close the miner but the work will continue on just half the speed until I can get that device back up again. It would be really neat to get my hands on some other android devices an see what they hash given they're all powered off a 5W usb cable. I'm currently getting about 17 H/s average off them but when they peak I caught two separate screenies of them at 30 H/s.

One thing to keep in mind is that I'm using this NeoNeonMiner program that I downloaded off the Play Store for free. It's ad-supported & by that they mean full screen ads with audio will pop up disrupting whatever you're doing & it spams them at the bottom of the mining screen as well. I would not call this piece of software 'friendly' at all & would gladly pay a percentage cut of mining efforts instead of deal with that type of horseshit. PLUS SIDE, I didn't even know the application did this until I took one of the phones outside the local network. This is because as you can see in the diagrams I've been drawing up, I've got a Pi-Hole sitting on this network. It absolutely roflstomps that entire programs advertising loop & I never once saw a single ad before taking it out of the pi-hole & I don't see any having returned it to the pi-hole. Fucking love that program, if you want to be a good friend / nerd then buy a bunch of raspberry pi's, preload pi-hole on them, and give them out for christmas / birthday gifts.

'I give you the gift of ad-free networking across all your devices, enjoy'. Pi-Hole Mining Enters the ARMs Race: Well I was having a good time late last night hanging with an Arsian when the thought occurred to me that the pi-hole install on the raspberry wasn't utilizing it much at all. Now that I had a load balancer setup for nothing but ARM connections, maybe just maybe it could lose three out of it's four threads to a little mining on the side. Which was actually pretty easily done! But only thanks to install script which pretty much took the piss out of the whole thing. Afterwards you can watch its temps from inside pi-hole's gui itself to make sure it's in the clear, we also logged in via ssh and watched the top process list while we stress tested the network to make sure a single thread would be enough to handle pi-hole or if I needed to reduce the mining to two threads.

(one thread works great even during max stress tests) Temps are great for how much stress is being placed on the device & given it's inside a case. Oh we also overclocked & volted it to the high-OC settings getting it to 1ghz across all four cores stable. What's it push out? Well about 5-6 H/s with three single ghz threads which are of course being piped through the load balancer so it's joining in on the speed racer action as well. Here's the little Pi-Hole Miner itself. Let's plug in a PowerEdge 2950! Well now that's not what I expected.

You ever thought to yourself, damn I bet a 2U with double xeons would be the shit at mining!? Well hold your horses captain because I'm burning 441W of power for an amazing 174 H/s inside Server 2012 R2. No, you read that right. 174 H/s @ 441W.

Well this probably happens because while each CPU is rated at 80W it's meant to go into a server rack and has four 9K fans cooling the entire rig minus the fans in the double power supplies it sports. The real downfall of course is the E5450's don't support AES instructions so mining is brutally inefficient. The 56W mini-workstation is out mining these xeons by 100 H/s itself. Actually plugging it into a calculator, this thing makes 0.30 cents a day and costs over a dollar a day to run!

The only way this thing would ever remain on for this purpose would be if Monero skyrocketed in value before the difficulty curve got anymore monstrous. A four fold increase in value (lolololol) would mean this thing was finally creeping into profitability. So with that in mind, you're either turning this thing off or you're letting it waste money in the hopes that at some point the market will go up enough to justify it's constant no profit expense state now. To put this into perspective, turning old cellphones into a cluster is more efficient & profitable (when scaled) then running this beast server.

Let's also discuss the, you can hear this throughout the entire house no matter where the fuck you put it factor. These things are LOUD and I mean, there's no escaping it. I took foam studio paneling meant for audio booths and lined a box around this thing just so I could close the door to the room it's in and somewhat hear my television in the living room. I opened the window in there and you can clearly hear this thing outside from the side walk. It must sound like I've got a grow going on in here and have terribly planned my centrifugal exhaust system.

It's a bit to high pitch for that to be the truth to an educated ear but for the normal person walking by I'm sure it sounds funny. Oh good times for 174 H/s. Meet a PowerEdge 2950.

PowerEdge 2950 Update: As a continued investigation into the last post I wanted to come back and let everybody know that I managed to get 180.6 H/s out of this beast by running twelve normal mining threads across the eight cores. This is done by turning affinity off & letting your operating system manage the nightmare workload across it's cores instead of assigning specific threads. This is actually a very cool concept we're getting to see in practice here. So previously I ran four cores in low power mode to double it's cache usage from 2MB to 4MB using 16MB total. Then I ran another four cores in normal mode, using 2MB each, so 8MB total. Coming together to fully utilize the available L2. Though the config file notes there will be a performance loss doing this verse just running normal mining threads.

So in order to use normal ones at full efficiency we'd have to run twelve of them, which I've now tested. As crazy as it sounds to make twelve miners split eight cpu cores it utilizes the system cache more effectively resulting in a 5-6 H/s gain. BIG NUMBERS right? In perspective that's basically an entire raspberry pi being added to the ARM load balancer.

Though I think this little experiment was more worth the educational value for sure. Questions Round Threadripper: How do I update XMR-Node-Proxy? Can I do it without reinstalling everything? Saw this pop up in the supportXMR chatango room earlier today. It's actually rather easy and nothing to be worried about!

Also, no you do not need to redo everything. Simply enough, bring up a terminal & navigate into your xmr-node-proxy folder. If you're lost in Linux or just need a little help getting your nixfu going again, I've included a picture below that has white boxes around the exact commands I've used to go through this process. After you're inside simply issue a 'git pull && pm2 restart proxy' command where the word proxy is to be replaced with the actual name you used while setting it up.

As you can see in my example below, this was my CPUs balancer and it was located in the xmr-node-proxy2 directory since it's my second balancer I'm running. To those following along that would mean the normal directory is my GPUs and the proxy3 directory is my ARMs. Roll through all your different installations you're running using the same command and you'll be up to date without even rebooting your machine. Example screenshot of me updating my second load balancer. Properly Understanding Difficulty & 51% Attacks: (with special developer guests) Alright so I've been sitting in the SupportXMR chatango room pretty much 24/7/365 since swapping pools. So much so I've been turned into a moderator so if you come in there spamming a bunch of nonsense you've already been warned the hammer will drop.

(though seriously we're actually super friendly just don't be an asshole) The community is intelligent and extremely helpful not to mention quite global so if you don't speak english well don't worry about it & please still come on in if you have questions. Anyways I try an interact with the community as much as I can an be helpful but sometimes I gotta take a back seat when guest stars show up. This morning I was just reading chat casually in the background when a really good discussion about difficulty and the possibility of 51% attacks just came out of no where when a user logged in with a great question. That's always how the best stuff starts, I've learned alot lurking in the background. Anyways I took the chat log, cut out all the ip addresses, cut out all the discussion that wasn't directly related to this exchange (there was a ton), and created the following for everybody to follow along with. It's important to note, this is not an original document, I have edited out entire parts of sentences from people when it was additional content directed at other personal questions or comments.

I want to make that clear that this is not an exact c/v of the entire conversation. It's purely a creation from that to help people as an educational study tool. FireiceUk: @m5m400 have you noticed that Monero blocks come in threes or fours nowadays? M5M400: @FireiceUk I have noticed.

I have also noticed that there a days with unreal lack of luck. Like yesterday, where we found a 1000+% effort block M5M400: @FireiceUk looking at the pool hashrate stats, there are pools that could do such an attack.

OpticFlow: @FireiceUk what does that mean, to have blocks in a row? FireiceUk: @OpticFlow one way you would see it is if someone was holding onto blocks before broadcasting them OpticFlow: @FireiceUk interesting OpticFlow: @FireiceUk can you mine blocks in advance and use them later? FireiceUk: @OpticFlow that's how you do the majority (51%) and related attacks miziel0: but if you withhold the info about block. Wouldn't it become invalid?

FireiceUk: @miziel0 nope, unless someone creates a longer fork in the meantime OpticFlow: @FireiceUk so you make a hidden branch of the chain and only show one block at a time? FireiceUk: @OpticFlow yes, 51% works like that, A finds a block, pockets, A finds another block pockets, B finds a block, A publishes two blocks, B's block is orphaned miziel0: hmm.

But we are finding consecutive blocks and I doubt m5m is keeping them secret GaryO22: So I'm reading the pastebin that someone linked but I'm stuck at this point 'So the network consensus algorithm will choose the sub branch of blocks whith the heaviest added difficulty.' (Can someone explain to me, hummm, what's the consensus algo? How can two block with the same height have different difficulties? What's a sub-branch? FireiceUk: @GaryO22 basics - you understand how difficulty works? If not let me know if yes then i will take it from there GaryO22: Hum it's kind of fuzzy actually. FireiceUk: @GaryO22 ok, imagine you are rolling a 100 sided dice FireiceUk: @GaryO22 every ten rolls you will get something starting with 0, right?

FireiceUk: 09, 08, 07,. 00 GaryO22: Statistically yes FireiceUk: @GaryO22 ok so let's say network difficulty is 10 FireiceUk: @GaryO22 so you you need to roll 100 / x = 10 FireiceUk: @GaryO22 to get a block FireiceUk: @GaryO22 100 / x >= 10 to be precise FireiceUk: @GaryO22 your roll FireiceUk: @GaryO22 but you can roll 04 or 07, either will get you a block, with me on that5? OpticFlow: @FireiceUk so you stash those until the diff is 10 GaryO22: same for any roll. Goblin show us your rigs & setup, get personal with us: Well outside of watching 300+ people sit in the chatango room because the stats screen is down & they're all freaking out, there has been some decent discussion this morning as well! Everybody wants to see my mining setup and honestly it's not that cool. The desk I sit at, that's pretty PCMR, I'm not going to lie, makes my epeen feel about 1000x large but in reality I'd gladly trade my cool 4K proart monitors and updesk for some rx vegas to put in my rigs. I also decided I was tired of hearing the mining fan load throughout the house so I centralized all the equipment I could into a corner of one bedroom next to an open window.

My desk isn't going anywhere so you still hear that but that's to be expected. This is nice because it also gives a location for everybody to return their mobile devices (laptop+phones) to for me to make sure mining is still running on them & they're being properly cooled.

Speaking of properly cooled, whoa buddy that room got toasty fucking hot real quick. Even with it wide open and 57F outside, there needs to be a fan in that window asap. I've taken a picture of the temp in the room over the last 24 hours & it's pretty brutal. Thank goodness we're going into winter as this will heat my home no problem, just put a fan in the doorway instead of the window. Looking out my window while I'm reading chat & studying XMR.

Speed Racer 2.0: (lets go faaaaaaaaast) The other day I was sitting in the SupportXMR channel reading through everybody's discussion. Some users where debating the differences between mining software and it was noted that SGMiner uses two threads per GPU while everybody else uses one. The channel debated this for a while before moving on in topic. This stuck with me for the rest of the day and I started testing it out of interest to what would happen. Can you run multiple miners across your single devices to any advantage? The answer to this is yes, yes you can. Though it's a process, just like about anything I've discussed in this thread so far.

I saw other people say they had tried this to no success, most said they couldn't even get XMR-STAK to turn on with multiple threads per device. Release or Dev branch, just crashes for days. The secret is not trying to add in a second miner to the configuration file like you would additional cards. The key is running the mining application TWICE, as in, two separate executable launches. THIS will connect to the same device as many times as you want! Though hard crashes, system reboots, and a whole lot of driver hell will follow if you start playing around without carefully considering everything.

Now how to dial in this process is simply by dividing your graphics card's power into smaller but equal separate threads to run. (please turn off your overclocks for the original configuration part of this, we will turn them back up later don't worry.) Example my 1080 Waterforce has twenty streaming multiprocessors, so I could run four miners at five threads each instead of one at twenty. The card at 2.1/5.5ghz overclock can handle 100 blocks across 20 threads. Though if you put a miner on 2 threads it can still push the same 100 blocks, actually it can push way more blocks then 100 before crashing. So if I open up two two-threaded miners both at say 150 blocks each now I'm getting 300 blocks out of four threads instead of the 100 blocks I was seeing before. I've spend DAYS testing this theory and there is a breaking point where you're just maxing your gear out and causing issues.

Example, 14x2 threaded workers on my titan just bogs it to the ground, not that you can't do it successfully, it's just not optimal. Though on my 1080 I saw a 50 H/s improvement splitting it into ten two threaded miners. There's just alot of cool numbers going on the background and it all does actually make sense once you dig deep enough into it. Through the division of power you can achieve some pretty radical results depending on how you've setup your load balancers. (which is an important element to this) I would highly recommend starting out by dividing your graphic card's power in four.

While I've seen success dividing it more times then this it's a really minor gain for an incredible amount of system stress and additional network load. Example: My 1080 has 20 SM's so now I'm running four five threaded miners across it. My Titan XP has 28 SM's so it's now running four seven threaded miners across it.

It's really important you measure your pre-split pre-load balancer hash rates, both max and averages. Then compare these numbers to your split numbers.

If you're not achieving atleast the same total level of performance as before the split then you've configured things wrong. Like setting up a single thread, to many blocks is a bad thing! Once you've got them fired up it's important to watch all your miners work at once and then occasionally test their hashing rates (this can be done easily by enabling verbose level 4 automatic output reporting) then seeing if everybody is working at the same rate relative to their difficult they've been dynamically assigned. If you're not seeing an equal division of your processing power then your system is having issues keeping up with the division of the work, you're bottlenecking somewhere.

Lower your blocks by values of two until you achieve equality across all the miners. Or on the other side, if you turn it on and everything is equal right away but really low hashing rate numbers then you should increase it by two until it starts crashing. If everything is stable & the rates look good across your split up device load then you can kick up your overclocks again.

What you're going to see is a CUDA crash on your last opened miner if you've over-overlocked your device. If you've out in space overclocked it then it'll start crashing on multiple mining threads instead of just the last one. There's two ways to handle this situation 1.) step your overclocks down a little, bit by bit, until it's stable with your current setup across all the mining threads 2.) go into your config file and slowly step down the block rate by values of two until it no longer crashes when your normal pre-workload division overclocks turn on. This can be really handy because maintaining the same clocks you had running beforehand makes it easier to analyze your results. (plus to me, it confirms you're achieving a different configuration at the same stability and speeds) Finally once you've got equally divided workloads (once again, taking variable difficulty into account) running without problem & they're all overclocked then you're pretty close to dialing this in. You might still notice your hash rate isn't what it use to be or that your improvement was pretty small overall. Scratching my head I fired up alot of tests to try and pinpoint my error in understanding.

Then it hit me while watching the graphics card's power consumption rates/levels in afterburner, what if the reduced threads weren't asking for enough juice? It seemed like I wasn't seeing those spikes on the power graph anymore. I thought that would be nice as it was a more stabilized & efficient way to mine plus both systems seemed to exhibit much faster response times now! Though if the systems weren't getting wrecked as hard then it seemed logical I wasn't getting the max out of them through this division of mining capability. How do I get the juice back up & fire these smaller work loads up a notch? Previously single threaded I ran at a bfactor of 8 on systems that nobody was touching often and all the way back to 14 on systems people used all day.

It made the automated scaling up and down of the mining processes in the background less noticeable. (even though it did mine less) Anything lower then 8 and you're in for a bad time inside environments meant to be used by users all day. Though since we're doing little miners maybe they could handle a lower factor? Yes they can! I'm able to get them all the way down to 4, half the bfactor of before! Though for responsiveness I pushed them back up one to 5, then up again another to 6 on the most heavily used systems.

You can go into afterburner and watch the power consumption graph, once you've got everything dialed in properly it should be jumping up to those peaks from your old valley but at a much more rapid rate now. You're not asking one guy to climb to the top anymore you're asking four people to, so you can literally watch four spikes in your power chart now instead of one. Once you see your baseline power numbers return to normal and you see your peaks return to around where they where before then you're back to dialed in mining on that card. Depending on how far you push your bfactor you'll get that full on system lag where you wait five seconds after clicking something. Even at dialed back rates making the systems MORE usable throughout the day then they use to be I'm seeing the benefits. Now even the titan is surpassing it's previous max hash rates. I saw it peak up in the low 1100 H/s when previously the highest I'd been able to get out of it was around 990 H/s.

Inside the SupportXMR android application when I'd be watching for peaks I'd generally be stoked to see 2 KH/s on any given proxy but when I kicked up this new concept I saw a 2.2 KH/s peak within a couple minutes! By 200 H/s even! Not only this, but our block counts are through the roof now! Previously the 1080 did 100 blocks, now it does 660!! The Titan does 704 now!!

So while we're talking the same exact gear, we're seeing 660-704% increases in block rate when configured in this manner. Now talking CPUs instead of GPUs, to achieve this effect with your processor all you have to do is run as many whole copies of the miner as you can fit into your cache. Example: My i7-5820K & 5930K both have 15MB L3 cache.

I can get 7x2MB miners into that 15MB fully. So I remove affinity and fire up seven individual copies of a single threaded full power miner. This saw another jump in performance! I was actually surprised that the CPUs could yield even more hash rate then I had them at already as when compared with others they're already ahead of the crowd. Doing all of this division work also has the additional benefit of working with xmr-node-proxy on levels it was more intended for. The dev has said 10+ devices is a good point to start, but normally a non-server related box would only have 1 cpu miner and 1-2 gpu miners. So per computer people would only have 2-3 devices to toss at the that basic entry point of ten.

Though you split up your devices into smaller wokers and all a sudden you've got like 12 devices per machine! Your load balancer is going nuts by the time you distribute out your entire network of machines in this new manner. (and the amount of data flying around your network increases proportionally as well, just a heads up!) This of course dramatically lowers the difficulty of what you're pushing. (keeping with the high speed low difficulty concept) As you're dividing the same equipment's power, it's not like you added any new hardware, you're just running many more miners across it now.

We're all carrying tiny little bricks to the job site and back instead of lugging boulders around. Load balancer wise I've had to change how things are running to maximize these new changes. I've lowered my starting advertised difficulties considerably. Since we're dividing the work up so many more times now it's going to take the load balancer forever to automatically adjust to an optimal rate if I'm asking everybody to still do the heavy lifting from before.

It's important to note, this will fix itself overtime, but not telling a bunch of little guys to lift a couple tons helps in the grand scheme of getting things working quickly. My shareTargetTime is 0.5 on my CPUs and ARMs while that is just a bit to fast for GPUs to really extend their legs & dig in.

Because of this the GPU proxy doubles down & runs on a shareTargetTime of 1.0. Anything beyond these numbers starts to show a loss of hashing power throughout all of my tests & believe me I've been testing this for a while now. (LOL look at the thread you're reading) So there you have it, that's a crash course to Speed Racer 2.0. You can now duplicate this across your systems and see what results you get! Speed Racer 2.0 Running On i7-5930+TitanXP Box.

Man, I haven't been in a BestBuy for a minute. I shrugged my shoulders and figured how bad could it be? They had to have some type of decent graphics cards right? Maybe a little over priced? Let's just walk in and find out.

Finally found the graphics card isle an it's empty, all out of stock signs. Three employees where all standing one row over circle jerking so I yelled over, guys, what, does best buy not sell graphics cards anymore? They all laughed and said 'bro, bitcoin, I don't know if you've ever heard of it? It's a crypto-currency thing, don't worry about it, basically, been sold out for the last six months straight, still sold out, never lasts longer then a day when we get them in, you can drink beer for free until you pass out, every day, so all the kids grab them!'

At which I just laughed an walked out. Yup, there's a mining craze still going on. Installing the customized 64-Bit Wolf Android Miner: (next level mobile device mining) A user in the SupportXMR channel brought to my attention that hyc_symas had ported wolf's miner to Android including OpenCL/GPU support.

This is a 64-bit only miner so it will not work on all your devices, for example I found out of my five arm devices only one of them was actually compatible. Though your mining rates will be double-triple the rates of using that shit NeoNeon mining application I've been showing off throughout the thread. Plus it's a real miner you use at terminal, not some bullshit app you download off the google play store. You can find his thread discussing this on reddit over at: As for installing it he actually recommends you grab 'Termux' from the app store but I gotta say I think this application is total horseshit. I would instead recommend you download 'Terminal Emulator for Android' as it's much better. Also, depending on your device this is going to be a bit of a wildcard run here, I'm going to give you how I did it, show work fine for you to repeat the steps, but if things go wrong you're going to need a bit of technical appreciation to get yourself back on track. Also, as heavily warned in the original thread, this can and will destroy a device if not respected.

It will cook your screen not to mention your components, KEEP YOUR SHIT COOL, OUT OF THE SUN, & WELL VENTILATED!!! (you have been warned) I also want to give mad shots out to Arsian Gigabaud for helping me with this one, he corrected some pretty rofl misunderstandings I had.

First you'll want to download the software onto your PC and change the configuration file to match your own wallet & device settings. (change: xmr.conf) You can see hyc_symas has included sample files for CPUs and GPUs as well so you can look at them for reference. Once you've got everything configured correctly you need to plug your android into your computer and then select file/data sharing in the dropdown menu on the android device once it's detected you've plugged it into a computer. (it normally defaults to pictures only, you want access to everything, and no you don't need to be rooted to do this) Once done with this go back to your computer and open up the device, navigate to the download folder, & copy the parent folder that holds your newly configured miner in it (this folder is actually called /miner/) to your download folder on the device.

(you can simply drag and drop it inside windows) Okay now the fun part! Open up your terminal emulator you downloaded before on the actual android device. Now we're going to enter some commands here, I'm going to drop to a code box and explain them there, read carefully. I'm going to include noobs notes for those who are here learning, do not feel bad, none of us where born knowing this stuff, just take the opportunity to grow! Cd /sdcard/Download/miner/. Late Night Parking Lot Craigslist Monero Exchanges: Last night I got out of bed around 3AM as my bat phone was blowing up. I'd been hustling craigslist all day looking for some mining gear to come up on for a new project.

All I needed was a working shell of quality parts & I'd been bustin balls for a hot minute. Finally a guy hit me up and you gotta hop when the offers come no matter the time.

This guy had listed $2000 worth of parts if brought brand new today (I looked them up), though over the course of the day I got him to ditch $600 in monitors and peripherals so we could just discuss the value he had in mining parts. He wanted $1250, then over a couple hours I had bartered him down to a thousand before fake walking away, then through using burner numbers over a couple hours to demoralize the guy he said he would go as low as eight hundred. (kept hitting him with offers of 300-500 from fake people) I told him I could give him $800 in XMR or $700 in cash as I had to convert it from the Monero so there would be a loss. He agreed to the seven but wanted it picked up, since it was late I offered him another 20 to bring it to me. Guy had kept all the original retail boxes, paperwork, extra cables, he really cared for this machine. He left it overclocked at 4.4ghz but I think I can fine tune it a bit better. Overall for the price not a bad little score!

Utilizing Ol'Stock Tales To Explain Cryptocurrency Markets: Once upon a time, in a place overrun with monkeys, man appeared and announced to the villagers that he would buy monkeys for 10 XMR each. The villagers, seeing that there were many monkeys around, went out to the forest, and started catching them. The man bought thousands at 10 XMR and as supply started to diminish, they became harder to catch, so the villagers stopped their effort. The man then announced that he would now pay 20 XMR for each one.

This renewed the efforts of the villagers and they started catching monkeys again. But soon the supply diminished even further and they were ever harder to catch, so people started going back to their farms and forgot about monkey catching.

The man increased his price to 25 XMR each and the supply of monkeys became so sparse that it was an effort to even see a monkey, much less catch one. The man now announced that he would buy monkeys for 50 XMR! However, since he had to go to the city on some business, his assistant would now buy on his behalf.

While the man was away the assistant told the villagers, 'Look at all these monkeys in the big cage that the man has bought. I will sell them to you at 25 XMR each and when the man returns from the city, you can sell them to him for 50 XMR each.' The villagers rounded up all their savings and bought all the monkeys.

They never saw the man or his assistant again, and once again there were monkeys everywhere. Now you have a better understanding of how the cryptocurrency market works.