lukMiner v0.10.1 with Monero v7 Support

Oh-kay, that turned out to be more work than expected… with cpu, knc, knl, and opencl versions all using different codes this “simple” thing of adding v7 support eventually turned out to be more work than expected. But hey, isn’t it always like that?

Either way – as of a few minutes ago I finally finished baking a new release (v0.10.1) that “seems” to run stably on the Monero v7 Testnet pool, for every one of the supported platforms: cpu, x100 phi, x200 phi, and OpenCL all seem to work just fine. As with all recent releases, you can download this relaese under . And also as usual: please let me know if you run into any issues!

To use: When using “classic” cryptonight (sumo, etn, and monero before the fork): use the “-a xn” (or “-a xnclassic”) command line flag; for cryptonight light (aeon) use “-a xnlight”; and for Monero v7 use “-a xmr-v7”. For more details on usage – including some examples – also see the at

Caveats/Remaining Issues

Though I’ve tested the above version quite a bit, a few issues are known to remain:

  1. This version can not (yet?) auto-detect whether we’re in pre-fork or post-fork times, so you have to specify the right “-a <xn|xmr-v7>” command line flag to produce the right hashes. If you don’t, you’ll produce invalid hashes, and at some point the pool you use will get angry. As such: make sure to switch your miner over to the new protocol as soon as – but not before – the hard fork hits (unless I manage to build an auto-detecting version before that, of course 🙂 ).
  2. Even if you use the right flags for the right pool, I do not yet know whether dwarfpool – where my dev shares go – will actually switch over to the v7 protocol automatically; nor do I know when they’ll do that, nor whether they’ll do that on the same URL/port, etc. Now if they do not simply switch the existing dwarfpool over at the right time (as one would expect they should!?), then the version you’d be using would try to submit invalid v7 dev shares to a not-yet v7 dwarfpool. If you do run into any such issues – or if you want to test the miner yourself on the testnet before dwarfpool switches over – then you can also use the “–dev-shared-on-test-net” command line flag: With this flag, all xmr-v7 dev shares will get sent to the (already existant) testnet pool on moneroworld, which should certainly accept them as v7 shares. (Needless to say, though, those shares get wasted, so better not use that flag after the hard fork is over :-/)
  3. Though I did update all the miner variants I have not yet updated the lukSticks. I’ll try to do this later this week…

As such: some issues remain; but at least the miner itself will already support v7 … and with another 9 days or so to go ’til the hard fork I’m reasonably optimistic I’ll get the remaining kinks ironed out ’til then, too!

With that:

Happy Mining!

PS: I’d like to hereby give a big shout-out to whoever set up the monero v7 testnet pool at … whoever that was: THANK YOU!


Monero v7, first light …

Just a quick heads-up, because so many of you are curious on support for the v7 hard-fork: it’s now Sunday morning, 12:37 am, and I finally finished getting a first implementation of this Monero v7 variant working…. and at least according to the generated hashes are actually correct.

I’ll still have a ways to go in cleaning up the code, fixing the opencl code, doing some more burn-in testing, and in particular allowing command-line switching between old and new protocol (currently it’s compile-time)…. but at least the lion’s share is done. So bottom line: Everything looking good for the hard fork in at the end of March ;-).

With that – happy mining!



MPSS Version for x200 machines


Though this will affect only a small portion of my readers (after all, the 7220 cards are pretty thin on the ground….) I still wanted to share this, because it’ll probably make at least some peoples’ days: Finally found a night earlier this week where I sat down and tried to build an MPSS offload version for the 7220 cards as well…. and who’d have guessed, when starting out with an MPSS version for the x100s it actually worked out pretty well.

Now the main reason I did that is that previously I had to jump through all kind of hoops to run the phi binary “natively” on those machies, with automated ssh scripts to start mpss, copy the miner to the devices, forward ports, kill/restart if required, etcpp…. pain in the ….. well. And of course, with the MPSS version all of that is gone, because the miner itself just runs on the host, and all the offloading is done by MPSS.

