v.15.6 – CPU re-activated, and a bit more perf on the Phis

Just uploaded v.15.6 – this was primarily built to re-enable the CPU path, but while looking at that I also realized that I had some pretty egregious spilling code in the KNL path that wasted cycles. In .15.6 this is now fixed. Latest performance:

  • on my 7250, with Ubuntu: +/- 1940 H/s
  • on a 7220A active card: +/- 1840 H/s.
  • 7210 …. still have to check, but not today.

Quite interestingly, at those rates we’re coming back to profitability numbers we haven’t seen in a while: at least if the profit calculators can be belived, at current reduced difficulty 1.9kH is back over 80cents a day. Not as much as during the crazy days (I still remember the $7.50 a day :-/), but way better than the $.20 we’ve seen recently!

With that – happy mining!

v0.15.5 with v4r support is out

Since I did get a few emails asking whether the new version is now out: Yes, it most certainly should be!

I did have some last-minute glitch in that all my testing machines apparently burned through one more of the wires in my home’s electrical wiring (third time :-/), so a few wall sockets lost power, including the one to my router – so the release was baked early yesterday, but didn’t get pushed out right away because the router was dead. Oh, heck, it all happens at the same time. Either way, a single extension cord from anothe room fixed that, and the 0.15.5 version was pushed some time before midnight yesterday night.

And as always, it should be on the releases page, under the following link: http://www.lukminer.net/releases/

A few notes:

  • this version should have code for at least a month or two’s blocks compiled in. I’ll update newer once when it’ll get close to that.
  • In this version I did fully deprecate support for the x100 generation phis. If somebody can convincingly make a case for re-activating that I can still do that – but it’d literally have to be thousands of those x100 generation phis to make that worthwhile, and I doubt those would be profitable.
  • In the latest drop I’ve disabled the CPU version; partly because this reduced the compile time by 4x (yes, CPU build is 3x more expensive because of the different instruction set specializations….), and partly because I thought nobody used that any more. I already got comments to the contrary, so will re-activate that in next drop.
  • I have not yet gotten around to fixing smaller coins like turtle or aeon.

Either way – v0.15.5 is out, and should be working.

With that – happy mining!

v4r is live.

Blockchain height 1788000 has just passed, so if you’re mining monero, you have to use the new miner.

Good news: Performance is roughly where I’d want it to be:

Screenshot from 2019-03-09 11-35-28

Bad new: I did (of course!) introduce a final bug when I built the release last night, so the v0.15.1 version currently on the downloads page will actually crash at that blockchain height. (Apologies – but that happens when you can’t actually test on the ‘real’ blockchain, yet :-/). The fix was literally 10 lines of code … but still – I’m currently baking the new version, and will upload as soon as the make is through.

Oh-kay … v4r, here we come.

Oh-kay – here we are. Two-three days ago I promised a version “probably tomorrow” …. but then – in my hubris – decided to do an apt-update on my KNL development machine … which let to a reboot … during which it realized that the harddisk has some broken sectors … which means it could no longer boot … or even mount the file system on another machine … which …. darn – which better time to lose a harddisk than two days before a release!? Seriously??? Anyway – most of the code was safe under git, it just took forever to reinstall that machine to a state where I could actually develop on it….

Aaaanyway. Release. v4r. I just tagged and built a first internal release with all the right code, including updated version numbers, mpss support, etc. A bit more testing, then I’ll post that public. To make up for lost time in that version I disabled KNC completely, and I think v4r will only run on knl/phi and mpss-knl right now, but at least on my machines it’s working great for both of those configs.

As to performance: What I’m seeing right now is close on 1800-2000 H/s on my 7250, which is pretty good. Exceeeeept…. there’s one caveat: The new thing in v4r is the “randomized code generation”, which means that every block height will run different code during hashing. To do that, there’s basically three options: a) run an interpreter, that just interprets that code sequence on the fly; or b) add a just-in-time compiler to the miner, or c) pre-build all (or at last, a lot) of the upcoming block height’s codes, and link them all together into the same binary. Since I’m not going to add a compiler (well – not yet, at least) I went for a mix of a) and c) : I do include some blocks (for those I get ca 1.8-2kH/s), but for then have a interpreter fall-back for those not built into the binary (and for those, we’ll only get 0.9-1kH/s).

Now the hope is that I’ll eventually ship a binary that has the next few months’ codes all built in – but at least right now I’m having “some minor issues” with the compiler spending literally hours to build a release when too many blocks are built in … and to make matters worse, the test net runs on a different block chain height than the real one will, so I’ll actually have to release different code than what I can test. As such, first version with v4r support might not actually have the right blocks compiled in, yet, and therefore may be running at half the speed. I do have a bigger build with more blocks running in the background …. but …. as I said, it might take a while.

