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!
The lukMiner blog 
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%
LikeLike
When I try to mine Stellite (using algo xnstellite in lukstick config file) I get unknown algo error. Any ideas?
LikeLike
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.
LikeLike
I just checked Stellite again on TradeOgre – there’s hardly any activity at all … is this coin still alive?
LikeLike
Does this version include all the blocks compiled in for this fork? Or is that still planned for a future release?
LikeLike
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 …
LikeLike
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
LikeLike
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.
LikeLike
https://ibb.co/Pcxr5bJ
proof that these low temperatures are really possible. watercooled of course
LikeLike
LOL. If you live in the rockies (like I do) then all you need for that right now is a garage :-).
LikeLike
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?
LikeLike
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.
LikeLike
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….
LikeLike
An now I don’t even have that as of today, Loki is done… Oh well. Time to find something else to do.
LikeLiked by 1 person
hi luk：
we have 3500 pcs phi 7120 online，but only 1600h/s/pcs。Can you optimize its performance?
LikeLike
contact me directly, too, please.
LikeLike
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.
LikeLiked by 1 person
@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.
LikeLike
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?
LikeLike
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?
LikeLike
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.
LikeLike
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.
LikeLike
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
LikeLike
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)
LikeLiked by 1 person
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 🙂
LikeLike
“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.
LikeLike
Its there now, thank you so much Luk
LikeLiked by 1 person
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.
LikeLiked by 1 person
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
LikeLike
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.
LikeLike
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?
LikeLike
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.
LikeLike
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?
LikeLike
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.
LikeLike