Anyway – the second reason I did that – and the thing that at least some here will enjoy – is that it’s always been bugging me that when running in native mode the 8 cards actually appear on pools as eight separate machines …. and I so wanted to at least once see an output of “24kH/s” in that miner’s output… And now, with the MPSS mode all the cards now indeed do work together in a single miner, so here it is:


And even more fun than that, here’s the corresponding screenshot from NiceHash… in particular, have a look at the difficulty column *G*.


Since that mpss offload version has pretty steep dependencies on OS version, MPSS version, etc I’m not going to put that into the public release; however, I already created a lukStick version of it, so if anybody does have some machines with x200 cards: let me know; I’d be happy to share that stick.

With that,

Happy Mining!


Upcoming Changes: Monero Hard Fork, Different Crytponight flavors, and Renamings …

Good morning, everybody!

As some of you may have heard there’s currently a certain “buzz” of excitement around the monero community, all relating to the upcoming “hard fork” – and though it’s actually surprising to must just how little is yet known about this upcoming change, I wanted to at least assure everybody that yes, of course I will update lukMiner to work with this hard fork.

Why is this “hard fork” such a big deal?

Now before saying anything else, let me go a bit into why this hard fork is such a big deal. Hard forks are nothing new to altcoins, and in fact, most coins are just  forks of a very small family of core algorithms (e.g., Monero, ETN, Sumo, etc are all just variants of the same cryptonight algorithm). Even for a given coin, hard forks are not necessarily a big deal: Yes, sometimes these hard forks lead to “splitting” of coins if only some of the community adopt these changes – e.g., ZEC (ZCash) and ZCL (ZCash Classic), or ETH (Ether) and ETC (Ether Classic) are both the effect of a given coin (e.g., ETH) having hard forked, and some continuing to mine the old, “classic” coin on the old blockchain with the old algorithm; while others use the new code on the new, “forked” blockchain. It’ll be interesting to see if this’ll happen to monero, too; though at least right now it looks like at least in this instance it probably won’t (we’ll see).

Even if it does not lead to a real “fork” into different coins, hard forks in a given coin’s codebase are nothing new – Monero alone had 6 or so in the past, and usually they’re not too big a deal: usually it’s some sort of bugfix or vulnerability fix that can’t be done in a backwards-compatible way; it usually gets adopted by everybody that runs a node, and that’s it. No big deal.

Now this time, unfortunately, the changes that are being discussed relate not only to the code affecting the nodes themselves, but to the actual hashing algorithm behind monero itself. In particular, this has two really big implications: First, it means that it will affect everybody that mines monero: If only the node code changes (as in the past) then it’s only those that run their own nodes that have to update; and in times where you pretty much have to use a pool, anyway, that means the burden on updating in the past was almost entirely limited to pool owners. This time, it’s the miners themselves that have to change; and it’s not only the all the miner developers (such as I) that have to change their codes, but also all the actual miners (i.e., you) that have to update to those new versions. So if you’re reading this, be prepared that you will have to update to the respective version of lukMiner as soon as this hard fork takes effect (and no, I do not know when that will be, yet).

The second big change – and maybe even more of a pain in the … ah, backside … that most people seem to not even have realized yet is that this means that this probably you will no longer be able to interchangeably miner different cryptonight coins with the same hashing algorithm: In the pre-fork world, the same miner could mine both XMR, ETN, SUMO, NiceHash, BXN, and a ton of other codes. The upcoming change however is a change to Monero, not to the cryptonight algorithm itself, and as such, it’s totally unclear which other coins (if any) will adopt this change. That sounds benign, but probably isn’t, as it creates all kinds of “collateral damage” questions: For example, will Nicehash switch its “cryptonight” over to the new Monero algorithm? Or will they (have to) add an additional algorithm just for Monero? (And if they do, what about all those NiceHash users that bought cryptonight hashes to mine monero?). Or in fact, does Nicehash even still make sense if you can no longer trade the same hashes for the most profitable coins?. It’ll have similar questions for sites like WhatToMine (can no longer compare different cryptonight algorithms), etcpp. Lots of questions, and so far, few answers.

