[GUIDE] Mining with xmr-stak-win64 & ar-xmr-stak

[thepitster]

https://github.com/fireice-uk/xmr-stak/releases
xmr-stak-win64 v2.3.0 is an ALL-IN-ONE Command Line Interface (CLI) Monero (and AEON) Miner, it utilizes any CPU(s) or GPU(s) (AMD or nVidia) you have at the ready.

!	DO NOT USE OLD CONFIG FILES

Start in a fresh folder with just the extract contents of the xmr-stak-win64.zip

When you first run 'xmr-stak.exe' it goes thru the process of asking:
Please enter:
- Do you want to use the HTTP interface?
Unlike the screen display, browser interface is not affected by the GPU lag.
If you don't want to use it, please enter 0, otherwise enter port number that the miner should listen on
Configuration stored in file 'config.txt'
Please enter:
- Please enter the currency that you want to mine:
        - aeon7
        - cryptonight
        - cryptonight_lite
        - edollar
        - electroneum
        - graft
        - intense
        - karbo
        - monero7
        - stellite
        - sumokoin

- Pool address: e.g. pool.usxmrpool.com:333
- Username (wallet address or pool login):
- Password (mostly empty or x)
- Rig identifier for pool-side statistics (needs pool support). Can be empty:
- Does this pool port support TLS/SSL? Use no if unknown. (y/N)
- Do you want to use nicehash on this pool? (y/n)
- Do you want to use multiple pools? (y/n)

After that it will create one of more or the configuration files: config.txt, cpu.txt, nvidia.txt, & amd.txt
config.txt is the miner CLI stuff so we go into that one first and I will explain to you the "safe" stuff to tweak or change to suit your needs without causing miner instabilities or lapses.

Code: (config.txt) [Select]


/*
 * 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" : 30,

/*
 * 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.
 *
 * 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.
 *
 * On Linux you will need to configure large page support "sudo sysctl -w vm.nr_hugepages=128" and increase your
 * ulimit -l. To do do this you need to add following lines to /etc/security/limits.conf - "* soft memlock 262144"
 * and "* hard memlock 262144". You can also do it Windows-style and simply run-as-root, but this is NOT
 * recommended for security reasons.
 *
 * Memory locking means that the kernel can't swap out the page to disk - something that is unlikely to happen on a
 * command line system that isn't starved of memory. I haven't observed any difference on a CLI Linux system between
 * locked and unlocked memory. If that is your setup see option "no_mlck".
 */

/*
 * 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.
 * no_mlck - This option is only relevant on Linux, where we can use large pages without locking memory.
 *           It will never use slow memory, but it won't attempt to mlock
 * 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,

/*
 * Buffered output control.
 * When running the miner through a pipe, standard output is buffered. This means that the pipe won't read
 * each output line immediately. This can cause delays when running in background.
 * Set this option to true to flush stdout after each line, so it can be read immediately.
 */
"flush_stdout" : 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" : 43000,

/*
 * 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,
okay above is the entire config.txt, anything from "pool_list" to "print_motd" gernally is nothing there needs to be messed with, you can also  Press 'h' (hashrate), 'r' (results) or 'c' (connection) to print reports.
The "h_print_time" as you can see I set  30 (seconds) instead of the default 60, I like to see my hashrate averages earlier than every minute, but do not set this too low if you gonna mine 100% CPU as lowering this would eat up more of that CPU from the actual mining.
Now the Built In Web server, this was a nice little addition I find handy

Now the Built In Webserver, this was a nice little addition I find handy
It asks to set this from the start and it gives you a nice little web page in order to view your Hash Rates, Results, and Connections

Code: (cpu.txt) [Select]

/*
 * Thread configuration for each thread. Make sure it matches the number above.
 * low_power_mode - This can either be a boolean (true or false), or a number between 1 to 5. When set to true,
 *                  this mode will double the cache usage, and double the single thread performance. It will
 *                  consume much less power (as less cores are working), but will max out at around 80-85% of
 *                  the maximum performance. When set to a number N greater than 1, this mode will increase the
 *                  cache usage and single thread performance by N times.
 *
 * no_prefetch -    Some sytems can gain up to extra 5% here, but sometimes it will have no difference or make
 *                  things slower.
 *
 * affine_to_cpu -  This can be either false (no affinity), or the CPU core number. Note that on hyperthreading
 *                  systems it is better to assign threads to physical cores. On Windows this usually means selecting
 *                  even or odd numbered cpu numbers. For Linux it will be usually the lower CPU numbers, so for a 4
 *                  physical core CPU you should select cpu numbers 0-3.
 *
 * On the first run the miner will look at your system and suggest a basic configuration that will work,
 * you can try to tweak it from there to get the best performance.
 *
 * A filled out configuration should look like this:
 * "cpu_threads_conf" :
 * [
 *      { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 0 },
 *      { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 1 },
 * ],
 * If you do not wish to mine with your CPU(s) then use:
 * "cpu_threads_conf" :
 * null,
 */

