Topic: XMR-stak-JK 2.10.7 Compiled with no devfee (Updated: 2019-8-18) - page 7. (Read 28567 times)

HEY Nvidia miners!

you should seriously check out CryptoDredge instead of XMR-Stak.

I am mining Loki (CN-heavy) with 1070s and I honestly get 20% more hahs rate. I am not the dev or getting paid or anything -  I just think you should check it out.

Compile a success.  Uploaded and first post updated.

lol.


lemme look at the release notes and if its worth going through the rigmarole.....   and at first glance, its a nvidia patch.


Ill try to compile in a little bit.   Hopefully the machine I used to compile last time has no issues.

*edit* compiling.   Seems like its working properly.... but ill know in ~10 min when the machine spits it out for me.  Once that happens, its off to mega and the link will be posted.

Nobody likes a nag. Thanks in arrears.

The XMR-stak 2.5.2 is out. Will you do a compilaiton? Thanks in advance.

I'm still trying to dial everything in with respect to stability and hashrate but as of now I have gone back to 2 threads on the RX 560 rig, using all the other auto-generated parameters except reducing the intensity to less than half what was specified for 1 thread operation (e.g. - 768 for 1 thread goes to 376 for 2 threads). Right now the 4x rig is doing a little over 1800H/s so a massive improvement from the <1600H/s I was getting before! However, I just made this change so now I need to see if it remains stable as I was still having problems with the 1 thread/768 hashrate config (e.g. - hashrate dropped from 400 to 300 on one of the cards sometime over the night). I'm still also still running the RX 570 system with a single thread, worksize of 8, and 768 intensity for now, mainly because I want to see how the other rig behaves before wasting more time fiddling with this one, but I suspect I will be doing the same tweak in a few hours.



Totally agree - I have slowly but surely come around to the idea that it is the energy cost that determines how secure a network is to the first degree, not the absolute hashrate or cost of the mining hardware, per se. One of the coins I was an early supporter of that remained on the original CN algo (DERO) has a network hashrate in the range of 400-500MH/s which works out to around 2000 ASICs and 1.2MW total power draw. Prior to being ASIC'ed it had a network hashrate of around 4MH/s which works out to ~5300 RX 570 GPUs drawing ~800kW of power; hardly an improvement in network security, really, at the cost of alienating a massive number of previously loyal GPU and CPU miners, but I digress...


UPDATE: Hashrate dropped on one of the RX 560 (not the same one) yet again, then the display driver crashed so I decided to DDU 18.6.1 and install 18.5.1, then pixel patch and set all the cards to compute mode. I also stopped using OverDrivenTool and switched over to MSI AB, as v4.5.0 is once again able to handle more than 3 AMD GPUs. I have core set to 1200, mem set to 1900, power limit set to -20%, no change as of yet to core voltage, and total draw is at an unhealthy 375W with hashrate at 1740H/s. So a slight drop in hashrate, a rather higher increase in power draw, but if it's more stable I'll consider that a fair trade overall.

UPDATE 2: Well, I finally gave up on xmr-stak on the 4x RX 560 rig because it kept losing hashrate on one card then outright crashing the driver if I ignored that long enough. Even though I had no luck with SRBMiner 1.6.8 before, I decided to give it another go since I downgraded the driver to 18.5.1 and whaddyaknow, it now works. It's only been running about 10 minutes so far, but delivering a fairly consistent 1775H/s at 356W; so, a little better hashrate and a little lower power draw. Neither are enough of an improvement to justify the 0.85% dev fee, but if it can stay up for longer than 4 hours without needing a reboot then that will be worth the fee to me. I'd like to stick with xmr-stak on both my rigs, but v2.5.1 clearly needs some bug-fixes and/or additional tweaking.

yeah with the upgrade, all the .txt files need to be re-generated (has something to do with formatting and variable fillout for the new variables stored in the file).