Even for us devs, there’s a lot of potential “collateral damage”: For example, right now I can steer all my dev shares to dwarfpool, because it doesn’t matter which coin the users mines; the hashes are the same. After the hard fork, I (as well as every other miner dev) will have to track different accounts, and send the dev shares accordingly. Not a big deal, you say … BUT: what if somebody keeps on mining with older version of a miner that hasn’t been updated yet? As long as he mines only coins that haven’t changed he’s fine – but suddenly, lots of “wrong” shares will be routed to the (old) dev share accounts, which I’m sure DwarfPool won’t be all too happy about….

Anyway; the fork is going to happen, and despite all my whining above it’s probably a good thing: ASICs do take a long time to develop, test, tape in, test again, produce, test again, and ship; while software can be changed in a few minutes. As such, changing the mining algorithms – albeit but slightly – will be a very good deterrence against ASICs, and that in itself is a (very) good thing. I’d wish for a bit more transparency and information about very basic questions like “what actually will change … and when?” – but overall, it’s still a good thing. (And please note, it’s also a good thing for you, the users: The biggest threat to your investment in CPUs, GPUs, and Phis for mining is ASICs!).

Upcoming Changes to LukMiner

So, enough of that whining – what does it mean for you, the users? First of all, yes, I most certainly will produce a version of lukMiner that will adapt to the hard fork. And yes, I’ll do that as soon as anybody can tell me what the changes will actually be (so far the Monero devs don’t answer, and there’s no changes in the public codebase visible, yet, even in branches). But it likely won’t be much that’ll change – if all you want is thwarting an ASIC the changes could be trivially small – so I fully expect to have a fixed version the same day I get info of what those changes are. After all, I have a fair amount of machines running on both Nicehash and specific “classic” cryptonight coins (ETN, SUMO), and (currently) all my dev shares on Monero… so even if it wasn’t for my own commitment to you, the users – I’d better have something quick.

Second, I will likely change the miner to no longer have different binaries for aeon vs xmr vs new-xmr, vs xyz; and instead have a single miner that can select the algorithm on the command line (there’s already way too many different binaries; I don’t want have yet another). Most likely, this will take the form of “-coin <name>”, where “name” will be name of the coin to miner (eg, xmr for monero, aeon for aeon, etn for Electroneum, etc). Eventually I’ll also try to merge in all the different opencl vs mpss vs cpu vs phi vs knl binaries into only two different binaries … but that can wait. Either way, you’ll have to update your mining scripts. (I’ll post detailed info as soon as I release the updated miner).

So; enough for today. Bottom line: Big changes are coming; let’s see how they’ll play out – but overall they’re probably for the long-term good; and I’ll certainly support them from day one. With that:

Happy Mining!


(luk-)Mining made easy – The “lukStick”…

(Bottom line: here’s a ready-to-go iso-image that’ll turn a 16GB USB stick into a self bootable linux-‘disk’ that’ll automatically run lukMiner – so you can run your Phi nodes without the need for buying disks or installing linux’es…)

With all the interest in the Asrock machines, one question that came up again and again is “if I do get one of those machines, what else will I need to mine on it” … after all, this machine has been stripped of many things including disks and memory, and even by Asrock is sometimes called a “barebone” – so maybe this question isn’t all that surprising.

Now “in theory”, the one single thing this machine was missing is a pair of harddisks, and, of course, a software install on those disks that will actually contain and run the miner. And sure, you can get such disks for $10 a pop on Newegg – but the software install can be a little bit more of a pain, in particular for those among us that aren’t enough of a Linux experts to do things like auto-starting the miner, etc (and even for those among us that have done all of that before, it still takes a lot of time to do all this).

