Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 1027. (Read 2347601 times)

process/thread affinity doesn't really exist in OS X so thats why the error is being tossed.

i've been poking around with it too but haven't had much time to really dig at it.

ccminer.cpp:464:26: error: use of undeclared identifier 'GetCurrentProcess'
                SetProcessAffinityMask(GetCurrentProcess(), mask);
                                       ^
ccminer.cpp:466:25: error: use of undeclared identifier 'GetCurrentThread'
                SetThreadAffinityMask(GetCurrentThread(), mask);
                                      ^

/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in compat
make[3]: Nothing to be done for `all-am'.
gcc -DHAVE_CONFIG_H -I.  -I/usr/local/include   -pthread -fno-strict-aliasing  -I/usr/local/cuda/include  -DSCRYPT_KECCAK512 -DSCRYPT_CHACHA -DSCRYPT_CHOOSE_COMPILETIME   -g -O2 -Wall -MT ccminer-crc32.o -MD -MP -MF .deps/ccminer-crc32.Tpo -c -o ccminer-crc32.o `test -f 'crc32.c' || echo './'`crc32.c
mv -f .deps/ccminer-crc32.Tpo .deps/ccminer-crc32.Po
gcc -DHAVE_CONFIG_H -I.  -I/usr/local/include   -pthread -fno-strict-aliasing  -I/usr/local/cuda/include  -DSCRYPT_KECCAK512 -DSCRYPT_CHACHA -DSCRYPT_CHOOSE_COMPILETIME   -g -O2 -Wall -MT ccminer-hefty1.o -MD -MP -MF .deps/ccminer-hefty1.Tpo -c -o ccminer-hefty1.o `test -f 'hefty1.c' || echo './'`hefty1.c
mv -f .deps/ccminer-hefty1.Tpo .deps/ccminer-hefty1.Po
g++ -DHAVE_CONFIG_H -I.  -I/usr/local/include   -pthread -fno-strict-aliasing  -I/usr/local/cuda/include  -DSCRYPT_KECCAK512 -DSCRYPT_CHACHA -DSCRYPT_CHOOSE_COMPILETIME   -g -O2 -MT ccminer-ccminer.o -MD -MP -MF .deps/ccminer-ccminer.Tpo -c -o ccminer-ccminer.o `test -f 'ccminer.cpp' || echo './'`ccminer.cpp
ccminer.cpp:464:26: error: use of undeclared identifier 'GetCurrentProcess'
                SetProcessAffinityMask(GetCurrentProcess(), mask);
                                       ^
ccminer.cpp:466:25: error: use of undeclared identifier 'GetCurrentThread'
                SetThreadAffinityMask(GetCurrentThread(), mask);
                                      ^
ccminer.cpp:1105:4: warning: 'SHA256' is deprecated: first deprecated in OS X
      10.7 [-Wdeprecated-declarations]
                        SHA256((uchar*)sctx->job.coinbase, sctx->job.coi...
                        ^
/usr/include/openssl/sha.h:150:16: note: 'SHA256' has been explicitly marked
      deprecated here
unsigned char *SHA256(const unsigned char *d, size_t n,unsigned char *md...
               ^
ccminer.cpp:1121:74: warning: for loop has empty body [-Wempty-body]
  ...(i = 0; i < (int)sctx->xnonce2_size && !++sctx->job.xnonce2; i++);
                                                                         ^
ccminer.cpp:1121:74: note: put the semicolon on a separate line to silence this
      warning
ccminer.cpp:1360:21: warning: '&&' within '||' [-Wlogical-op-parentheses]
                if ((have_stratum && work.data[0] == 0 || network_fail_f...
                     ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ ~~
ccminer.cpp:1360:21: note: place parentheses around the '&&' expression to
      silence this warning
                if ((have_stratum && work.data[0] == 0 || network_fail_f...
                                  ^
                     (                                )
ccminer.cpp:1377:12: warning: 18 enumeration values not handled in switch:
      'ALGO_ANIME', 'ALGO_BITC', 'ALGO_DEEP'... [-Wswitch]
                        switch (opt_algo) {
                                ^
ccminer.cpp:1634:12: warning: 36 enumeration values not handled in switch:
      'ALGO_ANIME', 'ALGO_BITC', 'ALGO_BITCOIN'... [-Wswitch]
                        switch (opt_algo) {
                                ^
ccminer.cpp:2011:12: warning: 36 enumeration values not handled in switch:
      'ALGO_ANIME', 'ALGO_BITC', 'ALGO_BITCOIN'... [-Wswitch]
                        switch (opt_algo)
                                ^
6 warnings and 2 errors generated.
make[2]: *** [ccminer-ccminer.o] Error 1

So I've been browsing around graphics cards, it's become apparent some manufacturers will use more power for the same clocks of the same make/model of card as another manufacturer.

Say a Asus 970 clocked at the same speed as a Gigabyte 970, the Gigabyte will use more power.

Is there anyway to figure out what card uses more power without actually testing it yourself? I noticed the power connectors are not the same across all cards in the same make and model. However, I have noticed that this isn't always a direct correlation to the power draw either. This can vary wildly too.

For instance some of the 960s have a six pin, others have a eight pin, and still others have two six pins. I don't know if this means a double six pin will pull infinitely more power then a single six pin, but it would hint at it. It could be the single six pins just don't have the right amount of power connectors for the maximum draw as well.

any cards which is superclocked or factory OC will obviously use more power.
If you want to compare check on nvidia website the original design and compare to what propose the manufacturer (and check on the manufacturer as many online just pick the first spec tech they find.

but again, it is probably easier to downclock yourself over a superclocked card than doing the inverse as the bios has been properly tune, so I still think it is better to buy a card designed to use more electricity than the inverse (wouldn't buy a Kingpin edition though...)

So I've been browsing around graphics cards, it's become apparent some manufacturers will use more power for the same clocks of the same make/model of card as another manufacturer.

Say a Asus 970 clocked at the same speed as a Gigabyte 970, the Gigabyte will use more power.

Is there anyway to figure out what card uses more power without actually testing it yourself? I noticed the power connectors are not the same across all cards in the same make and model. However, I have noticed that this isn't always a direct correlation to the power draw either. This can vary wildly too.

For instance some of the 960s have a six pin, others have a eight pin, and still others have two six pins. I don't know if this means a double six pin will pull infinitely more power then a single six pin, but it would hint at it. It could be the single six pins just don't have the right amount of power connectors for the maximum draw as well.

I had a look at the code; here is a quick fix to avoid mining when network fails:

diff --git a/ccminer.cpp b/ccminer.cpp
index c13d617..6c11757 100644
--- a/ccminer.cpp
+++ b/ccminer.cpp
@@ -215,6 +215,7 @@ bool autotune = true;
 bool opt_autotune = true;
 
 bool abort_flag = false;
+bool network_fail_flag = false;
 char *jane_params = NULL;
 
 char *rpc_user = NULL;
@@ -1356,7 +1357,7 @@ static void *miner_thread(void *userdata)
                pthread_mutex_unlock(&g_work_lock);
 
                /* prevent gpu scans before a job is received */
-               if (have_stratum && loopcnt>0 && work.data[0] == 0)
+               if (have_stratum && ((loopcnt>0 && work.data[0] == 0) || network_fail_flag))
                {
                        sleep(1);
                        continue;       
@@ -1903,6 +1904,7 @@ static void *stratum_thread(void *userdata)
                                if (!opt_benchmark)
                                        applog(LOG_ERR, "...retry after %d seconds", opt_fail_pause);
                                sleep(opt_fail_pause);
+                               network_fail_flag = true;
                        }
                }
 
@@ -1913,6 +1915,7 @@ static void *stratum_thread(void *userdata)
                        g_work_time = time(NULL);
                        if (stratum.job.clean)
                        {
+                               network_fail_flag = false;
                                if (!opt_quiet)
                                        applog(LOG_BLUE, "%s %s block %d", short_url, algo_names[opt_algo],
                                                stratum.job.height);

I tested it by creating a REJECT iptable rule to the pool and it worked fine, even though it submitted a lot of expired jobs on resume (maybe the jobs should be cleaned, but it doesn't hurt....).
On a side note, I think the cpu-miner.c file is unused (maybe others as well?).

I don't know about loopcount, it was already there, I just added my new flag.
I've removed it, testing now...

EDIT: works fine, looks like this:
if (have_stratum && (work.data[0] == 0 || network_fail_flag))

its from me except you changed the code...

in mine i only use :
ccminer.cpp:1669:               if (have_stratum && work.data[0] == 0 && !opt_benchmark) {

loopcnt > 0 do the reverse of what you want

I had a look at the code; here is a quick fix to avoid mining when network fails:

diff --git a/ccminer.cpp b/ccminer.cpp
index c13d617..6c11757 100644
--- a/ccminer.cpp
+++ b/ccminer.cpp
@@ -215,6 +215,7 @@ bool autotune = true;
 bool opt_autotune = true;
 
 bool abort_flag = false;
+bool network_fail_flag = false;
 char *jane_params = NULL;
 
 char *rpc_user = NULL;
@@ -1356,7 +1357,7 @@ static void *miner_thread(void *userdata)
                pthread_mutex_unlock(&g_work_lock);
 
                /* prevent gpu scans before a job is received */
-               if (have_stratum && loopcnt>0 && work.data[0] == 0)
+               if (have_stratum && ((loopcnt>0 && work.data[0] == 0) || network_fail_flag))
                {
                        sleep(1);
                        continue;       
@@ -1903,6 +1904,7 @@ static void *stratum_thread(void *userdata)
                                if (!opt_benchmark)
                                        applog(LOG_ERR, "...retry after %d seconds", opt_fail_pause);
                                sleep(opt_fail_pause);
+                               network_fail_flag = true;
                        }
                }
 
@@ -1913,6 +1915,7 @@ static void *stratum_thread(void *userdata)
                        g_work_time = time(NULL);
                        if (stratum.job.clean)
                        {
+                               network_fail_flag = false;
                                if (!opt_quiet)
                                        applog(LOG_BLUE, "%s %s block %d", short_url, algo_names[opt_algo],
                                                stratum.job.height);

I tested it by creating a REJECT iptable rule to the pool and it worked fine, even though it submitted a lot of expired jobs on resume (maybe the jobs should be cleaned, but it doesn't hurt....).
On a side note, I think the cpu-miner.c file is unused (maybe others as well?).

More is coming... If you want a higher hashrate, Please donate some beers.

7.05 MHASH per 750ti.

With djm34's changes we perhaps get 7,5MHASH per 750ti ??


https://ip.bitcointalk.org/?u=http%3A%2F%2Fi57.tinypic.com%2F30nd8hd.jpg&t=554&c=JlfEDP8Vdrvb6A

This is also one of the differences between the consumer line and the Tesla line.  The k80, for example, doesn't ship with a fan:  It's designed to be cooled by the server's airflow, where the air flows directly through the card from front to back (exiting the chassis out the back).  The GTX 980 and Titan draw air from *next to them* - a 90 degree angle from the card - and so stacking them in a dense configuration as in the photo means that their airflow is restricted and they're drawing in air that's already been heated a bit by the back of the card next to them.  The k80 design requires more careful integration with the chassis design, but with big fans, can be stuffed more densely than the consumer lines.

New release.


-Faster quark (optimized bmw-512)
-Added the credit algorithm (from the djm34 branch)
-Added the c11 algorithm(from the tprovot branch, but all kernals are replaced)

1.5.56(sp-MOD) is available here: (22-07-2015)

https://github.com/sp-hash/ccminer/releases/

The sourcecode is available here:

https://github.com/sp-hash/ccminer

But unfortunately, they still do over heat. One card absorbs the heat of the other, and it moves all the way to the last card.