CCminer(SP-MOD) Modded GPU kernels.

[Bombadil]

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

The commands    --cpu-priority and --cpu-affinity  .... what exactly do they do? It looks self explanatory, but?  thx

yes please - im interested in excatly what they do also ...

#crysx

Get on IRC Also, post right above yours

[1714693751]

1714693751

[1714693751]

1714693751

[1714693751]

1714693751

[chrysophylax]

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

The commands    --cpu-priority and --cpu-affinity  .... what exactly do they do? It looks self explanatory, but?  thx

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

[flipclip]

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

The commands    --cpu-priority and --cpu-affinity  .... what exactly do they do? It looks self explanatory, but?  thx

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.

[chrysophylax]

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

The commands    --cpu-priority and --cpu-affinity  .... what exactly do they do? It looks self explanatory, but?  thx

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

[rednoW]

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 ))

[sp_]

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

The commands    --cpu-priority and --cpu-affinity  .... what exactly do they do? It looks self explanatory, but?  thx

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.

[tbearhere]

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

The commands    --cpu-priority and --cpu-affinity  .... what exactly do they do? It looks self explanatory, but?  thx

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.

Appreciate the explanation... but on my windows bat file the cmd window says unrecognized command. I put in the bat file ...     --cpu-priority 

[duboisi]

I got about 9% of "reject reason: Duplicate share" with Release 32. 750 TI @ YAAMP QUARK.

[neonman]

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....

[bathrobehero]

Which is the latest version that is compatible with compute 3.5 (780 Ti)? Also, if the spreadminer needs testing on the 750 Ti's, let me know.  

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).

[rednoW]

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

[Bombadil]

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

The commands    --cpu-priority and --cpu-affinity  .... what exactly do they do? It looks self explanatory, but?  thx

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.

[rednoW]

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

[Bombadil]

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

Yep Unless you assign it to a specific core (if you have more than one on your rig ), so you still have cores left that won't be locked.
Chances of locking up are low though, but it is possible. One would want to eliminate as much point-of-failures on a continuous mining system.

[bathrobehero]

I run miners on realtime since ever and only cudaminer locked up the system a few times when it crashed a card. I very rarely had that with ccminer.

[Bombadil]

I run miners on realtime since ever and only cudaminer locked up the system a few times when it crashed a card. I very rarely had that with ccminer.

Yeah, but it's still possible That's why we really need --cpu-priority and --cpu-affinity to robustly set them up through cli & scripts. There are already workarounds for this, but built-in is always better, easier and more straight-forward.

[scryptr]

SP_ v32 WILL NOT BUILD ON LINUX--

I tried building it and got dozens of ""t2" defined but not used" errors.  I have no executable left on exit.

I checked "ccminer.cpp" for the correction that flipclip mentioned earlier.  The correction is in place in the git-code.

I am curently running tpruvot's 1.5.2-git release, it has been very stable.  A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident.       --scryptr

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....

[bathrobehero]

I'm wondering what's the difference between intensity and throughput. Spreadminer has throughput (-x) and ccminer has intensity (-i) parameters but I can never go above -i 20 and not because of running out of memory, it's just simply crashes (eg. -i 20 = ~25% VRAM usage and -i 21 = crash). On the other hand I can play around with throughput which lets me use almost all VRAM even though that's not the fastest.

For example, a 780 Ti does around 2.6mh/s with spreadminer by default while using 788 MB VRAM but with a throughput of 30 it does around 3.15 mh/s and uses 2463 MB VRAM. Anyway, I wouldn't mind playing with more parameters if there is a possibility of gains.

[flipclip]

SP_ v32 WILL NOT BUILD ON LINUX--

I tried building it and got dozens of ""t2" defined but not used" errors.  I have no executable left on exit.

I checked "ccminer.cpp" for the correction that flipclip mentioned earlier.  The correction is in place in the git-code.

I am curently running tpruvot's 1.5.2-git release, it has been very stable.  A loss of 5mh/s for the rig, compared to sp_'s best, is painfully evident.       --scryptr

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....

This is a different fix then before.  Unfortunately this is getting out of my realm here but when I made the below fixes, it compiled (Ubuntu 14.04) and quark ran fine (not sure about x15):
In Cudahelper.h (line 68):
FROM:
__device__ __forceinline__ uint64_t REPLACE_HIWORD(const uint64_t &x, const uint32_t y)
TO:
__device__ __forceinline__ uint64_t REPLACE_HIWORD(const uint64_t x, const uint32_t y)

(line 78):
FROM:
__device__ __forceinline__ uint64_t REPLACE_LOWORD(const uint64_t &x, const uint32_t y)
TO:
__device__ __forceinline__ uint64_t REPLACE_LOWORD(const uint64_t x, const uint32_t y)

Compiled and seems to be running fine.

[djm34]

I'm wondering what's the difference between intensity and throughput. Spreadminer has throughput (-x) and ccminer has intensity (-i) parameters but I can never go above -i 20 and not because of running out of memory, it's just simply crashes (eg. -i 20 = ~25% VRAM usage and -i 21 = crash). On the other hand I can play around with throughput which lets me use almost all VRAM even though that's not the fastest.

For example, a 780 Ti does around 2.6mh/s with spreadminer by default while using 788 MB VRAM but with a throughput of 30 it does around 3.15 mh/s and uses 2463 MB VRAM. Anyway, I wouldn't mind playing with more parameters if there is a possibility of gains.

the throughput is the total number of gpu thread used by the algorithm, the intensity lead to that number but is packed differently (don't remember how... power of 2 or something like that