As such, from the very beginning I had promised I’d look into coming up with something that would be a bit easier; possibly using a bootable USB stick that would automatically run the miner…  Now when I first floated that idea I got lots of positive feedback (in fact, one user even offered to “buy” those sticks!); but it did take a while to make it work.

Anyway – today, without further ado, I present to you – ta-daa – the “lukStick” …. the best invention since sliced bread, a cure against all illnesses, and …. well, maybe not all that good, but hopefully still useful! In all seriousness: the “lukStick” is nothing but a ready-to-go Linux image for a 16GB USB stick; bootable, with the miner started automatically, and a separate dos/fat partition that contains the config file (for those users that are more comfortable with dos/windows machines 🙂 ). And no, you won’t have to pay for it – if you absolutely want to I will of course take donations, but you most certainly won’t have to ;-).

So, without further ado, here’s what you have to do

  • get a bunch of 16 GB USB sticks (you can get them for $5 a pop on NewEgg; I took the Cruzer 16GBs)
  • download the latest image from
  • unzip the downloaded image
  • take a USB stick and copy that .iso image onto it (I use ‘dd’ under linux, but there’s probably windows tools for that, too)
  • Once the iso image is burned, take the USB stick out, and plug it back in; this should mount the fat partition that contains the “” script. Edit that script to use your own pool, port, address, etc.
  • Plug the stick into an Asrock KNL box, turn it on, done.

Of course, the same stick will also work in the Exxact boxes; however, you may have to take out the disks to make sure it actually boots from USB first (the Arock machines don’t have disks, so will boot from USB automatically).

The Stick has a complete Ubuntu 17 on it, so once it’s plugged in you won’t need any harddisk any more – meaning it’s all you’ll ever need to make the Asrock machines go. Also, the miner is preinstalled on that stick, and will get started automatically upon boot. Oh, and of course, there’s no reason whatsoever why this would/should be restricted to the Asrock machines, or even to only Phis … you can of course change the script to also use the ‘cpu’ miner, and run that on any machine you want.

With that:

Happy Mining!

x100 MPSS Users: Major bugfix release!

To all KNC/MPSS users: Please immediately update to !

First of all: To all those that volunteered to be guinea-pigs and try the MPSS offload version I added in 0.9: A giant “mea culpa, mea culpa, mea maxima culpa”…. I hardly know how to write this without feeling like a complete ass, but that MPSS offload version did indeed have a major flaw that led to the KNC device code getting stuck in mining developer shares after 10 minutes, so to whoever ran that code: your KNC card(s) have been mining for me, and only for me, since 0.9 came out …. oh man, I don’t know what to say….

Reason I didn’t spot this sooner – even after two KNC/MPSS users reported un-expectedly low hashes for their accounts – is that this bug appears only in the MPSS offload version (not in cpu, phi, opencl, cuda, or even knc native mode) … and even when running that mpss mode it only happened for the shares computed on the KNC (the CPU threads still mined for the user)… and even then, it’d happen only after a few minutes… and even then, you’d only “really” see it if you ran without the CPU threads…. and even then, the outputs looked absolutely right, ….. which made it all so hard to reproduce. But still, those are nothing but empty excuses; I did verify the bug existed, and now I do feel like said “complete ass”.