"cpu_threads_conf" :
[
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 0 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 1 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 2 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 3 },

],
Okay I will explain this for a WINDOWS system,basically ALL the important stuff comes after "cpu_threads_conf".

So the lines with { "low_power_mode" : true, "no_prefetch" : true, "affine_to_cpu" : 0 }, low_power_mode set to 'true' can give you increase performance in mining.
"affine_to_cpu" can be either a number as you see above, "affine_to_cpu" : 0, 1, 2, 3 etc. or you can set it to 'false' and it is not suppose use that core but appears that it does anyways even when set to 'false', I always recommend if you are gonna mine CPU and GPU on the same machine always leave one CPU core off from mining so it does not lag your GPU down.


I have experienced that if you just remove the core lines IE: { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" :  3}, entirely it will not use the core(s) of the removed config lines or you can comment them out so the CLI ignores them like so:

Code: [Select]

"cpu_threads_conf" :
[
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 0 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 1 },
/*    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" : 2 },
    { "low_power_mode" : false, "no_prefetch" : true, "affine_to_cpu" :  3},
*/
],the /* COMMENT */ tells the CLI to ignore anything between them so this way it will NOT use cores 2 & 3 but use cores 0 & 1 only.

Code: (nvidia.txt) [Select]

/*
 * GPU configuration. You should play around with threads and blocks as the fastest settings will vary.
 * index         - GPU index number usually starts from 0.
 * threads       - Number of GPU threads (nothing to do with CPU threads).
 * blocks        - Number of GPU blocks (nothing to do with CPU threads).
 * bfactor       - Enables running the Cryptonight kernel in smaller pieces.
 *                 Increase if you want to reduce GPU lag. Recommended setting on GUI systems - 8
 * bsleep        - Insert a delay of X microseconds between kernel launches.
 *                 Increase if you want to reduce GPU lag. Recommended setting on GUI systems - 100
 * affine_to_cpu - This will affine the thread to a CPU. This can make a GPU miner play along nicer with a CPU miner.
 * sync_mode     - method used to synchronize the device
 *                 documentation: http://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__DEVICE.html#group__CUDART__DEVICE_1g69e73c7dda3fc05306ae7c811a690fac
 *                 0 = cudaDeviceScheduleAuto
 *                 1 = cudaDeviceScheduleSpin - create a high load on one cpu thread per gpu
 *                 2 = cudaDeviceScheduleYield
 *                 3 = cudaDeviceScheduleBlockingSync (default)
 *
 * On the first run the miner will look at your system and suggest a basic configuration that will work,
 * you can try to tweak it from there to get the best performance.
 *
 * A filled out configuration should look like this:
 * "gpu_threads_conf" :
 * [
 *     { "index" : 0, "threads" : 17, "blocks" : 60, "bfactor" : 0, "bsleep" :  0,
 *       "affine_to_cpu" : false, "sync_mode" : 3,
 *     },
 * ],
 * If you do not wish to mine with your nVidia GPU(s) then use:
 * "gpu_threads_conf" :
 * null,
 */

"gpu_threads_conf" :
[
  // gpu: GeForce GTX 750 Ti architecture: 50
  //      memory: 1955/2048 MiB
  //      smx: 5
  { "index" : 0,
    "threads" : 30, "blocks" : 15,
    "bfactor" : 8, "bsleep" :  25,
    "affine_to_cpu" : true, "sync_mode" : 3,
  },

],
setting  "affine_to_cpu" to true show good results in hashrates, this one here I had to change to get max from my GPU was "bfactor" : 6, it was set to 8 and it did not give me max hashrates but six seems to have done the job just fine, you can also if you like change the "threads" : 32, they default to 64 but you can use any number from 1 to 64 (I suggest not using lower thread number as it may not produce higher hash rates).

Code: (amd.txt) [Select]