Anyway, two key takeaways:
– v15.1 with v4r support currently building.
– expected performance (once the right binary is our): somewhere around 1800-2000H/s

With that – happy mining!

(PS: Now where did I put that compiler book ….. ?)

v4r update…

Guess I should have waited for about an hour before posting the last article, but that’s how it always is – only after you give up hope do you finally find your breakthrough :-).

Anyway; quick update: Good news – I got code correctness for the upcoming v4r change. It’s still “somewhat less performant than I’d like it to be” (just by an order of magnitude or so, so …. meh…), but from here on out it’s no longer the extreme pain of trying to find bugs in seemingly random code sequences – now it’s only an optimization problem. Really happy – done for today, time for a beer.

Happy mining, guys.

Upcoming Monero xmr-v4r

I know, I know – I’ve been awfully quiet recently …. new job, new responsibilities, plus several paper deadlines I’m working on (for my day job), and of course, the usual domestic emergencies on top of that. Basically, I’ve been so much under water that I hardly even followed developments in crypto-land any more (let alone having had the time for any serious development…) – and basically, if you guys had not pointed it out to me I probably would even have missed the upcoming changes.

Anyway – you guys did send me a lot of messages recently, so at least I got reminded of the upcoming monero algorithm change (sometime next week, if my math is right). And to say so up front: Yes, I am working hard to try and intercept that. Over the last week or two, I finally did dig through some of the forums (monero, reddit,etc), and look through the existing miners (cpuminer, stak, xmrig, monero reference codebase) to at least figure out what this change will be, and let me say, that alone was an adventure – to put it bluntly: how the heck could we – as a community – end up in a state where each and every post and/or miner seems to be calling this by a different name? Cryptonight R? Random? CN-R? CNvR? Monero? And even better, variant 4 and CNv4? … Four? Seriously? When the last one was either v8 or v2, depending on who you asked? Couldn’t we simply have agree on a serial numbering – or if we can’t agree on that, at least year/month (19/3), or a Ubuntu-like CN19.02, or anything that makes sense? We are working on a technology that requires literally millions of highly distributed machines all over the world to run a parallel consensus protocol, in real time, to jointly agree on the state of a distributed blockchain, and we can’t even agree on an f-ing name for the algorithm we run??? Really? Apologies for my ranting, but I just had to get that off my chest.

Anyway – enough of the ranting, there’s a job to do. As said above, I have already looked through all the reference codes, and think I have a pretty good idea of what has to be done. Bad news: It’s a lot. Good news: I got at least some of that done already. Getting it to do the right thing (and to do it fast) – well, that’s another matter, but I’m still optimistic that I’ll be getting there in time. So far I’m already tracking the blockchain height, have hooked up the random-math code generator every time the height changes, have added the plumbing to pass that through to the miners, and am actually already calling at least an interpreter for that code. It’s still producing wrong hashes on the test net, but at least it’s doing something.

Of course, I do realize that having most of it working isn’t good to man or beast – a slightly wrong hash is just as wrong as a completely wrong one – but still: I’m reasonably optimistic that I should be getting those fixed in time. I’ll still have to hook up some sort of compiler for that code, but that should (knock on wood) actually be the simpler task … well, as they always sayd: we’ll see.

Anyway: Long story short – I’m working on it.

With that … happy mining!

PS: Oh, and in case you were wondering about the title: To make at least some partial fun of all the naming mess I decided that for my miner, I’d use a name that tries to digest as many of these random names as possible. So for me, “xmr-v4r” it’ll be!

v.14 and Devshare-Pool changes

V.14 is out as of last night; and can be downloaded from the usual place (http://www.lukminer.net/releases/). At least on my development machine this brings v8 hashrate back to about 2100H/s – not where I expect it to end up, yet, but sure better than what it was before.

Please note I also changed the devShare pool from DwarfPool to cryptoknight.cc – apparently DwarfPool was having some issues last night and was refusing connections (reported by a user, and verified by me as well); if there’s any issues with that let me know!

And finally – a final note to all the inquiries about when a KNC version will come back again: I’m working on it. As said before the changes that went into v8 make the code “easier” to port to KNC (the “explode” and “implode” phases should already work by now), and in particular, to then keep “in sync” with future changes. However – please understand that this is still a very different architecture than the x200 KNL phis – they’re both 16-SIMD machines, and many instructions are shared … but quite a few are missing one or or the other side, and even worse, a few look the same but behave somewhat differently. And of course, a single bit wrong in a single instruction, and the hash is wrong, with a nightmare to debug it …. so this takes some time. Oh, and of course, there’s no OpenCL, auto-vectorizer, or anything like that in the miner, so it’s not “just recompile” for the different architecture. Anyway, the summary is still the same: I’m working on it, it’s coming, but it’ll take some time. :-/

With that – happy mining!