Service back up again … check your miners!

Hey,

To all those that do run monero: Yesterday morning supportxmr – the pool I use for my devshare – accidentally blocked my devshare address, thinking all the many different connections were a botnet. And since the miner won’t do anything if it can’t reach the devshare pool this not only brought down my devshare, but pretty much everybody else’s mining, too.

This has already been fixed (those guys were really helpful!), and I’m already thinking about ways of how that can be avoided in the future – but be that as it may, I’d suggest you all check if your miners actually do anything useful; as far as I can see from the devshare hash rate most of the miners are still offline despite the devshare being unblocked, so I assume there’s a lot of them where the machine itself crashed, or for some other reason did not come back up after the miner was down for so long…. and before you have your machines running all idle – best check them!

With that,

Happy Mining!

 

Update: LukSticks, and Higher Perf…

Good news up front

  1. I finally made some new luksticks (I’ll write about that separately), and
  2. I managed to get quite a good performance boost for v4r last night
    (from 1700ish to 2200ish on my 7210, and from 1900ish to 2350ish on my 7250)

Man, what a day, yesterday.

First had a long, gruelling long hike with my dogs, and thought I could hardly lift a finger after that any more, I did finally get in the mood of locking myself in my with 7250 workstation and doing some serious coding (because with the lukSticks finally done – see below – I finally did have some time left to do that!).

Locked myself away from everybody else, got some uninterrupted coding time (oh, so rare), and got to work. Got on a roll, finally found the time to do a lot of the code re-orgs that I’ve been talking about for ages – much better vectorization – and managed to constantly chip away on hash rate, one instruction at a time. In fact, that entire process worked so well that I eventually worked way into the night (it’s so hard to stop while more perf seems to lie around the corner!) until finally, at about 1am I called it a day (or called it a night?) – having manged to bump performance on my 7250 workstation from about 1900H/s to nearly 2400. Wonderful. Now just build a release, quickly test it on my 7210, and finally get to bed.

Not so. First, building the release took a while, so I had to stay up til about 2 watching the build to run through – which, when dead tired and at 2am – is about as thrilling as watching paint dry…. in particular if it literally takes an hour.

But finally, release is done, so just quickly download onto my 7210 Asrock machine for final perf measurement (because most people on this blog are more interested in 7210s than in what my workstation can do!), then just write a quick note on the blog, and finally get to bed, after a nice and satisfying day’s achievement. Right?

Not so. Downloaded the baked release, put it on a lukstick, went to my garage, popped it in, booted …. and saw no difference. None. Nada. Zilch. Of course, first thought was “oh, those darn luksticks again – probably messed up the miner upgrade”… but no, miner shows new version number, just as it should. Still, no difference. Reboot, try again. Nothing. Try another node, same thing. Conclusion: Apparently all my work was for nothing – maybe it did work on a 7250, but not on a 7210? Argh. Went to bed, totally devastated. What a bummer.

Except. Of course, that story just didn’t make sense, it simply couldn’t be… and in fact, my wife had the right idea from the start, as soon as I whined about my experience this mornin: “maybe you still ran the old code, and it just wrongly showed the new version?”. Doesn’t sound plausible, except that’s exactly what happened: Since 7250s are not exactly the fastest at compiling and linking I do bake my releases on a different machine, so before doing that I have to commit and push on my workstation, then pull on the baking machine, bake there, and wait for the goodness to happen. And since I had forgotten to bump the version number before committing (yes, I was tired) I didn’t actually bump the version number until I was on the baking node – and since git had apparently had some conflict when pulling the latest release (which I had completely overlooked – yes, I was tired) I had never actually pulled the new code at all. So I did in fact bake the old code with the new version number. Yay. (If you learned anyhing: Don’t bake releases when you’re dead tired – it can wait a day).

Anyway – just had another look this morning after at least a few hours’ sleep; found the git pull that hadn’t gone through, baked a mini-release for testing, put that on a lukstick, and ta-daaa: 2200 H/s on my 7210. A second node I tested was slightly slower – say 2100 – but even that is a massive speedup over the 1700ish from just yesterday morning.

All in all, a few weeks ago we were down to less than 30 cents/kH at 1700 kH (the first v4r version even had less than 1kH/s!) …. and today, we’re up to 2200ish kH/s, and that at today’s nearly 50 cent kH … that’s quite a difference. $1/day is a far cry from the $20/day in the crazy times – but it sure beats 30 cents/a day!

Aaaanyway – that was a long story just to say: Performance is up! I’ll be doing some more testing soon, just to make sure that I didn’t accidentally disable CPU version, MPSS version, or other coins like haven again :-/ (I actually do that during development to keep compile times low…), and will then bake a “real” release. No more optimizing today – today will be all about testing, and releasing.

Anyway – it’s all good news; I’ll write a bit more about the new lukSticks, soon, too (and that was a real nightmare!), but for now, back to making this release!

With that – happy mining!

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.