/*
 * GPU configuration. You should play around with intensity and worksize as the fastest settings will vary.
 * index         - GPU index number usually starts from 0
 * intensity     - Number of parallel GPU threads (nothing to do with CPU threads)
 * worksize      - Number of local GPU threads (nothing to do with CPU threads)
 * affine_to_cpu - This will affine the thread to a CPU. This can make a GPU miner play along nicer with a CPU miner.
 * strided_index - switch memory pattern used for the scratch pad memory
 *                 2 = chunked memory, chunk size is controlled by 'mem_chunk'
 *                     required: intensity must be a multiple of worksize
 *                 1 or true  = use 16byte contiguous memory per thread, the next memory block has offset of intensity blocks
 *                 0 or false = use a contiguous block of memory per thread
 * mem_chunk     - range 0 to 18: set the number of elements (16byte) per chunk
 *                 this value is only used if 'strided_index' == 2
 *                 element count is computed with the equation: 2 to the power of 'mem_chunk' e.g. 4 means a chunk of 16 elements(256byte)
 * comp_mode     - Compatibility enable/disable the automatic guard around compute kernel which allows
 *                 to use a intensity which is not the multiple of the worksize.
 *                 If you set false and the intensity is not multiple of the worksize the miner can crash:
 *                 in this case set the intensity to a multiple of the worksize or activate comp_mode.
 * "gpu_threads_conf" :
 * [
 * { "index" : 0, "intensity" : 1000, "worksize" : 8, "affine_to_cpu" : false, "strided_index" : true, "mem_chunk" : 2, "comp_mode" : true },
 * ],
 * If you do not wish to mine with your AMD GPU(s) then use:
 * "gpu_threads_conf" :
 * null,
 */

"gpu_threads_conf" : [
  // gpu: Cedar memory:384
  // compute units: 2
  { "index" : 0,
    "intensity" : 176, "worksize" : 8,
    "affine_to_cpu" : false, "strided_index" : 1, "mem_chunk" : 2,
    "comp_mode" : true
  },

],

/*
 * Platform index. This will be 0 unless you have different OpenCL platform - eg. AMD and Intel.
 */
"platform_index" : 1,
So far I have but only one AMD to test this one and it's only a 1GB card but it gives off 90ish H/s of it with the above config in place.

and that is the xmr-stak-win64 Monero Miner.

UPDATE ADDED

They added a pools.txt file to hold information about all your pools, if you decide to use more than one.

Code: (pool.txt) [Select]

/*
 * pool_address    - Pool address should be in the form "pool.supportxmr.com:3333". Only stratum pools are supported.
 * wallet_address  - Your wallet, or pool login.
 * rig_id          - Rig identifier for pool-side statistics (needs pool support).
 * pool_password   - Can be empty in most cases or "x".
 * use_nicehash    - Limit the nonce to 3 bytes as required by nicehash.
 * use_tls         - This option will make us connect using Transport Layer Security.
 * tls_fingerprint - Server's SHA256 fingerprint. If this string is non-empty then we will check the server's cert against it.
 * pool_weight     - Pool weight is a number telling the miner how important the pool is. Miner will mine mostly at the pool
 *                   with the highest weight, unless the pool fails. Weight must be an integer larger than 0.
 *
 * We feature pools up to 1MH/s. For a more complete list see M5M400's pool list at www.moneropools.com
 */
 
"pool_list" :
[
{"pool_address" : "xmr.pool.minergate.com:45560", "wallet_address" : "thepitster@gmail.com", "rig_id" : "PC_NAME", "pool_password" : "x", "use_nicehash" : true, "use_tls" : false, "tls_fingerprint" : "", "pool_weight" : 1 },
],

/*
 * Currency to mine. Supported values:
 *
 *    aeon
 *    cryptonight (try this if your coin is not listed)
 *    cryptonight_lite
 *    edollar
 *    electroneum
 *    graft
 *    intense
 *    karbo
 *    monero7 (use this for Monero's new PoW)
 *    sumokoin
 *
 */

"currency" : "monero7",

UPDATE ADDED

EDIT: added new configs to guide above

[HyperionX]

I like it but I need you to make one change on it @thepitster put my wallet address into there instead of yours

[Afaz]

lol damn nice tutorial. i like how its all laid out and i like that webserver portion. nicehash will tell me when a "worker" goes offline or online eg crashes and restarts...but live monitoring i believe you have to use their paid version. with Nicehash i specifically use the algo "nist5" for gpu, i typically get 68.99-71.04 MH/s opposed to the other algo such as "Lyra2REv2" which i get approx 55-59 MH/s.... Cryptonight seems to be extremely buggy, ill check and its working hashing at a decent amount for CPU around 260-285 h/s but sometimes when it crashes and closes out the stak dos window, it will either not start back up or it will show in the GUI that its hashing but the DOS stak window isnt even open showing new blocks..etc or will take 3 hours before it opens the dos window again(so is it actually hashing???) so lately ive been disabling CPU mining on nicehash, letting minergate CPU mine while nicehash GPU mines BTC using "nist5" algo. The charts show i profit more from "Lyra2REv2" by a small amt of BTC per day but i get higher MH/s and wayyyyyyy more accepted shares per minute... it confuses me... id like to optomize the config file but i feel like id end up breaking it or causing the miner to crash my gpu...

[thepitster]

well fazzy no pain no gain