Now, what next? First of all: Once again, mea culpa, that should not have happened. Also many, many thanks to those that reported this bug, and still stuck with me … I owe you one. Next: To every body that did run this MPSS version for a considerable time: let me know how much you think you should have made, and I’ll glady reimburse you (it can’t be that much; the MPSS shares are rather small). In addition: as another sign of how sorry I am I just changed to KNC miner share from 4% to 1%, indefinitely. And finally: if you do intend to run in MPSS mode, please update your miner to 0.9.2 ASAP (here the link:

Again, my most sincere apologies… I don’t know what else to say …


Update 2/11: Updates the link from “0.9.2rc2” (release candidate 2) to “0.9.2” (the actual release).

“Frequently asked questions” on the latest article…

Wow – and I thought the original phi mining article 8×7220 Phi System had gotten a lot of replies… man, was I wrong: the latest article on mining with the Asrock Rack 4×7210 system got a solid two thousand reads in the first 24 hours. Amazing.

Anyway – there were lots of questions on these systems (as well as on the Exxact system I mentioned earlier), and I’ll try to answer them all. I’ll try to answer every email I’m getting; but still, some questions seem to be recurring more often than others, and for those I think (hope?) it’ll be easier if I just put them onto the blog itself. I’ll start today with a two or three key ones, and will update this page (ie, not post a new one every time) as I get to it…. bear with me; I can only type so fast :-/

Q: What is the wall power draw on those systems?

Probably the most asked question, and about an hour ago I decided it’s quicker to just drive to home depot and get a new Watt-meter than trying to reply to several emails (unfortunately I apparently fried my original one when I put it behind that 24kH monster machine I described earlier …. not a good idea).

Now with that brand new gadget, here’s what I got: My Asrock Rack 4×7210 system pulls pretty much 1300-1350W from the wall (on 110V, will update with 210 once I move it to my cohosting site). Of course that is under full load:


The 7210s have a TDP of 215W, so seems the rest of the system is pulling an additional 500Ws on top of that – way more than I would have expected, but still… 1.3KW for 11KH/s isn’t bad at all (that’s what my average GPU mining rig pulls as well, with significantly less output). The 7250s will likely pull more, but don’t have any asrack ones yet.

In my Exxact 4×7250 System I’m pulling more, apparently something around 1550W:


Note that is with the DIMMs and disks removed (see next post to come), but I doubt that’ll add more. Now why this pulls 200Ws more than the other one I don’t know – the TDP difference between 7210s (215W) and 7250s (250W) should only account for 140Ws, not 200… but then, I have them on 110Vs, which is where the PSUs won’t be at their utmost efficiency.

Q: Where can I get those systems?

Right now there’s two confirmed sources that I have used myself: one is Exxact Corp; the other is Asrock Rack. In particular the ~$3k system that the last post was about is from Asrock Rack.

For those that asked where to find the web page to order those from: Such a page does not exist (yet), but you can send an email to . Note they “apparently” got quite some interest recently (wonder where this was coming from 🙂 ), so they may be short on stock.

In addition to Asrock and Exxact, you may also be able to get some such systems directly from Intel. I’ll post more when something on that front materializes more clearly, but at least if you want to buy more than just one or two systems I’m sure somebody would like to talk you (and I’d be happy to make the contact). Full disclosure: As my “About” page states I do actually work for Intel in my day job, but in a totally different capacity… (yes, “interesting” situation indeed, tell me about it).

Q: Why do some systems perform better than others?

As mentioned in an earlier post the default BIOS that these systems originally came with wasn’t optimal for the MCDRAM, but that can be fixed by using the right BIOS. Asrock Rack already found “the right” one; I’ll post it as soon as I receive it myself. Of course I also asked Exxact for one, but no reply yet (I only asked last night).

I sincerely hope Asrock will automatically put the right one onto future systems (in fact I’m 90+% sure they will), but jsut in case: you might want to tell them what the system is for, and ask if it has the right BIOS… just in case.

In addition, there also seems to be some OS influence as well – doesn’t make the slightest sense to me, but it seems Ubuntu can be up to 10% faster than CentOS – not sure if that’ll still be the case after the BIOS update, but at least for the old BIOS that difference has been confirmed by multiple users (as well as myself).

Q: Are those co-processors / GPUs / PCI cards ?

No. The x200 “Knights Landing” series (and now the x205 “Knights Mill” ones as well) are all “bootable” processors. You can get them in workstation form factor as well (e.g., from Colfax:, but primarily they’re intended for High-Performance-Computing(HPC) / Supercomputing (e.g., the Stampede supercomputer has 6,400 of those Phis!), so their “natural habitat” is in rack-mount servers (e.g., in a 2U rackmount form factor). Either way, they are the “main CPUs” that go right onto the server motherboard. The big upside of this is that it’s so much easier to go “at scale” – find a co-location, pay them for their space and power, and just rack them up….

Note there are also a few isolated prototypes of PCI cards out in the wild (the so-called 7220s and 7240s), but this is a different discussion – and since they’re not freely available, anyway, please ignore them for now.

Q: What else do I need for this build ?

Well, that’s an almost trivial one: Nothing.

Though it’s significantly less fun than a “real” build (such as the one in my post with 7220 cards – that was fun!) these are ready-to-go rackmount systems. For the Exxact system the system comes with memory, disks, and OPA cards (none of which you actually need :-/); you can install linux on the disks, and run it, or take out the disks and use a pre-built bootable USB stick (will write more on that in a separate post).

The Asrock Rack system is a “barebone” system with just the chassis, PSU, and CPU – you don’t need either memory or disks, but you obviously do need something to boot off, so what I did is create myself a bootable USB stick with a linux distribution (and lukminer preinstalled in the boot script). So you do need those USB boot sticks (or to plug in your own disks – newegg has refurbished barracudas for $10 a pop!); but other than that it’s ready to go.

Be warned though they are not exactly quiet – they’re intended for data centers, not for “under the desk”, or “next to my TV”.

Q: Now why are the Asrock Systems so cheap?

Now that is an interesting question ;-). According to the list price for 7210s is indeed around $1,900 per 7210; so one’d expect a four-node system to cost at least $8k just for the CPUs. However, there currently “seems” to be an active promotion going on where the “older” x200s (7210, 7250, etc) are availalable for a “lower” price – that may or may not be related to the fact that the newer x205 “Knights Mill” generation of the Phis is now out, but whatever it may be – right now they are quite steeply discounted. Asrock Rack (or Intel?) may or may not be able to tell you more about that… can’t.

Note, of course, that if that is a special pricing promo it may or may not disappear at some point in time. Again, Asrock – or your favorite Intel distributor – may or may not know more.

Q: What miner are you using to get this performance?

Well – since this is the “lukMiner” blog you may not be surprised that I use the “lukMiner” miner :-). Pre-built binaries for the phis are available via this link ; and yes, I do take a developer share, so of course, I’m heavily biased towards these systems – I do not get any commissions from either Asrock, Exxact, Intel, or whoever (which is doubly weird because I work for Intel in my day job, in a totally different capacity!?) … but I do get a share if you guys are using lukMiner to mine on them. On the upside: That means I have a very high incentive to make it even better and even faster, and to also look into other coins….