My GTX470 is no longer "stable" enough for mining CNv8.   After 4-24 hours, it will cause a cuda crash in the miner.   After removing it from that test rig, no issues.  Odds are that it was just running to hard for its cooling capability;  remember, the 4-series cards were the most power hungry and hottest of any other Nvidia card ever made.


Hashrate seems to be minus 1/4-1/3 or so compared to cnv7 (accounting for my 470 when it was plugged in as well).   So far, no issues with the rx560.



It only made sense that things went the way they did (more power draw, harder on hardware, etc), because its the only way to overwhelm the FPGAs.   They can only have so much responsiveness, and signal timing across a complex FPGA configuration can be quite a chore.    Ive been doing my research and learning on how FPGA's are programmed and work recently;  and.... well, its not an easy task.    My first project personally will probably be making some sort of RISC cpu (maybe a V) on a FPGA and go from there.

notice many cn7 coins raising in value now;    the mass-FPGA holders are probably doing what it takes to squeeze every little pinch out of cn7 that they can before others catch on and they get dumped down to a realistic value... same thing happened during the cn7 swap.

Well, I have to amend my earlier comments about it being painless switching over to 2.5.1... The CN coin I mine - LTHN - just switched to CNv8 and now I am dealing with unrelenting driver and system crashes. I just DDU'ed the 18.5.1 driver and installed/pixel-patched 18.6.1 to no avail. I've also bumped up the core/mem voltages to as high as they were stock (ie - no power saving) and that doesn't seem to help, either.

So I next decided to try SRBMiner and it is crashing the driver, too. I'll keep plugging along for another hour or so, but after that I am just going to stop mining completely.

UPDATE: in a fit of pique I deleted the amd.txt file for both rigs and let xmr-stak automatically generate them. Hashrate is depressingly low - 1020-1060H/s for the RX 570 + Ryzen 5 1600 system (previously ~1180H/s), and <1600H/s for the 4x RX 560 system (previously ~1900H/s), but at least it isn't crashing anymore (and I hope I didn't just jinx myself...).

I have yet to run it on a 1080ti, or hook a power meter up....   I suggest give it a go and share results if anyone has them.   As well as the gpu threads/intensity settings they used =)

JK, what is your 1080Ti speed for the V8 and the power consumption?

Greed is no surprise, people will just mine whatever makes them the most returns.    Alot of them dont have a choice because the income is required pay off the asset cost of the hardware.   Cant really expect any different really, usually evens out in the end depending on which path is more useful to society overall

yes;  I myself am having issues connecting to nanopool with the TLS settings, and instead am having to choose the standard stratum port for more reliable connections.

Other than that, the switchover seems to be going well.

Look at the network hashrate;  Just on nanopool: from 138Gh to just 33Gh after the fork.....   Shows there are some damned greedy people out there.

Hope they like their bricks.

It works, thanks!

try using port 14444

Hi, I'm new with XMR-stack, plz help with the config. I want to mine with CPU and join to nanopool, but cant connect to pool with this error:

Fast-connecting to xmr-eu1.nanopool.org:14433 pool ...
Pool xmr-eu1.nanopool.org:14433 connected. Logging in...
SOCKET ERROR - [xmr-eu1.nanopool.org:14433] RECEIVE error: socket closed

My bat file is this:
xmr-stak.exe -o xmr-eu1.nanopool.org:14433 -u myaddress.cpu_gamer/[email protected] --currency monero -i 0 -p "" -r "" --noNVIDIA --noUAC

and this is my config file:
/ generated by xmr-stak/2.5.1/4e72408ff/master/win/nvidia-amd-cpu/20

