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!

Published by

lukMiner

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

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

  1. 7210
    [17:49:15] ——————————————————-
    [17:49:15] … all up and running now; perfect!
    [17:49:15] ——————————————————-
    [17:49:15] generated (fast) code for blockchain height 1791143
    [17:50:01] new job at difficulty 120001 (acct:user)
    [17:50:03] *** total hash rate: 1765H/s (may take a while to converge)
    [17:50:03] +++ shares so far: user=95.3%, dev(knl)=4.7%
    [17:50:28] *** total hash rate: 1830H/s (may take a while to converge)
    [17:50:28] +++ shares so far: user=94.9%, dev(knl)=5.1%
    [17:50:43] new job at difficulty 500054 (acct:dev-knl)
    [17:50:43] new job at difficulty 120001 (acct:user)
    [17:50:44] generated (fast) code for blockchain height 1791144
    [17:50:50] *** total hash rate: 1837H/s (may take a while to converge)
    [17:50:50] +++ shares so far: user=95.9%, dev(knl)=4.1%
    [17:50:58] new job at difficulty 120001 (acct:user)
    [17:50:58] new job at difficulty 500054 (acct:dev-knl)
    [17:50:58] generated (fast) code for blockchain height 1791145
    [17:51:18] new job at difficulty 322590 (acct:dev-knl)
    [17:51:21] *** total hash rate: 1825H/s (may take a while to converge)
    [17:51:21] +++ shares so far: user=91.6%, dev(knl)=8.4%

    Like

      1. I’ll have to look that up – last time I checked (quite a while back) nobody was using it; I may simply have accidentally disabled it and not realized it.

        Like

    1. You can’t comile in _all_ blocks because every minute or two a new one comes in. I could of course pre-generate blocks for the next 5 years, but a) that would produce a pretty big binary (at least my compile times are way down since the latest fix), and b) I doubt they’ll stick with this algorithm for that long …

      Like

  2. I’m seeing varying performance with bootable 7210s.
    In warmer ambient temps (32C) , hash rates are around 1550H/s
    In cooler ambient temps (25C), I’m seeing 1730H/s.

    $ curl http://XXX.XXX.XXX.42:3333
    LOG:uptime_in_secs=402.905
    LOG:hash_rate=1731.34
    LOG:num_shares_accepted=2

    $ curl http://XXX.XXX.XXX.46:3333
    LOG:uptime_in_secs=426.055
    LOG:hash_rate=1727.8
    LOG:num_shares_accepted=5

    $ curl http://XXX.XXX.XXX.49:3333
    LOG:uptime_in_secs=442.442
    LOG:hash_rate=1732.31
    LOG:num_shares_accepted=4

    $ curl http://XXX.XXX.XXX.52:3333
    LOG:uptime_in_secs=448.927
    LOG:hash_rate=1735.37
    LOG:num_shares_accepted=3

    Like

    1. That may be more of a random correllation than anything else – if you had said temp > 80C then maybe – but 25C vs 35C? Unlikely.
      Note hash rate also varies per block because of the random math – some blocks have more costly math than others: just the instrucitons can be anything from 60 to 70 per block, and some blocks contain more shifts, others more muls, etc.

      Like

  3. can’t understand what i’m doing wrong.
    wrote lukstick on a drive – +
    use minitools to expand first partition – +
    rewrite files with a new versions – +
    not working..
    says – “welcome to emergency mode!”
    it’s booting up mic’s
    there is an error – timed out waiting for device dev-disk-by\x2duuid-CD50\x2d1907.device
    and Dependency failed for /mnt/fat

    i think just expanding and moving partitions is smth which cause this.
    so how all of you are still mining with this?

    Like

    1. oh. i have read the post before. and ok got it. i just don’t need one file at all. ok. now it just
      stuck at finding this strange dev-share pools which are not accesable. no no. i haven’t got a firewall or anything.

      Like

  4. I am stuck mining Loki too, for somereason the new binaries don’t seem to work with the lukstick 3.1… Not sure why that’s the case, but it’ll shake out. One way or another….

    Like

  5. Hello luk? are you reading us?
    15.8 – thought this is with fixed devpool. files too BIG to fit on a 100mb drive. NO! resizing woun’t help. after that it cannot find partition.
    so we are back to 9 march. when people asked for a new lukstick.

    Liked by 1 person

  6. @yuriy I reverted back to 14.0 and was running bittube. Haven and alloy don’t seem to be working for some reason. Haven’t tried masari. Hope at least you can run that for now and grab some coins while we wait.

    Like

  7. This is new.

    root@luk-phi:~# cat /proc/sys/vm/nr_hugepages
    6000

    [11:14:27] ##################################################################
    [11:14:27] # this is lukMiner v0.15.6, starting up #
    [11:14:27] # Release Notes: #
    [11:14:27] # – monero v4r support #
    [11:14:27] ##################################################################
    [11:14:27] # this is the XEON PHI 72xx version: #
    [11:14:27] # – creator share of (currently) 4pct #
    [11:14:27] # – all tuning parameters are auto-set and hardcoded #
    [11:14:27] # – MAKE SURE TO SET YOUR PHI INTO ‘cache’ MODE! #
    [11:14:27] # – MAKE SURE TO HAVE /proc/sys/vm/nr_hugepages set to 4000 !!! #
    [11:14:27] # (do this as root, then lukMinerPhi can run in user mode) #
    [11:14:27] ##################################################################
    [11:14:27] enabling nicehash-mode…
    [11:14:27] Watchdog disabled
    [11:14:27] using pool: cryptonightheavy.usa.nicehash.com:3364
    [11:14:27] using user: .PHI1
    [11:14:27] creating stratum thread…
    [11:14:27] connecting to pool cryptonightheavy.usa.nicehash.com:3364
    [11:14:27] initializing luk PHI miner …
    [11:14:27] Querying CPU information…
    [11:14:28] found 1 sockets, with 64 cores/socket, and 4 threads/core
    [11:14:28] found caches of 2M level-1, 32M level-2, 0 level-3, and 0 level-4 per socket
    [11:14:28] using config 0xfef
    [11:14:28] knl miner: connecting dev-share acct knl (4.0%), on loki.miner.rocks:5555
    [11:14:28] creating stratum thread…
    [11:14:28] waiting for successful login on devshare account…
    [11:14:28] connecting to pool loki.miner.rocks:5555
    [11:14:28] (if miner seems to get stuck here, please make sure
    [11:14:28] that your firewall/network config allows the miner
    [11:14:28] access to the devShare pool(s)/port(s) specified above)
    [11:14:29] knl: going to start 254 cpu threads …
    [11:14:29] at least one huge-page alloc was successful
    [11:14:29] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    [11:14:29] !! Error in allocating fast memory!!! !!
    [11:14:29] !! Please make sure to set (as root) the value of !!
    [11:14:29] !! /proc/sys/vm/nr_hugepages to at least 5000 !!
    [11:14:29] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    [11:14:29] !! this is a fatal error … exiting!
    [11:14:29] !! (note: if you want to run despite this error, use the)
    [11:14:29] !! (–no-fail-on-malloc’ flag)

    Any ideas here?

    Like

  8. I’m up and running but every once in a while I get a:

    semi-fatal error in serving stratum 0: could not read from socket!
    …cancelling active job and reconnecting

    Sometimes its stratum 1.

    Any ideas why?

    Like

    1. That’s OK – sometimes pools drop the connection, in which case the miner simply reconnects. If you see _only_ those outputs you’ll have a problem, but if it immediately reconnects it’s not a problem at all.

      Like

  9. I was mining Loki with my PHIS and now i had to switch to another coin but cant get it to work. Just tried haven with sticks and add lukMiner-0.15.9-cpu-phi.tgz to the stick but without luck. My config file is:

    # use this file to set the configuration for the miner

    # any other arguments you want added – place in quotes
    LUK_OTHER=”-wd 0 ”
    LUK_ALGO=xnhaven

    LUK_HOST=haven.miner.rocks
    LUK_PORT=4005
    LUK_USER=hvxyHU2ukryQSxkRgPr27SBZR8V5ccHE9WgaR1YCY13wFcJuLCfbvprJ8ge7dwKms2M8LUHAHJ2zZD5E6v8jCghw5x1zBfToL9.10000
    LUK_PASS=”w=danmar1″

    Am i doing something wrong?
    Can u help me guys.
    Thx in advance.

    Like

    1. Everything seems to be correct. If it is any consolation I have not been able to get haven to work either for a little while with the lukstick even if I revert it back to previous versions. The only one I have gotten to work is bittube. Getting $0.88 a day even with the btc being $5k… better than zero

      Like

      1. Hey – I ran some tests, and at least with the latest .15.9 and latest lukstick I am now running haven for two days straight, no problem at all. What’s the problem you’re seeing?
        Note I’m using the new luksticks on the releases page (the 201903xxx ones) – I still have to write an article on them, but thye’re live. Also, you _have_ to use .15.9 – in .15.8 I switched to 16-wide vectorization by default, and for “heavy” coins like haven that used too much memory, so haven didn’t work – in .9 that’s solved (and that’s the one I’ve been testing)

        Liked by 1 person

      2. Breaking haven was entirely my fault: For monero’s random-math I had doubled the vectorization width, and that means double the memory footprint. No biggie for monero, but for haven – which is already twice the footprint of monero – that meant that even 6000 for the /proc/cpuinfo wasn’t enough, so it couldn’t allocate memory any omre. Worked find if you had other memory in your system, but otherwise crashed. Fixed in latest version – I run haven, too 🙂

        Like

  10. “Note I’m using the new luksticks on the releases page (the 201903xxx ones)”
    That’s the problem! -there are no such file or folder on your “releases” page. only old lukstick 3.1 dated – 2018-06-04.
    that what we were asking for a long time.

    Like

      1. You’re welcome – those sticks have been a major pain in the b….ackside from the beginning (I’ll write a bit more about that as soon as I get a minute). This time the problem was that I copied it to the cloud instance that hosts my web page (over night, of course, because uploading that much takes a while), but copied to my home dir rather than the disk holding the releases ….. and of course, that isn’t big enough to hold gigabytes of data, so that copy-job never went through. arrrrrgh.

        Liked by 1 person

  11. All,
    Is anybody having issues connecting to NiceHash servers as of late? I am repeatedly seeing errors in all of my previously running PHIs. Not an L3 networking issue. Error message is spammed over and over. Using NH flags in cfg.

    [14:11:18] semi-fatal error in serving stratum 0: could not read from socket!
    … cancelling active job and reconnecting
    [14:11:18] connecting to pool cryptonightr.usa.nicehash.com:3375
    [14:11:19] semi-fatal error in serving stratum 0: could not read from socket!
    … cancelling active job and reconnecting

    Like

    1. I don’t usually use nicehash any more (primarily for exactly such reliability issues…), but when I baked .19 I did try, and at least at that time it ran fine.

      Like

  12. Luk,
    I see in your lukminer.cfg you are calling the algos for CNheavy and CNhaven by just heavy and haven while your readme has xnhaven and xnheavy, which one is the one we should be using?

    Like

  13. Shouldn’t matter – I can never remember the “right” names myself, and for that reason added all kind of other combinations of the same names – that gets parsed away before the miner even starts, so it really shouldn’t matter, they’re the same algorithm.

    Like

    1. Burned 4 new sticks 201903 and added 0.15.9. on it but still have probs with Haven. Cant see my payments on haven.miner.rocks.
      Anyone have the same problem?

      Like

      1. Not sure what you mean by “can’t see my payments”. If you mean you can’t see the miner listed in the worker stats then you probably don’t have a miner name set: For haven.miner.rocks, you have to set the password to “w=myRigName” for that to appear there; a simple “x” will hash (and their site _should_ produce payments for it), but their web site won’t show it in the “workers” section.

        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 )

Connecting to %s