You should have a proper GPU driver installed. Having only CUDA toolkit installed is not enough; moreover, CUDA toolkit is not required unless you're planning to recompile a miner's .cu files.
Make sure your drivers are newer than the minimal supported drivers
Lower you overclock settings, check GPU temperature, update your GPU driver to the latest version. This may seem totally unrelated but surprisingly really helps.
Make sure you don't have two computers with the same name (like
HOME-PC) on your network: sometimes the router's DHCP system settings require that addresses be updated every, say, 2 hours, and the presence of PCs with the identical name causes problems in the IP address re-assignment process. If possible, set a (different) static IP address to each of your rigs.
GPU thread ... crashed: "an illegal memory access was encountered" message
This is usually due to a too high overclock setting, try lowering you GPU OC values.
This seems to be something to do with GPU power saving settings. It is suggested to run "Paint 3D" or some OpenGL enabling application in this case, that should address the issue.
It is possible (use
-t <number of CPU cores to mine at> syntax, i.e.
-t 4) but it doesn't really make sense: CPU mining gives you about +1Mh/s per core, while with even as low-grade a GPU as 1050Ti you're getting around 100 Mh/s on it alone. It can also significantly reduce your GPU mining speed if you have few cores (e.g. 2) and several GPUs: it takes a certain amount of CPU power to manage and load GPU threads, and CPU mining aggressively consumes this resource.
You can try running one miner instance per GPU to have as many miner instances as there are GPUs in the rig. Use the
--opencl-device) option to specify which miner instance controls which GPU in the rig.
The default value (16) is good enough albeit a bit conservative. You may choose to set a higher value, which increases a hashrate (people use values up to 4096), but there comes a question: increasing the workload for a little more hashrate has a tradeoff on submission latency, because work chunks are less granular. Latency of say 0.5 sec usually will not effect the blueness of the mined block, but does reduce the chance of being a chain block, thus reducing the chance of merging red blocks and earning their reward. So the system in essence incentives maximal responsiveness (minimum latency). Thus the optimal value lies in the range of 256...1024.
Consider every time the DAG changes to be a job. This job is updated on average every second. When the user specifies for instance 1% to dev fund, then every 100 jobs the miner mines one job over the dev fund address. If it finds a block during that time, that block's reward goes to dev fund.