Bitcoin Forum
April 22, 2019, 01:24:05 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 [174] 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 »
  Print  
Author Topic: [ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner  (Read 419393 times)
joblo
Legendary
*
Offline Offline

Activity: 1148
Merit: 1050


View Profile
February 23, 2018, 10:59:24 PM
 #3461

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


cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
1555939445
Hero Member
*
Offline Offline

Posts: 1555939445

View Profile Personal Message (Offline)

Ignore
1555939445
Reply with quote  #2

1555939445
Report to moderator
1555939445
Hero Member
*
Offline Offline

Posts: 1555939445

View Profile Personal Message (Offline)

Ignore
1555939445
Reply with quote  #2

1555939445
Report to moderator
1555939445
Hero Member
*
Offline Offline

Posts: 1555939445

View Profile Personal Message (Offline)

Ignore
1555939445
Reply with quote  #2

1555939445
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
joblo
Legendary
*
Offline Offline

Activity: 1148
Merit: 1050


View Profile
February 23, 2018, 11:02:10 PM
 #3462

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.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
Nokedli
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
February 23, 2018, 11:05:05 PM
 #3463

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
*
Offline Offline

Activity: 1148
Merit: 1050


View Profile
February 23, 2018, 11:15:38 PM
Last edit: February 24, 2018, 02:07:11 AM by joblo
 #3464

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

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
felixbrucker
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


View Profile WWW
February 23, 2018, 11:23:18 PM
 #3465

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
*
Offline Offline

Activity: 1148
Merit: 1050


View Profile
February 23, 2018, 11:49:50 PM
 #3466

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?

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
felixbrucker
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


View Profile WWW
February 24, 2018, 12:01:47 AM
 #3467

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
*
Offline Offline

Activity: 1148
Merit: 1050


View Profile
February 24, 2018, 02:26:11 AM
 #3468

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.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
jperser
Jr. Member
*
Offline Offline

Activity: 51
Merit: 5


View Profile
February 24, 2018, 05:22:10 AM
 #3469

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


HORIZEN ►►► Bringing Privacy To Life | https://horizen.global/
joblo
Legendary
*
Offline Offline

Activity: 1148
Merit: 1050


View Profile
February 24, 2018, 06:25:21 AM
 #3470

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?

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
joblo
Legendary
*
Offline Offline

Activity: 1148
Merit: 1050


View Profile
February 24, 2018, 06:32:16 AM
 #3471

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.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
4ward
Member
**
Offline Offline

Activity: 451
Merit: 17


View Profile
February 24, 2018, 10:13:36 AM
 #3472

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?

Current api is compatible with Ccminer, so I think changing it would break compatibility with many tools that people may use

If you are reworking the api, then perhaps keeping existing one and activating it with a switch would be the "safe" way,
but it would introduce additional code which I'm not sure you want to maintain.

Perhaps set a cutoff date of when the old API will be discontinued?

I personally mine on my own fork of MegaMiner (https://github.com/yuzi-co/Megaminer) and changing the api is easy for me.


On a sidenote, the feature I would love to see would be continuous hash rate reporting, not only when a share is found (which can take a while on some algos with current),
but reporting it continuously

felixbrucker
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


View Profile WWW
February 24, 2018, 11:16:21 AM
Last edit: February 24, 2018, 11:46:37 AM by felixbrucker
 #3473


Any downside to this?


i use H/s as often as possible and just format it into the appropriate unit on display. A change to not always use H/s and remove KH/s (after some time) will require some conversion to bring it down to H/s first, push it through the app and finally convert it back to whatever is the appropriate format. It wont be a large overhead in programming but it will be unnecessary. I do not know of any app using the api returned hashrate just as is, it wouldn't make sense.

This is how i currently extract data from api:

Code:
 const result = {
accepted: parseFloat(obj.ACC),
acceptedPerMinute: parseFloat(obj.ACCMN),
algorithm: obj.ALGO,
difficulty: parseFloat(obj.DIFF),
hashrate: parseFloat(obj.KHS) * 1000,
miner: `${obj.NAME} ${obj.VER}`,
rejected: parseFloat(obj.REJ),
uptime: obj.UPTIME,
cpus: parseFloat(obj.CPUS),
temperature: parseFloat(obj.TEMP),
  };

this would need to change to this:

Code:
 const units = [
{key: 'PH/s', factor: 5},
{key: 'TH/s', factor: 4},
{key: 'GH/s', factor: 3},
{key: 'MH/s', factor: 2},
{key: 'KH/s', factor: 1},
{key: 'H/s', factor: 0},
  ];
  const unit = units.find(currUnit => obj[currUnit.key]);
  let hashrate = 0;
  if (unit) {
hashrate = parseFloat(obj[unit.key]) * (Math.pow(1000, unit.factor));
  }
  const result = {
accepted: parseFloat(obj.ACC),
acceptedPerMinute: parseFloat(obj.ACCMN),
algorithm: obj.ALGO,
difficulty: parseFloat(obj.DIFF),
hashrate,
miner: `${obj.NAME} ${obj.VER}`,
rejected: parseFloat(obj.REJ),
uptime: obj.UPTIME,
cpus: parseFloat(obj.CPUS),
temperature: parseFloat(obj.TEMP),
  };

With H/s always present it would be just like the first example except i do not need to do
Code:
* 1000

I hope this explains it
Nokedli
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
February 24, 2018, 11:28:54 AM
Last edit: February 24, 2018, 12:47:08 PM by Nokedli
 #3474

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.

http://prntscr.com/ij3bkh
http://prntscr.com/ij3flq
windows 10 local wallet
3.8.2.1 -> http://prntscr.com/ij3qkp

interzone/c11 simply crashed -> 3.8.2.1 http://prntscr.com/ij3pma
BWK/nist5 also crashed -> 3.8.2.1 http://prntscr.com/ij3ou2
Solaris/xevan http://prntscr.com/ij3lnl -> 3.8.2.1 http://prntscr.com/ij3nmc
UTC/scryptjane:14 http://prntscr.com/ij3zoo -> 3.8.2.1 http://prntscr.com/ij40du
on localhost / win 10
Amstellodamois
Newbie
*
Offline Offline

Activity: 168
Merit: 0


View Profile
February 24, 2018, 11:42:10 AM
 #3475

Is there a page of the thread presenting benchmarks?
(Wondering what a really shitty CPU would do - like a G4400)
joblo
Legendary
*
Offline Offline

Activity: 1148
Merit: 1050


View Profile
February 24, 2018, 03:38:41 PM
Last edit: February 24, 2018, 04:38:07 PM by joblo
 #3476


http://prntscr.com/ij3bkh
http://prntscr.com/ij3flq
windows 10 local wallet
3.8.2.1 -> http://prntscr.com/ij3qkp

interzone/c11 simply crashed -> 3.8.2.1 http://prntscr.com/ij3pma
BWK/nist5 also crashed -> 3.8.2.1 http://prntscr.com/ij3ou2
Solaris/xevan http://prntscr.com/ij3lnl -> 3.8.2.1 http://prntscr.com/ij3nmc
UTC/scryptjane:14 http://prntscr.com/ij3zoo -> 3.8.2.1 http://prntscr.com/ij40du
on localhost / win 10

Excellent data, it wil take some time to analyze it.

Edit: I have an initial question about this data that will affect the bug fix release.
You initially reported that yescryptr16 crashed but this shows that it was hashing
and submitting rejects. Were both of these tests with the same code? I need to know
if v3.8.3.1 can hash or if it crashes before starting to hash.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
joblo
Legendary
*
Offline Offline

Activity: 1148
Merit: 1050


View Profile
February 24, 2018, 03:55:26 PM
 #3477


On a sidenote, the feature I would love to see would be continuous hash rate reporting, not only when a share is found (which can take a while on some algos with current),
but reporting it continuously


Wouldn't we all. The problem is the locally calculated hashrate is completely artificial.

To put this in perspective, while testing blakecoin with very high stratum diff the miner was reporting
150 MH/s but a single share submit resulted in the pool displaying 469 Mh/s. It remained at that rate
until the share fell out of the sample window. So the pool reported hashrate went from 0 to 469 and
back to zero every time a share was submitted.

So I have to ask, what exactly do you expect from a continuous hashrate display that has no real
connection to what the pool is seeing?

I would like to see a measure that uses share submission rate and share difficulty so the miner can
make calculations based on real data.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
joblo
Legendary
*
Offline Offline

Activity: 1148
Merit: 1050


View Profile
February 24, 2018, 05:17:56 PM
 #3478

I hope this explains it

Thanks, it's becoming clear. Considering the API output isn't intended to be human readable dynamic
rate scaling is innapropriate. What is most appropriate is just raw H/s and the monitoring app would
be responsible for making it human readable. The hitch is that there is a legacy of using kH/s which
doesn't work for very low hashrate algos.

So I will go back to the initial request and just add H/s alongside kH/s. Although kH/s would be deprecated
it would be maintained indefinitely. Since the dual reporting of hashrate is not visible to the user there is
no harm.

That resolves that issue.

I am also considering adding solution count to the API and console output. A bug fix release shouldn't normally
have a new feature but in this case it makes sense to be to coordinate multiple API changes rather than speading
them over multiple releases.

I will reverse all the GBT changes introduced in 3.8.3 and analyze the data provided by Nokedll in more detail
before making any changes to try to support GBT.

The final issue is the role of the get_new_work changes to the problems seem. The key question is whether it
contributed to the solo mining problems reported. The role of job_id is critical as I discovered using benchmark.
I have to be sure a job_id exists before I test it else I get a NULL pointer deref. There may be 3 tracks through
this function:

1. benchmark where there is no job id to test for new work.

2. stratum where job_id is tested and in some instances the work may also need regeneration

3. getwork/gbt where there may (or may not?) be a job_id to compare but work should never be regenarated
I'm still not sure if testing the job_id is safe for getwork and gbt, I'm hoping for more clarification which will
determine if additional checking is required.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
Nokedli
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
February 24, 2018, 05:25:58 PM
 #3479


http://prntscr.com/ij3bkh
http://prntscr.com/ij3flq
windows 10 local wallet
3.8.2.1 -> http://prntscr.com/ij3qkp

interzone/c11 simply crashed -> 3.8.2.1 http://prntscr.com/ij3pma
BWK/nist5 also crashed -> 3.8.2.1 http://prntscr.com/ij3ou2
Solaris/xevan http://prntscr.com/ij3lnl -> 3.8.2.1 http://prntscr.com/ij3nmc
UTC/scryptjane:14 http://prntscr.com/ij3zoo -> 3.8.2.1 http://prntscr.com/ij40du
on localhost / win 10

Excellent data, it wil take some time to analyze it.

Edit: I have an initial question about this data that will affect the bug fix release.
You initially reported that yescryptr16 crashed but this shows that it was hashing
and submitting rejects. Were both of these tests with the same code? I need to know
if v3.8.3.1 can hash or if it crashes before starting to hash.

1700x or E5-2640 + manjaro + 3.8.3.1 Segmentation fault, no any hash http://prntscr.com/ij6v61 <-original git compiled without any change
8700k + win10 + 3.8.3.1 start working, crash after 1-2 minute, normal hashrate 1khs +/- 5%, windows also from git, not self compiled
I'm using -march=znver1 -DUSE_SPH_SHA tweaks for amd and sandybridge for E5 thats all
joblo
Legendary
*
Offline Offline

Activity: 1148
Merit: 1050


View Profile
February 24, 2018, 05:58:27 PM
 #3480


http://prntscr.com/ij3bkh
http://prntscr.com/ij3flq
windows 10 local wallet
3.8.2.1 -> http://prntscr.com/ij3qkp

interzone/c11 simply crashed -> 3.8.2.1 http://prntscr.com/ij3pma
BWK/nist5 also crashed -> 3.8.2.1 http://prntscr.com/ij3ou2
Solaris/xevan http://prntscr.com/ij3lnl -> 3.8.2.1 http://prntscr.com/ij3nmc
UTC/scryptjane:14 http://prntscr.com/ij3zoo -> 3.8.2.1 http://prntscr.com/ij40du
on localhost / win 10

Excellent data, it wil take some time to analyze it.

Edit: I have an initial question about this data that will affect the bug fix release.
You initially reported that yescryptr16 crashed but this shows that it was hashing
and submitting rejects. Were both of these tests with the same code? I need to know
if v3.8.3.1 can hash or if it crashes before starting to hash.

1700x or E5-2640 + manjaro + 3.8.3.1 Segmentation fault, no any hash http://prntscr.com/ij6v61 <-original git compiled without any change
8700k + win10 + 3.8.3.1 start working, crash after 1-2 minute, normal hashrate 1khs +/- 5%, windows also from git, not self compiled
I'm using -march=znver1 -DUSE_SPH_SHA tweaks for amd and sandybridge for E5 thats all

Thanks, I'll play it safe for now and skip the job_id check for getwork/gbt

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
Pages: « 1 ... 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 [174] 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!