MANUAL - How to setup XMRig nVidia miner for newbies
THIS GUIDE IS FOR 2.4.5 VERSION. In the newer versions, there are some minor differeces in config file.
If you find this usefull, please consider a donation. This was wrote in hours after so many days of learning and testing. :)) Thanks!
BTC: 1FP4Pm4cztjL7QGaj9VFXi1cScsW6UDx8W

See Updates at the end of post.
To see all the parameters, you can export them in a help.txt file with this help.cmd file:

@echo off
xmrig-nvidia.exe -help > help.txt

Before using XMRig in Windows 10 x64bit, you must install in this order:
1.vc-redist all versions from 2012 to present, both x32 and x64;
2.nVidia driver 388.71 - only the graphics diver, and maybe Physix (I heard some miners use it); don't go with 39x driver, it causes problems with some miners (ethminer, etc.). This is the first ver. that supports CUDA 9.1.
3.CUDA 9.1 and all the patches (you don't need Samples and Documentation, only driver and runtime, maybe tools and other stuff).

At the first start of the miner, you will see something like:
"GeForce GTX 1060 3GB - 44x27 6x25 arch:61 SMX:9"
What this means? How to tweak the settings for optimal mining?
Explanations:
44 threads x 27 blocks,
bfactor 6 x bsleep 25,
achitecture 61,
multiprocessors SMX 9.

The settings can be made in the **config.json** file, opened with Notepad. It's a simple text file.
It comes with the miner with a basic config. After first start, it will be replaced by the same file, but with settings sugested by the miner, accordingly with your rig setup. In the regenerated file, you can now modify any settings you want.. threads, blocks, wallet, miner, etc.
Best practice: before starting the miner for the first time, edit your config.json with the basic settings that will remain unaltered in the future, and save it in a BACKUP folder. When you add a GPU or replace it, you should delete the config.json, and replace it with the backup, to let the miner set the new GPU.
Here is an example:
```
{
    "algo": "cryptonight",
    "background": false,
    "colors": true,
    "donate-level": 5,
    "log-file": null,
    "print-time": 300,
    "retries": 90,
    "retry-pause": 10,
    "syslog": false,
    "threads": null,
    "pools": [
        {
            "url": "pool1:port",
            "user": "wallet.worker",
            "pass": "x",
            "keepalive": true,
            "nicehash": false
        },
	{
            "url": "pool2:port",
            "user": "wallet.worker",
            "pass": "x",
            "keepalive": true,
            "nicehash": false
        }
    ]
}
```

A small omision from dev... if you want to add more pools, you must put a comma "," after the "}", so you will have "pools": [ {pool1}, {pool2}, ...]. In the original file, the comma is missing.
BEFORE you start tuning the threads, you must set the other parameters to proper values in the regenerated config.json, after first start.

The **index** is the number of GPU, like GPU 1, GPU 2 etc, as they are identified by the system. The index in miner starts at 0. The numbering in Afterburner or GPU-Z starts at 1. So index 0 means GPU 1, index 1 means GPU 2... etc. GPU1 is the one on the 16x slot, GPU2 is on the other 16x/8x/4x slot. GPU3, 4, 5 and 6 are in the 1x slots starting from cpu. I don't know at what position will be a GPU linked in the M.2 slot. BTW in Windows you can have maximum 8 graphical processors: 8GPU or 7GPU+1cpu hd graphics if you use the HDMI on your motherboard. If you have 6 PCIe slots, you can use the M.2 slots too. They are basicaly PCIexpress x4. In BIOS you must set Above 4G decoding enabled and M.2 slot on PCIe mode.
You can't set **smx** or **arch**; they are automaticaly identified by the miner accordingly with your GPU model. 
**Blocks** must be SMX multiplied by 3. 
Set **bfactor** 8, **bsleep** 100 for GUI systems (Windows), or let the basic 6x25 for others.

You can find the optimal **threads** by starting with a low value, like 12, or 22, or whatever (it can be set in the initial config.json file, see help, and than modified in the regenerated config.json file), start miner, if it crashes, lower value by -2; if dosen't crashes, increase value by +8. When you find the maximum threads value, let the miner run for 5 min, note the hashrate; than lower the value by -2, or a multiple of 2, and note the hashrate eachtime; you will notice an increase in hashrate, than a decrease. Fine tune there with +/-2 untill you get max hashrate. You should be aware of the fact that some pools may ban you for a short period of time, if you connect and disconnect frequently (aka start miner a few times in 5min for ex).
For ex. the optimal threads setting for GTX 1060 3GB is 32. With 6 GPU at 44 threads (the maximum value), I got around 2650 H/s, but with 32 threads, my hashrate jumped to 2863 H/s.
So an optimal config for that GPU should give you this:
"GeForce GTX 1060 3GB - 32x27 8x100 arch:61 SMX:9" in Windows.

**print-time** 300: the hashrate and system health is printed once per 300seconds. 
**retries** 90, **retry-pause** 10: if connection to the pool is lost, the miner awaits for 10 seconds, than retries to reconnect for 90 times (90x10sec=15minutes). The pause must be set no less than 5 sec.
Parameter "variant": should be:
1 for new Cryptonight PoW (Monero7 fork);
0 for old Cryptonight PoW;
-1 for Cryptonight Heavy.
************************************
Update1:
**nVidia GPU mining in Windows 10:**
GPU RAM used for cryptonights: Threads x Blocks x M = RAM MB

Blocks = SMX x 3 (maxim SMX x 8)
M = 2MB - for CN
M = 4MB - for CN heavy
Windows 10 reservs <=20% video RAM (That's one reason why Linux it's better).
Must let some RAM for padding (~100MB).

**From what I experimented and from some wiki descriptions of what threads and block mean,
I think a good rule is to increase blocks more, than to increase threads. 
Threads should be 32, 16 or 8. Blocks should be SMX x 4 or more. 
If you have enough memory, you should use Threads x Blocks = no. of cores in the GPU.
One core takes care of one thread. The value of Threads you specify is fore number of threads in a block.
The value of Blocks is the total number of blocks. 1 multiprocessor (SM) takes care of 1 to 8 blocks. So the number of blocks should be a multiple of SMX (Blocks=SMX x1/x2/...x8).**
For CN-heavy, if you have low memory like in 3GB cards, just use 1/2 no. of Threads from CN.

Ex: For GTX 1060 3GB GPU, in Windows, you have 2490MB available; SMX 9.
The formula goes like this:
CN: 44 x 27 x 2 = 2376 MB (<2490-100)
CNH: 22 x 27 x 4 = 2376 MB (<2490-100)
So, the maximum Threads is 44 for CN (Monero) and 22 for CNH (Sumokoin), with Blocks 27.
************************************
Update 2:
use online config generator/editor https://config.xmrig.com/
...then tweak the Threads on each GPU untill you get the best hashrates.
************************************
Update 3:
For GTX 1060 3GB Hynix, best seetings I found so far in Windows 10 x64:
CN: th x bl bf x bs: **32x36 8x100** or **8x144 8x100** (for me, it gives same hashrates).
32x36 = 1152 total threads (=the no. of cores in this GPU). 1152 x 2MB = 2304MB videoRAM.
CNHeavy: **16x36 8x100** or **4x144 8x100**
16x36 = 576 total threads. 576 x 4MB = 2304MB videoRAM.

8x100 for WINDOWS is imperative!!! With 6x25 you get lower and varriable hashrate. With 8x100 the hashrate is very stable, and is the highest. Dosen't matter if the monitor is plugged in mobo or in GPU. You must use 8x100 on all cards in the rig.
************************************
Update 4:
You can use static diff, but if the pool is configured correctly, you don't need to. And many pools don't support static diff. The pool's var diff algo can work just fine.

Static diff can be easily calculated:
HR x TT = staic diff

HR = your rig's hashrate (for ex. I have an average of 2839 H/s in CN-heavy; I use 2800 for calculation).
TT = target share time in seconds (I understand that this is the time that an accepted share occures). Depending on coin (blocktime, network hashrate, etc) it varries. For CN, 30sec to 60sec TT is recommanded.
This calculator can be found at this address:
https://haven.miner.rocks/#static_diff_calc

So as my example goes, with a rig that has 2800 H/s and a TT of 30s, you have 2800*30=84000 static diff. If you want more accepted shares, but at lower diff, lower the time. Anyway, setting a lower time than recommanded, meaning setting a lower static diff, will not increase your earnings; 2 shares at diff 25000 equals 1 share at diff 50000 as coin reward. Sending more shares with lower diff will just chocke the pool server. This technique is used by evil miners when they attack a pool/coin.
***********************************
Update 5:
Also see this thread for Threads and Blocks for GTX series:
https://github.com/xmrig/xmrig-nvidia/issues/166
***********************************
Update 6:
It seems that CN-Heavy (Sumo, Loki, Haven, etc) likes OC the core too, more than CN (Monero), besides mem, so try to increase GPU Core's freq, and maybe the power limit, to see the difference in hashrate.
***********************************
Update 7:
After days of testing with a 7 x GTX 1060 3GB rig and a RX580 pc, I can share the following findings:
-XMRig nVidia and XMRig AMD hashes better than XMR-Stak, along with a 1% lower fee (30.05.2018)
**gain +1,50%**
-static diff gives more hashes at pool side than var diff (see above how to calculate static diff) 
**gain +0,65%**
-lowering the static diff to half than pools recomandation gives more hashes at pool side (set for 15s)
**gain +1,97%**
-CNHeavy is core and mem intensive, so OC both. Is not so demanding as equihash for power, so you can lower the power limit. For mem OC an AMD card, use HWiNFO64 sensors only mode, to see the mem errors of the GPU and use Claymore ETH miner. You should have 0 mem errors in 30 min.