/*
 * Network timeouts.
 * Because of the way this client is written it doesn't need to constantly talk (keep-alive) to the server to make
 * sure it is there. We detect a buggy / overloaded server by the call timeout. The default values will be ok for
 * nearly all cases. If they aren't the pool has most likely overload issues. Low call timeout values are preferable -
 * long timeouts mean that we waste hashes on potentially stale jobs. Connection report will tell you how long the
 * server usually takes to process our calls.
 *
 * call_timeout - How long should we wait for a response from the server before we assume it is dead and drop the connection.
 * retry_time   - How long should we wait before another connection attempt.
 *                Both values are in seconds.
 * giveup_limit - Limit how many times we try to reconnect to the pool. Zero means no limit. Note that stak miners
 *                don't mine while the connection is lost, so your computer's power usage goes down to idle.
 */
"call_timeout" : 10,
"retry_time" : 30,
"giveup_limit" : 0,

/*
 * Output control.
 * Since most people are used to miners printing all the time, that's what we do by default too. This is suboptimal
 * really, since you cannot see errors under pages and pages of text and performance stats. Given that we have internal
 * performance monitors, there is very little reason to spew out pages of text instead of concise reports.
 * Press 'h' (hashrate), 'r' (results) or 'c' (connection) to print reports.
 *
 * verbose_level - 0 - Don't print anything.
 *                 1 - Print intro, connection event, disconnect event
 *                 2 - All of level 1, and new job (block) event if the difficulty is different from the last job
 *                 3 - All of level 1, and new job (block) event in all cases, result submission event.
 *                 4 - All of level 3, and automatic hashrate report printing
 *
 * print_motd    - Display messages from your pool operator in the hashrate result.
 */
"verbose_level" : 3,
"print_motd" : true,

/*
 * Automatic hashrate report
 *
 * h_print_time - How often, in seconds, should we print a hashrate report if verbose_level is set to 4.
 *                This option has no effect if verbose_level is not 4.
 */
"h_print_time" : 60,

/*
 * Manual hardware AES override
 *
 * Some VMs don't report AES capability correctly. You can set this value to true to enforce hardware AES or
 * to false to force disable AES or null to let the miner decide if AES is used.
 *
 * WARNING: setting this to true on a CPU that doesn't support hardware AES will crash the miner.
 */
"aes_override" : null,

/*
 * LARGE PAGE SUPPORT
 * Large pages need a properly set up OS. It can be difficult if you are not used to systems administration,
 * but the performance results are worth the trouble - you will get around 20% boost. Slow memory mode is
 * meant as a backup, you won't get stellar results there. If you are running into trouble, especially
 * on Windows, please read the common issues in the README and FAQ.
 *
 * By default we will try to allocate large pages. This means you need to "Run As Administrator" on Windows.
 * You need to edit your system's group policies to enable locking large pages. Here are the steps from MSDN
 *
 * 1. On the Start menu, click Run. In the Open box, type gpedit.msc.
 * 2. On the Local Group Policy Editor console, expand Computer Configuration, and then expand Windows Settings.
 * 3. Expand Security Settings, and then expand Local Policies.
 * 4. Select the User Rights Assignment folder.
 * 5. The policies will be displayed in the details pane.
 * 6. In the pane, double-click Lock pages in memory.
 * 7. In the Local Security Setting – Lock pages in memory dialog box, click Add User or Group.
 * 8. In the Select Users, Service Accounts, or Groups dialog box, add an account that you will run the miner on
 * 9. Reboot for change to take effect.
 *
 * Windows also tends to fragment memory a lot. If you are running on a system with 4-8GB of RAM you might need
 * to switch off all the auto-start applications and reboot to have a large enough chunk of contiguous memory.
 *
 *
 * use_slow_memory defines our behaviour with regards to large pages. There are three possible options here:
 * always  - Don't even try to use large pages. Always use slow memory.
 * warn    - We will try to use large pages, but fall back to slow memory if that fails.
 * never   - If we fail to allocate large pages we will print an error and exit.
 */
"use_slow_memory" : "warn",

/*
 * TLS Settings
 * If you need real security, make sure tls_secure_algo is enabled (otherwise MITM attack can downgrade encryption
 * to trivially breakable stuff like DES and MD5), and verify the server's fingerprint through a trusted channel.
 *
 * tls_secure_algo - Use only secure algorithms. This will make us quit with an error if we can't negotiate a secure algo.
 */
