Open sandwormusmc opened 6 years ago
I decreased the value passed to -g to 7 and ended up working. Still curious that nvidia-smi shows some memory used by the other cards:
+-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | 0 1305 G /usr/libexec/Xorg 119MiB | | 0 1734 G /usr/bin/gnome-shell 88MiB | | 0 21669 C ./ethdcrminer64 2391MiB | | 0 26538 C nsgminer 581MiB | | 1 21669 C ./ethdcrminer64 2391MiB | | 1 26538 C nsgminer 581MiB | | 2 26538 C nsgminer 7763MiB | +-----------------------------------------------------------------------------+
Adding the --remove-disabled also hid the other cards:
nsgminer --device 2 --neoscrypt -o http://69.27.173.229:19327 -u somevalidwallet -p x -I 15 --worksize 16 -g 7 --syslog --temp-cutoff 80 --auto-fan --gpu-engine 150 --gpu-memclock 500 --gpu-reorder --remove-disabled -T
Could you please explain why you set -g higher than 1 and work size lower than 64?
No particular reason other than not knowing all the intricacies of the various miners out there... I think I got the worksize from a Readme somewhere, and I was playing with the number of threads to try to get a higher hash rate. It seems that values other than these cause issues in my case? I'm using Linux with the 384.98 drivers and 3 GTX 1070s, in case that makes a difference.
-g 1 -w 64 -I 15 should be optimal. I don't think running NSGminer and other miners on the same devices at the same time makes much sense. NeoScrypt is both computationally and memory expensive. By the way, NVML is for GPU monitoring only, so any temperature or clock speed adjustments through the miner are ignored. There are other tools for this purpose.
Yeah that was the thing... I was trying to run ethdcrminer64 on 2 of the other GPUs while running nsgminer on the third at the same time. Since I was using the --device 2 option, I would have assumed it would have only used the third 1070 in my system, however it didn't seem to be doing that and a previously functioning pool didn't credit me for any shares the miner sent it's way. I also tried a different pool thinking it may have been a pool issue however the other one didn't seem to credit me for any shares, either. This was with the logs saying I had quite a few shares sent and accepted, and after about 12 hours passed.
NSGminer inits all GPUs of the platform specified or assumed by default. They may be disabled on start-up, but can be enabled any time and hashing starts immediately. If you're concerned about memory usage, init those GPUs not to be used by NSGminer with the lowest intensity.
The binary still tries to enable all GPUs detected and fails when they are in use by other applications.
E.g. run nsgminer --device 2 on a system with 3 GPUs, nvidia-smi still shows nsgminer occupying memory on all 3 GPUs
Ends up with errors like:
[00:08:10] The network difficulty has been set to 376108 [00:08:10] Stratum from pool 0 detected new block [00:08:10] Error -2: Creating Context. (clCreateContextFromType) [00:08:10] Failed to init GPU thread 26, disabling device 2 [00:08:10] Error -2: Creating Context. (clCreateContextFromType) [00:08:10] Failed to init GPU thread 27, disabling device 2 [00:08:11] Error -2: Creating Context. (clCreateContextFromType) [00:08:11] Failed to init GPU thread 28, disabling device 2 [00:08:11] Stratum from pool 0 requested work restart [00:08:11] Error -2: Creating Context. (clCreateContextFromType) [00:08:11] Failed to init GPU thread 29, disabling device 2
Full command line:
nsgminer --device 2 --neoscrypt -o http://69.27.173.229:19327 -u somevalidwallet -p x -I 15 --worksize 16 -g 10 --syslog --temp-target 80 --auto-fan --gpu-engine 150 --gpu-memclock 500 --gpu-reorder