Q: What coins is this for?

This can also be googled on the lukMiner google site, but just to mention it here as well: Currently lukMiner supports only cryptonight (monero, bytecoin, electroneum, sumo, …) and cryptonight light (aeon) coins.

As to other coins: Since the Phis are regular Intel CPUs you can, in theory, also run whatever other miner code you want to run… but be warned: The MCDRAM and the lots of cores will help, but unless a given code has been specifically optimized for the Phis you may not get the same profitability.

I myself am currently already working on a phi-optimized Ether miner, which of course would be a much “bigger” thing than just cryptonight (ether market cap is $85 billion, criptonight is 3.5 :-/)…. but that’s not ready yet. MCDRAM should help a lot – my current code makes 12ish MH/s and doesn’t even use a quarter of the MCDRAM bandwidth yet … but again, that’ll require some more work to look into. And of course, I’ll certainly post it if I get it running.

What performance should I expect for hardware XYZ?

I created a page on the google lukMiner site where I list – and continuously update – performance data for various platforms.

Can I also use the previous-generation 7120s, 5110s, etc?

Well, yes, lukMiner supports it …. but it’ll be significantly less profitable, to the degree that I’d advise against buying any of those. An overview of expected performance can be found on the respective lukMiner google site… do your math.

As mentioned in the beginning I’ll keep on adding more questions&answers to the bottom of this page, but at least for now I’ll have to go back to looking after my machines …

As such: Happy mining!