I'm gonna keep repeating it: setting to high, higher than high, stoned high, doesn't make a difference. Setting it to realtime does, but might lock up your system.
that's right 
Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 1179. (Read 2347601 times)
soon time to build number 32.
I saw that you hardcoded the realtime priority. I'd advice against it: if for some reason the process loops endlessly, the complete rig will freeze up. Don't do realtime if you're not watching your rigs (and there are many like that around..)
So that's where the command line, like with KlausT and tpruvot comes in handy: --cpu-priority and --cpu-affinity
They set the process priority and affinity
Realtime priority (5) will grant full priority of your miner over any other process on your windows. This boosts your speed a lot, I've seen quark go up by +200kh by using realtime priority.Setting affinity will lock it to certain core(s), so the threads don't hop around too much. If you grant realtime priority to a process, it could lock/freeze up your system (nothing else can kill it), but if you assign it to only 1 out of 4 cores, other processes (like taskmgr) can run on the other 3 cores and kill it, if necessary.
Also, if you run cpuminers next to ccminer, or something else that's cpu intensive like av scan, and they run on the same core(s), they'll interfere with eachother. You don't want to lose 200kh quark per 750ti because some funny CPU only coin you're mining next to it
I've also seen on some cpuminers/algos that setting up a different process per CPU core, and locking them to an assigned core, they perform much better. This doesn't mean it will necessarily boost ccminer speed (at the moment), but it doesn't hurt it at all to say the least. I'd like it mostly because it's much easier to manage your low-level-hardware miners.
In release 32 I have set the default priority to High. I haven't merged the parameter code yet, so you cannot change this. I didn't notice any difference eighter. CPU usage is down to 1% in x11 and 3% in quark.
I'm gonna keep repeating it: setting to high, higher than high, stoned high, doesn't make a difference. Setting it to realtime does, but might lock up your system.
I got about 9% of "reject reason: Duplicate share" with Release 32. 750 TI @ YAAMP QUARK.
it's the pool problem, same on Release 31 
Edit: nevermind me, I thought I only had issues compiling to compute_35 but it was the latest commit's fault (faster x17, the asm stuff in cuda_helper.h).
latest git pull sphash not build on linux:
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
./cuda_helper.h(73): Error: Cannot store to pointer that points to constant memory space
make[2]: *** [x15/cuda_x15_whirlpool.o] Error 1
make[2]: *** Waiting for unfinished jobs....
I got about 9% of "reject reason: Duplicate share" with Release 32. 750 TI @ YAAMP QUARK.
soon time to build number 32.
I saw that you hardcoded the realtime priority. I'd advice against it: if for some reason the process loops endlessly, the complete rig will freeze up. Don't do realtime if you're not watching your rigs (and there are many like that around..)
So that's where the command line, like with KlausT and tpruvot comes in handy: --cpu-priority and --cpu-affinity
They set the process priority and affinity
Realtime priority (5) will grant full priority of your miner over any other process on your windows. This boosts your speed a lot, I've seen quark go up by +200kh by using realtime priority.Setting affinity will lock it to certain core(s), so the threads don't hop around too much. If you grant realtime priority to a process, it could lock/freeze up your system (nothing else can kill it), but if you assign it to only 1 out of 4 cores, other processes (like taskmgr) can run on the other 3 cores and kill it, if necessary.
Also, if you run cpuminers next to ccminer, or something else that's cpu intensive like av scan, and they run on the same core(s), they'll interfere with eachother. You don't want to lose 200kh quark per 750ti because some funny CPU only coin you're mining next to it
I've also seen on some cpuminers/algos that setting up a different process per CPU core, and locking them to an assigned core, they perform much better. This doesn't mean it will necessarily boost ccminer speed (at the moment), but it doesn't hurt it at all to say the least. I'd like it mostly because it's much easier to manage your low-level-hardware miners.
soon time to build number 32.
I saw that you hardcoded the realtime priority. I'd advice against it: if for some reason the process loops endlessly, the complete rig will freeze up. Don't do realtime if you're not watching your rigs (and there are many like that around..)
So that's where the command line, like with KlausT and tpruvot comes in handy: --cpu-priority and --cpu-affinity
They set the process priority and affinity
Realtime priority (5) will grant full priority of your miner over any other process on your windows. This boosts your speed a lot, I've seen quark go up by +200kh by using realtime priority.Setting affinity will lock it to certain core(s), so the threads don't hop around too much. If you grant realtime priority to a process, it could lock/freeze up your system (nothing else can kill it), but if you assign it to only 1 out of 4 cores, other processes (like taskmgr) can run on the other 3 cores and kill it, if necessary.
Also, if you run cpuminers next to ccminer, or something else that's cpu intensive like av scan, and they run on the same core(s), they'll interfere with eachother. You don't want to lose 200kh quark per 750ti because some funny CPU only coin you're mining next to it
I've also seen on some cpuminers/algos that setting up a different process per CPU core, and locking them to an assigned core, they perform much better. This doesn't mean it will necessarily boost ccminer speed (at the moment), but it doesn't hurt it at all to say the least. I'd like it mostly because it's much easier to manage your low-level-hardware miners.
In release 32 I have set the default priority to High. I haven't merged the parameter code yet, so you cannot change this. I didn't notice any difference eighter. CPU usage is down to 1% in x11 and 3% in quark.
I've used this command to start miner in windows
start /realtime ccminer.exe
it gives me more hashes.
Now with release 32 it starts with high but not with realtime priority and gives less hashes.
I need to go to Task Manager and change priority manual to realtime.
No good.
And no improvements for gtx750 ... i think - some worse hashrate even with manual setting to realtime...
So release 32 no good for me ((
Release 31 rulez ))
start /realtime ccminer.exe
it gives me more hashes.
Now with release 32 it starts with high but not with realtime priority and gives less hashes.
I need to go to Task Manager and change priority manual to realtime.
No good.
And no improvements for gtx750 ... i think - some worse hashrate even with manual setting to realtime...
So release 32 no good for me ((
Release 31 rulez ))
soon time to build number 32.
I saw that you hardcoded the realtime priority. I'd advice against it: if for some reason the process loops endlessly, the complete rig will freeze up. Don't do realtime if you're not watching your rigs (and there are many like that around..)
So that's where the command line, like with KlausT and tpruvot comes in handy: --cpu-priority and --cpu-affinity
yes please - im interested in excatly what they do also ...
#crysx
Get on IRC
Also, post right above yours i know - just saw it bomba ... tanx for the explanation ... wont work with linux im assuming ... or it will? ...
damn im slow this morning ... :|
will get on irc when i get back in a few hours - gotta run a few errands for now ...
#crysx
I believe it is windows only, at least in its current iteration. Currently it will not compile on Linux. After doing a git pull, you will need to update ccminer.cpp (line 2231)
FROM:
SetConsoleCtrlHandler((PHANDLER_ROUTINE)ConsoleHandler, TRUE);
#endif
SetPriorityClass(NULL, HIGH_PRIORITY_CLASS);
SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS);
TO:
SetConsoleCtrlHandler((PHANDLER_ROUTINE)ConsoleHandler, TRUE);
SetPriorityClass(NULL, HIGH_PRIORITY_CLASS);
SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS);
#endif
This adds the SetPriorityClass to an if statement for Windows only. Compiled fine on Linux (Ubuntu 14.04) after this. Submitted a pull request.
that sounds great ...
more fine grained control would mean the organic maturing of ccminer ... i like ...
now all that would really be nice is a stats interface ( eg like that of sgminer - that works for cuda in linux also ) that would run rather than the listing of hashrates and 'yay' ...
ill try that later tonight ...
tanx ...
#crysx
soon time to build number 32.
I saw that you hardcoded the realtime priority. I'd advice against it: if for some reason the process loops endlessly, the complete rig will freeze up. Don't do realtime if you're not watching your rigs (and there are many like that around..)
So that's where the command line, like with KlausT and tpruvot comes in handy: --cpu-priority and --cpu-affinity
yes please - im interested in excatly what they do also ...
#crysx
Get on IRC
Also, post right above yours i know - just saw it bomba ... tanx for the explanation ... wont work with linux im assuming ... or it will? ...
damn im slow this morning ... :|
will get on irc when i get back in a few hours - gotta run a few errands for now ...
#crysx
I believe it is windows only, at least in its current iteration. Currently it will not compile on Linux. After doing a git pull, you will need to update ccminer.cpp (line 2231)
FROM:
SetConsoleCtrlHandler((PHANDLER_ROUTINE)ConsoleHandler, TRUE);
#endif
SetPriorityClass(NULL, HIGH_PRIORITY_CLASS);
SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS);
TO:
SetConsoleCtrlHandler((PHANDLER_ROUTINE)ConsoleHandler, TRUE);
SetPriorityClass(NULL, HIGH_PRIORITY_CLASS);
SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS);
#endif
This adds the SetPriorityClass to an if statement for Windows only. Compiled fine on Linux (Ubuntu 14.04) after this. Submitted a pull request.
soon time to build number 32.
I saw that you hardcoded the realtime priority. I'd advice against it: if for some reason the process loops endlessly, the complete rig will freeze up. Don't do realtime if you're not watching your rigs (and there are many like that around..)
So that's where the command line, like with KlausT and tpruvot comes in handy: --cpu-priority and --cpu-affinity
yes please - im interested in excatly what they do also ...
#crysx
Get on IRC
Also, post right above yours i know - just saw it bomba ... tanx for the explanation ... wont work with linux im assuming ... or it will? ...
damn im slow this morning ... :|
will get on irc when i get back in a few hours - gotta run a few errands for now ...
#crysx
soon time to build number 32.
I saw that you hardcoded the realtime priority. I'd advice against it: if for some reason the process loops endlessly, the complete rig will freeze up. Don't do realtime if you're not watching your rigs (and there are many like that around..)
So that's where the command line, like with KlausT and tpruvot comes in handy: --cpu-priority and --cpu-affinity
yes please - im interested in excatly what they do also ...
#crysx
Get on IRC
Also, post right above yours soon time to build number 32.
I saw that you hardcoded the realtime priority. I'd advice against it: if for some reason the process loops endlessly, the complete rig will freeze up. Don't do realtime if you're not watching your rigs (and there are many like that around..)
So that's where the command line, like with KlausT and tpruvot comes in handy: --cpu-priority and --cpu-affinity
yes please - im interested in excatly what they do also ...
#crysx
soon time to build number 32.
I saw that you hardcoded the realtime priority. I'd advice against it: if for some reason the process loops endlessly, the complete rig will freeze up. Don't do realtime if you're not watching your rigs (and there are many like that around..)
So that's where the command line, like with KlausT and tpruvot comes in handy: --cpu-priority and --cpu-affinity
They set the process priority and affinity
Realtime priority (5) will grant full priority of your miner over any other process on your windows. This boosts your speed a lot, I've seen quark go up by +200kh by using realtime priority.Setting affinity will lock it to certain core(s), so the threads don't hop around too much. If you grant realtime priority to a process, it could lock/freeze up your system (nothing else can kill it), but if you assign it to only 1 out of 4 cores, other processes (like taskmgr) can run on the other 3 cores and kill it, if necessary.
Also, if you run cpuminers next to ccminer, or something else that's cpu intensive like av scan, and they run on the same core(s), they'll interfere with eachother. You don't want to lose 200kh quark per 750ti because some funny CPU only coin you're mining next to it
I've also seen on some cpuminers/algos that setting up a different process per CPU core, and locking them to an assigned core, they perform much better. This doesn't mean it will necessarily boost ccminer speed (at the moment), but it doesn't hurt it at all to say the least. I'd like it mostly because it's much easier to manage your low-level-hardware miners.
soon time to build number 32.
I saw that you hardcoded the realtime priority. I'd advice against it: if for some reason the process loops endlessly, the complete rig will freeze up. Don't do realtime if you're not watching your rigs (and there are many like that around..)
So that's where the command line, like with KlausT and tpruvot comes in handy: --cpu-priority and --cpu-affinity
-Less cpu usage, more GPU. x11 down from 20% cpu to 1%
-faster groestl(quark, x11, x13...), mostly on 970/980
nist5 is broken
1.5.32(sp-MOD) is available here: (23-jan-2015)
https://github.com/sp-hash/ccminer/releases/tag/1.5.32
The sourcecode is available here:
https://github.com/sp-hash/ccminer
-faster groestl(quark, x11, x13...), mostly on 970/980
nist5 is broken
1.5.32(sp-MOD) is available here: (23-jan-2015)
https://github.com/sp-hash/ccminer/releases/tag/1.5.32
The sourcecode is available here:
https://github.com/sp-hash/ccminer
Submitted another groestl speedup@github. the 980 is up 200KHASH in quark.
soon time to build number 32.
I saw that you hardcoded the realtime priority. I'd advice against it: if for some reason the process loops endlessly, the complete rig will freeze up. Don't do realtime if you're not watching your rigs (and there are many like that around..)
So that's where the command line, like with KlausT and tpruvot comes in handy: --cpu-priority and --cpu-affinity
soon time to build number 32.
Jump to: