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 http://www.lukminer.net/releases . 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 README.md at http://www.lukminer.net/releases.

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 http://killallasics.moneroworld.com/ … whoever that was: THANK YOU!

 

Published by

lukMiner

To learn more about me, look at the "About" page on http://lukminer.org

25 thoughts on “lukMiner v0.10.1 with Monero v7 Support”

      1. Oh, forgot to mention … my SYS-5038K-I-NF9 arrives Wednesday so I should be able to give you some stats for the 7290 by next weekend.

        Like

      2. New Supermicro machine is not delivering the performance I was expecting at all. With luk-phi on a 7290 I’m getting 493H/s which is bloody awful.

        Liked by 1 person

      3. I _think_ you already figured it out, but just for reference (in case anybody reads this afterwards): This is almost guaranteed an issue of the miner running in regular DRAM rather than MCDRAM. Go into the BIOS, look for something like “uncore settings” or so, and in that section change the MCDRAM settings to “CACHE” and “QUADRANT”. If you do buy from Asrock Rack they will (well, they promised they would) pre-set these values automatically, but not every other supplier will do that (yet?).

        Liked by 1 person

      4. Further data: 48GB memory installed, running Ubuntu 16.04.4

        If you can verify that it should be getting 3075H/s or so I’ll be sending a very pointy email to my supplier.

        Liked by 1 person

      5. Yes, I’d expect about 3kH/s, give or take. Biggest issue of course will be that MCDRAM has to be turned on (see separate answer on your other question); in addition you probably also want to check with your supplier if that machine uses the right BIOS version. For the Asrock machine they do install a BIOS that gets the 7210s from 2600H/s to around 2800H/s – but I don’t know if non-Asrock suppliers do the same – or even whether they’ve already found that BIOS (cause I ahven’t, either :-/).

        Liked by 1 person

      6. Thanks for your email reply about the bios settings for the X200. Results are in now for the 7290 installed in the Supermicro “Ninja Developer” platform. With luk-phi it’s getting exactly 2,600H/s which, while a little short of the ASRock figure, is still respectable. With luk-cpu using the default 18 threads out of a possible 288 it’s getting 162H/s.

        Liked by 1 person

      7. Almost sure that’s still the “default” slow BIOS. At some point I figured that there’s two different BIOSes with different MCDRAM settings when I compared to otherwise identical systems, one of which was getting only ~2.5kH (with a 7210) and ~2.6K (with a 7250), while another one of the “same” K1SPE motherboards was getting 2.8kH (7210) and 3.0kH (7250) instead. Lots of swapping of hard- and software, and eventually it turned out to be a BIOS version difference.

        Asrock Rack then ran some experiments on their side with the servers, and confirmed; they also found a BIOS for their systems that does get them the good performance, and of course, Asrock now delivers all their Phis with this “better” BIOS – but the “default” intel BIOS is still the slow one… so if you did _not_ buy from Asrock, I’d suggest talk to your supplier and try to get them to “find” that right BIOS for you as well. Unfortunately I do _not_ know where to ge it from, only that I could not find it myself on any public downloads. I know it exists, I even know whom at Intel I could ask that might know; but since this mining is my own toy business (ie, not official intel work) I can’t easily leverage those Intel contacts…. so you’ll have to find it through your supplier (though that said, your supplier may well know who I am, and if they as a Intel customer ask me for help as a Intel employee ….)?

        Either way, I’d _expect_ a 7290 to get more than 2600H/s – at least order 3K, and almost sure all you have to do is update to the “right” BIOS.

        Liked by 1 person

      8. I’d be very interested to know what bios version your K1SPE board is reporting. AMI are usually very reliable but this is a whole new processor so I’m not surprised that there are teething troubles.

        Liked by 1 person

      9. Phew; good question. Will have to look it up, first – but not even sure it’s really a different “version”, or simply a different “build” with just a few different timing settings etc. I’ll try to look it up, but might take a while …

        Liked by 1 person

      10. At this point I’d expect that the faster board still has 1.0b installed. I’ve found the recent bios security updates like the 2.0 bios now being supplied tend to slow the system down. It would be very unusual for there to be two bios versions with the same version number.

        In any case, Supermicro haven’t yet responded to my call for tech support, probably due to Easter. I’ll relay the results when they do.

        Liked by 1 person

  1. I wish there was a forum along with this blog so that we could assist one another on setups, troubleshooting, etc. – this could alleviate a good amount of emails being thrown your way. Maybe when you are done with the other 1000 things..!

    Like

    1. A couple of questions, is the Watchdog function in this version, are you planning on implementing the cool script to start lukminer as in the older versions, and what’s the dev fee? Thanks for your hard work and I really like the older versions.

      Liked by 1 person

      1. Hey, Klee – long time no hear ;-).

        Yes, the watchdog _should_ be in that version, too. If you use the miner directly you should be able to set it via “–watch-dog “; if you use the latest lukStick you should be able to set the “LUK_OTHER” variable to include this setting. If it doesn’t work, please let me know!

        Dev fee is still 1% for CPU and KNC, and 4% for KNL (I think). lukStick itself is free; the miner of course still takes the fee, but the stick itself doesn’t charge any “extra”…

        As to “like the older versions” : I really do hope you’ll like the newer ones, too ;-). If not, let me know – IIRC it was you that recommended the color output (awesome suggestion, BTW!), and alwasy happy to make it better!

        Liked by 1 person

  2. Just tested luk-knc-native with the newly released MPSS 3.8.4 under Win7 with my 3120A card. Performance has dropped ever so slightly, now achieving 540H/s

    Liked by 1 person

  3. luk-knc-native works with the new algo on the 3120A, as does luk-phi on the 7290. Good job. The lower difficulty is nice too. πŸ™‚

    Like

  4. LOL. What is the “IPBC fork”? It’s always so fascinating what kind of coins you guys play around with …. πŸ™‚ No, seriously: Any more information, and I can at least have a look…

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s