[ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 25.

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: joblo on February 23, 2018, 06:15:38 PM

Quote from: Nokedli on February 23, 2018, 06:05:05 PM

Quote from: joblo on February 23, 2018, 05:59:24 PM

Quote from: Nokedli on February 23, 2018, 05:34:52 PM

Quote from: joblo on February 23, 2018, 05:23:13 PM

Quote from: Nokedli on February 23, 2018, 05:14:10 PM

still Segmentation fault
same error with other wallet

If it crashes with BLOCK_VERSION_CURRENT 3 and std_longpoll_rpc_call from 3.8.2 I'm stumped.

git + 2 patch, no build modification
http://prntscr.com/iixh31

Ok, undo those changes, start fresh and make the following change to std_get_new_work:

Code:

       if ( ( memcmp( work->data, g_work->data, algo_gate.work_cmp_size )
              && clean_job )
          || ( *nonceptr >= *end_nonce_ptr )
del:      || ( !opt_benchmark && strcmp( work->job_id, g_work->job_id ) ) )
add:      || ( have_stratum && strcmp( work->job_id, g_work->job_id ) ) )
       {

http://prntscr.com/iixtyv

One more shot in the dark, replace std_get_new_work with the old version.

If that doesn't work apply all patches above: replace std_get_new_work and
std_longpoll_rpc_call with old versions, and #define BLOCK_VERSION_CURRENT 3
as per old version.

Ater that I'm really stuck.

Edit: This is really strange. I need you to confirm the previous version still works.

I've reviewed the changes I made. There were none to yescrypt but many other algos
were changed.

I made a few changes to common code:

Increasing the block version count, reverting did not help.

Removing getwork code from longpoll. This was my first suspect if my assumption that
getwork doesn't use longpoll. But reversing that change did not help either.

I made a change to how new work is detected to fix an issue with super-fast algos. But
reversing that didn't fix it either.

I made a change to how shares are detected but that only applies when a solution is found.

The last change was to the API which also doesn't apply.

I'm at a loss to explain it.
some getwork code from longpoll

This problem is bugging me, it defies logic. I'm beginning to suspect it may be an isolated issue.
If anyone else is solo mining with v3.8.3.1 using getwork or gbt please post your results, success
or failure, Please include the algo, your CPU, OS, any deveation from defaults and any relevant
console output.

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: jperser on February 24, 2018, 12:22:10 AM

Quote from: joblo on February 23, 2018, 04:55:28 PM

The API changes were a request, but it seems the old way was preferred. I'll revert the change
if the majority want.

Edit: there are more changes to the API coming, adding solved block count.

I need hashes per second for some of my miners. I had to modify cpuminer-opt every time a new version comes out. Here is the output of my modified API looks like:

Code:

 NAME=cpuminer-opt;VER=3.8.2.1;API=1.0;ALGO=scrypt;CPUS=4;URL=pool-us.bloxstor.com:3002;
KHS=0.01;HS=14.02;ACC=2;REJ=0;ACCMN=0.239;DIFF=0.019401;TEMP=39.9;FAN=0;FREQ=0;
UPTIME=503;TS=1519448273|

The current KHS tag doesn't give me enough resolution, so I added HS. Auto-scaling will break poor coding. Adding this extra tag will also break poor coding (i.e. if Awesome Miner reports the temperature is 0.019401). I assume that the programmers at Awesome Miner know to read the tags, not count the ";". My watchdog code reads all the tags and understands THS, GHS, MHS, KHS, and HS. My code tracks the lowest non-zero value, then displays it in Engineering notation.

Either dynamic scaling or multiple tags will work for me. I have seen multiple tags on another miner, that is why I adopted it. I stopped using Awesome Miner because its limitations (but that is a subject for a different thread).

I don't like being bound to the legacy of others but I have a compromise proposal.

I can restore the kH/s term alongside the new scaled term for a conversion period to allow
mining managers to update their code to support scaled hash rate, then remove the
legacy kH/s permanently. This will ensure H/s is used when appropriate which satisfies
the feature request.

Any downside to this?

jperser

jr. member

Activity: 51

Merit: 5

Quote from: joblo on February 23, 2018, 04:55:28 PM

The API changes were a request, but it seems the old way was preferred. I'll revert the change
if the majority want.

Edit: there are more changes to the API coming, adding solved block count.

I need hashes per second for some of my miners. I had to modify cpuminer-opt every time a new version comes out. Here is the output of my modified API looks like:

Code:

 NAME=cpuminer-opt;VER=3.8.2.1;API=1.0;ALGO=scrypt;CPUS=4;URL=pool-us.bloxstor.com:3002;
KHS=0.01;HS=14.02;ACC=2;REJ=0;ACCMN=0.239;DIFF=0.019401;TEMP=39.9;FAN=0;FREQ=0;
UPTIME=503;TS=1519448273|

The current KHS tag doesn't give me enough resolution, so I added HS. Auto-scaling will break poor coding. Adding this extra tag will also break poor coding (i.e. if Awesome Miner reports the temperature is 0.019401). I assume that the programmers at Awesome Miner know to read the tags, not count the ";". My watchdog code reads all the tags and understands THS, GHS, MHS, KHS, and HS. My code tracks the lowest non-zero value, then displays it in Engineering notation.

Either dynamic scaling or multiple tags will work for me. I have seen multiple tags on another miner, that is why I adopted it. I stopped using Awesome Miner because its limitations (but that is a subject for a different thread).

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: felixbrucker on February 23, 2018, 07:01:47 PM

my personal choice would be to keep the api backwards compatible and just add stuff to it as cpuminer-opt/cpuminer-multi is widely used

if you feel stuff is not needed anymore just mark it deprecated and remove it at a later stage/version, however i don't see the need to remove the KH/s, it's not like it's a million extra bytes, just some few chars

That's ok with me. If there are no objections I'll include it in another bug fix release if the yescrypt/getwork issue
can be solved. I can also include the solution count in the API, it's already coded so it's more work to remove it.

felixbrucker

hero member

Activity: 700

Merit: 500

my personal choice would be to keep the api backwards compatible and just add stuff to it as cpuminer-opt/cpuminer-multi is widely used

if you feel stuff is not needed anymore just mark it deprecated and remove it at a later stage/version, however i don't see the need to remove the KH/s, it's not like it's a million extra bytes, just some few chars

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: felixbrucker on February 23, 2018, 06:23:18 PM

Quote from: joblo on February 23, 2018, 06:02:10 PM

It doesn't make sense to me to put both but if that's what people want I'll do it. I'd like some
opinions from other users.

keep KH/s for backwards compatibility that is

Given that another API change is coming is it worth it to reintroduce kH/s or just take
the compatibility hit for both and get it over with?

felixbrucker

hero member

Activity: 700

Merit: 500

Quote from: joblo on February 23, 2018, 06:02:10 PM

It doesn't make sense to me to put both but if that's what people want I'll do it. I'd like some
opinions from other users.

keep KH/s for backwards compatibility that is

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: Nokedli on February 23, 2018, 06:05:05 PM

Quote from: joblo on February 23, 2018, 05:59:24 PM

Quote from: Nokedli on February 23, 2018, 05:34:52 PM

Quote from: joblo on February 23, 2018, 05:23:13 PM

Quote from: Nokedli on February 23, 2018, 05:14:10 PM

still Segmentation fault
same error with other wallet

If it crashes with BLOCK_VERSION_CURRENT 3 and std_longpoll_rpc_call from 3.8.2 I'm stumped.

git + 2 patch, no build modification
http://prntscr.com/iixh31

Ok, undo those changes, start fresh and make the following change to std_get_new_work:

Code:

       if ( ( memcmp( work->data, g_work->data, algo_gate.work_cmp_size )
              && clean_job )
          || ( *nonceptr >= *end_nonce_ptr )
del:      || ( !opt_benchmark && strcmp( work->job_id, g_work->job_id ) ) )
add:      || ( have_stratum && strcmp( work->job_id, g_work->job_id ) ) )
       {

http://prntscr.com/iixtyv

One more shot in the dark, replace std_get_new_work with the old version.

If that doesn't work apply all patches above: replace std_get_new_work and
std_longpoll_rpc_call with old versions, and #define BLOCK_VERSION_CURRENT 3
as per old version.

Ater that I'm really stuck.

Edit: This is really strange. I need you to confirm the previous version still works.

I've reviewed the changes I made. There were none to yescrypt but many other algos
were changed.

I made a few changes to common code:

Increasing the block version count, reverting did not help.

Removing getwork code from longpoll. This was my first suspect if my assumption that
getwork doesn't use longpoll. But reversing that change did not help either.

I made a change to how new work is detected to fix an issue with super-fast algos. But
reversing that didn't fix it either.

I made a change to how shares are detected but that only applies when a solution is found.

The last change was to the API which also doesn't apply.

I'm at a loss to explain it.
some getwork code from longpoll

Nokedli

newbie

Activity: 15

Merit: 0

Quote from: joblo on February 23, 2018, 05:59:24 PM

Quote from: Nokedli on February 23, 2018, 05:34:52 PM

Quote from: joblo on February 23, 2018, 05:23:13 PM

Quote from: Nokedli on February 23, 2018, 05:14:10 PM

still Segmentation fault
same error with other wallet

If it crashes with BLOCK_VERSION_CURRENT 3 and std_longpoll_rpc_call from 3.8.2 I'm stumped.

git + 2 patch, no build modification
http://prntscr.com/iixh31

Ok, undo those changes, start fresh and make the following change to std_get_new_work:

Code:

       if ( ( memcmp( work->data, g_work->data, algo_gate.work_cmp_size )
              && clean_job )
          || ( *nonceptr >= *end_nonce_ptr )
del:      || ( !opt_benchmark && strcmp( work->job_id, g_work->job_id ) ) )
add:      || ( have_stratum && strcmp( work->job_id, g_work->job_id ) ) )
       {

http://prntscr.com/iixtyv

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: felixbrucker on February 23, 2018, 05:31:40 PM

Quote from: joblo on February 23, 2018, 04:55:28 PM

The API changes were a request, but it seems the old way was preferred. I'll revert the change
if the majority want.

Edit: there are more changes to the API coming, adding solved block count.

actually the requester on github was talking about what i mentioned above: use H/s in addition to KH/s

Quote

Could you modify api.c to also include hashes/sec?

Quote

159 "ALGO=%s;CPUS=%d;URL=%s;KHS=%.2f;HS=%.2f;ACC=%d;REJ=%d;"
163 algo, opt_n_threads, short_url, (double)global_hashrate / 1000.0, (double)global_hashrate,

It doesn't make sense to me to put both but if that's what people want I'll do it. I'd like some
opinions from other users.

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: Nokedli on February 23, 2018, 05:34:52 PM

Quote from: joblo on February 23, 2018, 05:23:13 PM

Quote from: Nokedli on February 23, 2018, 05:14:10 PM

still Segmentation fault
same error with other wallet

If it crashes with BLOCK_VERSION_CURRENT 3 and std_longpoll_rpc_call from 3.8.2 I'm stumped.

git + 2 patch, no build modification
http://prntscr.com/iixh31

Ok, undo those changes, start fresh and make the following change to std_get_new_work:

Code:

       if ( ( memcmp( work->data, g_work->data, algo_gate.work_cmp_size )
              && clean_job )
          || ( *nonceptr >= *end_nonce_ptr )
del:      || ( !opt_benchmark && strcmp( work->job_id, g_work->job_id ) ) )
add:      || ( have_stratum && strcmp( work->job_id, g_work->job_id ) ) )
       {

Nokedli

newbie

Activity: 15

Merit: 0

Quote from: joblo on February 23, 2018, 05:23:13 PM

Quote from: Nokedli on February 23, 2018, 05:14:10 PM

still Segmentation fault
same error with other wallet

If it crashes with BLOCK_VERSION_CURRENT 3 and std_longpoll_rpc_call from 3.8.2 I'm stumped.

git + 2 patch, no build modification
http://prntscr.com/iixh31

felixbrucker

hero member

Activity: 700

Merit: 500

Quote from: joblo on February 23, 2018, 04:55:28 PM

The API changes were a request, but it seems the old way was preferred. I'll revert the change
if the majority want.

Edit: there are more changes to the API coming, adding solved block count.

actually the requester on github was talking about what i mentioned above: use H/s in addition to KH/s

Quote

Could you modify api.c to also include hashes/sec?

Quote

159 "ALGO=%s;CPUS=%d;URL=%s;KHS=%.2f;HS=%.2f;ACC=%d;REJ=%d;"
163 algo, opt_n_threads, short_url, (double)global_hashrate / 1000.0, (double)global_hashrate,

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: Nokedli on February 23, 2018, 05:14:10 PM

still Segmentation fault
same error with other wallet

If it crashes with BLOCK_VERSION_CURRENT 3 and std_longpoll_rpc_call from 3.8.2 I'm stumped.

Nokedli

newbie

Activity: 15

Merit: 0

still Segmentation fault
same error with other wallet

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: Nokedli on February 23, 2018, 04:54:12 PM

still the same error

OK, try going back to block version 3:

Code:

#define BLOCK_VERSION_CURRENT 3

Edit: if that doesn't work go back to std_longpoll_rpc_call from v3.8.2. Those were the only
changes I made that affect solo mining and I made no changes to yescrypt.

joblo

legendary

Activity: 1470

Merit: 1114

The API changes were a request, but it seems the old way was preferred. I'll revert the change
if the majority want.

Edit: there are more changes to the API coming, adding solved block count.

Nokedli

newbie

Activity: 15

Merit: 0

still the same error

wildzer0

newbie

Activity: 28

Merit: 0

The API change breaks Awesome Miner support. Can a compatibility mode be added or is an Awesome Miner update needed?

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: Nokedli on February 23, 2018, 04:25:05 PM

Solo mining looks bad, only for me?
Dual E5-2640 similar error, Manjaro 17 on both

Possibly not. If you can compile please replace function std_longpoll_rpc_call in file
cpu-miner.c with this and let me know what happens.

Code:

json_t *std_longpoll_rpc_call( CURL *curl, int *err, char* lp_url )
{
json_t *val;
char *req = NULL;
if (have_gbt)
{
req = (char*) malloc( strlen(gbt_lp_req) + strlen(lp_id) + 1 );
sprintf( req, gbt_lp_req, lp_id );
}
//TODO this code makes no sense, this first call should be removed.
// also remove conditional expression in second call, no getwork.
// val = json_rpc_call( curl, rpc_url, rpc_userpass, getwork_req, err,
// JSON_RPC_LONGPOLL );
val = json_rpc_call( curl, lp_url, rpc_userpass, req ? req : getwork_req,
err, JSON_RPC_LONGPOLL);
// val = json_rpc_call( curl, lp_url, rpc_userpass, req,
// err, JSON_RPC_LONGPOLL );
free(req);
return val;
}

Topic: [ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 25. (Read 444103 times)