"tls_secure_algo" : true,

/*
 * Daemon mode
 *
 * If you are running the process in the background and you don't need the keyboard reports, set this to true.
 * This should solve the hashrate problems on some emulated terminals.
 */
"daemon_mode" : false,

/*
 * Output file
 *
 * output_file  - This option will log all output to a file.
 *
 */
"output_file" : "",

/*
 * Built-in web server
 * I like checking my hashrate on my phone. Don't you?
 * Keep in mind that you will need to set up port forwarding on your router if you want to access it from
 * outside of your home network. Ports lower than 1024 on Linux systems will require root.
 *
 * httpd_port - Port we should listen on. Default, 0, will switch off the server.
 */
"httpd_port" : 0,

/*
 * HTTP Authentication
 *
 * This allows you to set a password to keep people on the Internet from snooping on your hashrate.
 * Keep in mind that this is based on HTTP Digest, which is based on MD5. To a determined attacker
 * who is able to read your traffic it is as easy to break a bog door latch.
 *
 * http_login - Login. Empty login disables authentication.
 * http_pass  - Password.
 */
"http_login" : "",
"http_pass" : "",

/*
 * prefer_ipv4 - IPv6 preference. If the host is available on both IPv4 and IPv6 net, which one should be choose?
 *               This setting will only be needed in 2020's. No need to worry about it now.
 */
"prefer_ipv4" : true,


Before mxr-stak i use Claymore CPU miner 4.0, but claymore dont update to the new algo :-(

I just got 2.5.1-JK running on two different rigs and it was painless for one and quite painful for the other. The painless one is my "daily driver" desktop with a single RX 570 and Ryzen 5 1600, Windows 10 1803 (ie - just got the fall update), AMD 18.5.1 driver, and MSI AB 4.4.0 set to -25% power, 1200 core and 1900 mem.

The problematic rig is 4x RX 560 2GB on an Onda D1800 6-GPU mining mobo running Windows 10 1709 (ie - NOT updated), AMD 18.6.1 (ie - newer driver) and uses OverDrivenTool to setup the GPUs rather than MSI AB. This rig kept crashing either during the bin file compiling or as soon as it logged into the pool. After wrestling with different things for an hour I finally tried bumping up all the voltages in the mem and core clock profiles by 25mV and that stopped the crashing. Of course, that increases the power consumption slightly, but the hashrate is otherwise the same (this is mining Lethean (formerly IntenseCoin), which is still running what is essential CNv7).

Yeah, AMD backend is still as per normal from what I can tell.    Its working with the RX560 in my test rig consisting of a number of mixed AMD/Nvidia/legacy.

If you have any amd issues, its most likely driver related;  and I would recommend to read the alerts on the fireice-uk github at the source about the driver issues people have had;  I saw the alert when I was reading the release notes before compiling.




For those of you whom can't/won't update driver for some reason; you can download the official release from github, and copy the xmrstak_cuda_backend.dll file, but rename it to xmrstak_cuda_backend_cuda9_2.dll and put it in the folder with my release.   This will give you library support for the older drivers/devices as it was with 2.4.x

I had to do this because if I install nvidia driver 400+, my older legacy devices (GTX 5-series and older) will not load a driver in windows.   The require the 3xx version of the nvidia driver to work....   This copying of fireice-uk's cuda DLL is a good alternative.

Thanks for all the efforts. You said you comipled with CUDA, does the miner also work with AMD cards properly?

Yep =)

Went smoothly.  May have something to do with my laptop I had used previously.  The laptop I used this time took ~17 min to compile... but its also running a steamcmd server.... lol.


First post updated.  New version works.

Nice! Yeah I used cuda 10 as well. Good thing u waited i recompiled 2.5.1 this time luckily it took only 10 min.


If I run into any issues with my miner I have your's to fall back on