Bitcoin Forum
April 26, 2024, 03:02:17 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 118 119 120 121 122 123 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 192 193 194 195 196 197 »
  Print  
Author Topic: [LOCKED] cpuminer-opt v3.12.3, open source optimized multi-algo CPU miner  (Read 443960 times)
joblo (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1114


View Profile
February 05, 2018, 05:24:35 PM
Last edit: February 05, 2018, 09:38:00 PM by joblo
 #3341

So I finally got some time to test this and confirm the results I saw
I have mined to 2 wallets on http://pool.threeeyed.info/
Running 2 miners in parallel, with 2 threads each, on 4 core cpu, with manually defined affinity in task manager to make sure they use separate cores

Running for 2 hours with no interruptions, here is the results
multi gave double the profit, and reported more or less correct speed
opt reported speed was about 4 times higher that the received speed on pool

cpuminer-opt 3.8.0:
Screenshot:
http://prntscr.com/iafztr
Miner output:
https://text-share.com/view/e95290d4
Pool link:
http://pool.threeeyed.info/?address=RMuoJFg2qDSxEaDaCZG24Yhn3k99gW6SkF

cpuminer-multi-1.3.3
Screenshot:
http://prntscr.com/iafzkk
Miner output:
https://text-share.com/view/59a010b3
Pool link:
http://pool.threeeyed.info/?address=RJmz1bAtpa4hXrX7LC82cVikoB4gpd5L52

That's not good. I have confirmed the hash rate calculation for other 4way algos
so this seems specific to x16r. The fact that the pool-side hash rate lower than multi
suggests that only one of the 4 lanes is finding shares and the other three are finding
nothing, not even rejects.

There is a simple test I can do to confirm the lane issue but I'm pretty deep in debugging
more optimizations right now so I can't follow up immediately. I'll try to find a window to
do this test (I'll use your addresses at 3eyed for testing) then decide how to move forward.

Thanks for the hard work.

Edit: confirmed, only lane 0 submitting shares.

AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
https://bitcointalk.org/index.php?topic=5226770.msg53865575#msg53865575
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
1714100537
Hero Member
*
Offline Offline

Posts: 1714100537

View Profile Personal Message (Offline)

Ignore
1714100537
Reply with quote  #2

1714100537
Report to moderator
The trust scores you see are subjective; they will change depending on who you have in your trust list.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
guytechie
Hero Member
*****
Offline Offline

Activity: 677
Merit: 500


View Profile
February 05, 2018, 05:39:19 PM
 #3342

Hi guys, I have a question about the --cpu-afinnity switch.  Yeah, I know, yet another one.

I tried searching for the answers here, but thread is so long, the search is coming up with stuff that didn't help.

I have a TR 1950x and a Ryzen 7 1700/

Without messing with the affinity switch, just halving the # of threads doesn't actually distribute the load to all physical cores.  It just goes from cpu 0 to cpu 8 (in the case of Ryzen 1700).  This is apparent with Cryptonight, which hashes much faster when halving the # of threads to just the physical cores (not the virtual ones).

--cpu-affinity 1 works perfectly with the TR 1950x.  It alternates the load from cpu 0, 2, 4, etc.  However, the behavior is not the same on the Ryzen 7 1700.  Instead, it would just run all threads on cpu 0 only.

Is there a different affinity mask for Ryzen 7 1700s specifically?

Put something in my tip jar if I made your day. Smiley
BTC:
1MkmBHDjonAFXui6JEx9ZmEemfMtUo9Cmu
joblo (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1114


View Profile
February 05, 2018, 09:13:51 PM
 #3343

Hi guys, I have a question about the --cpu-afinnity switch.  Yeah, I know, yet another one.

I tried searching for the answers here, but thread is so long, the search is coming up with stuff that didn't help.

I have a TR 1950x and a Ryzen 7 1700/

Without messing with the affinity switch, just halving the # of threads doesn't actually distribute the load to all physical cores.  It just goes from cpu 0 to cpu 8 (in the case of Ryzen 1700).  This is apparent with Cryptonight, which hashes much faster when halving the # of threads to just the physical cores (not the virtual ones).

--cpu-affinity 1 works perfectly with the TR 1950x.  It alternates the load from cpu 0, 2, 4, etc.  However, the behavior is not the same on the Ryzen 7 1700.  Instead, it would just run all threads on cpu 0 only.

Is there a different affinity mask for Ryzen 7 1700s specifically?

Your tr 1950x with cpu-affinity 1 makes no sense, the Ryzen is behaving as expected.
Affinity of 1 means that only CPU 0 will be used for all threads..
There should be as many bits set in the affinity mask as there are threads to run,
If there are fewer bits than threads you start doubling up threads on logical cores, very bad.

The only affinity that might make sense with 8 threads is either 0x5555 or 0xaaaa.
The only difference is even vs odd numbered cores. Some think 0xaaaa is better
because it leaves core 0 free. I don't know if it matters, but I digress.

How do you know cpus 0 to 8 are not on seperate physical cores? Check the CPU core
temperatures with 1/2 threads and default affinity and confirm all cores are the same relative temperature.
If 4 cores are hot and 4 cool your assumption was correct and you need to use affinity to
spread the threads over all the cores.

With your TR1950x you would use a mask of 0x55555555 for 16 threads, IF YOU NEED IT.

And remember NEVER USE AFFINITY WITH DEFAULT THREADS.

Please provide a full report to clear up all this confusion.

I don't have any idea if TR maps logical cores differently than Ryzen, or differently than Intel.
If it does blame AMD. I don't have any problem with Intel CPUs, never use affinity.

Some people tend to use decimal for affinity. Those that do probably don't know what they
are doing because affinity is a bitmap. If you don't understand a bitmap represented in hexadecimal
it's even more difficult to understand it in decimal.

AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
https://bitcointalk.org/index.php?topic=5226770.msg53865575#msg53865575
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
guytechie
Hero Member
*****
Offline Offline

Activity: 677
Merit: 500


View Profile
February 05, 2018, 10:11:07 PM
Last edit: February 05, 2018, 10:33:57 PM by guytechie
 #3344

Your tr 1950x with cpu-affinity 1 makes no sense, the Ryzen is behaving as expected.
Affinity of 1 means that only CPU 0 will be used for all threads..
There should be as many bits set in the affinity mask as there are threads to run,
If there are fewer bits than threads you start doubling up threads on logical cores, very bad.

I don't know what to tell you.  For some reason, this is happening on the TR CPU.

So for some reason, that's expected behavior on my Ryzen, but not the TR.

As for WHY I did "1", it's because I read somewhere on this thread that value means to alternate every other core starting with CPU 0.  Misinformation, perhaps, but it was the only info I had to go on until now.

Quote
The only affinity that might make sense with 8 threads is either 0x5555 or 0xaaaa.
The only difference is even vs odd numbered cores. Some think 0xaaaa is better
because it leaves core 0 free. I don't know if it matters, but I digress.

Thanks.  With that info, I can reverse-conclude that the hex value is just binary for 0101010101010101 (representing 16 threads).

I was wondering how that worked.

I will try this and get back to you (not in a position to test right now).

Quote
How do you know cpus 0 to 8 are not on seperate physical cores? Check the CPU core
temperatures with 1/2 threads and default affinity and confirm all cores are the same relative temperature.
If 4 cores are hot and 4 cool your assumption was correct and you need to use affinity to
spread the threads over all the cores.

I know with Cryptonight because something about making sure they're on the right CCX so they don't share cache - or something of that matter.  Without doing anything, the hashrate is terrible.  After getting it to alternate cores, hashrate was 5 to 6x faster.

I used xmr-stak to verify. Their miner was easier to mine Cryptonight.  They alternated the cores - can verify with monitoring tools such as HWInfo, Task Manager, and CoreTemp.

I want to use cpuminer-opt because of xmr-stak's dev fee.  Using cpuminer-opt, I noticed without any affinity settings (just the thread setting), they were not alternating - AND the hasrate was much lower.

Quote
With your TR1950x you would use a mask of 0x55555555 for 16 threads, IF YOU NEED IT.

Thanks for this.  Will try and report back.

Quote
And remember NEVER USE AFFINITY WITH DEFAULT THREADS.

Of course - default threads usually mean 100% of CPU, so no reason to set affinity.

Quote
Please provide a full report to clear up all this confusion.

Will do.

Quote
I don't have any idea if TR maps logical cores differently than Ryzen, or differently than Intel.
If it does blame AMD. I don't have any problem with Intel CPUs, never use affinity.

I'm not sure, but I think with my Haswell, it might just automatically alternate (use physical cores) without the need of setting affinity (just set the threads).  I haven't had the time to play with Cryptonight on my Haswell yet.  I'll check it out when I have time and let you know.

Quote
Some people tend to use decimal for affinity. Those that do probably don't know what they
are doing because affinity is a bitmap. If you don't understand a bitmap represented in hexadecimal
it's even more difficult to understand it in decimal.

Does it work with binary values?

Code:
--cpu-affinity 1010101010101010

UPDATE:
With 0x5555 and 8 threads for Ryzen (or 0x55555555 and 16 threads for TR), I get an overall 60-65% CPU utilization, and the load is spread evenly across all cores (virtual and physical).

What's weirder is on the TR, I revert back to "1", and it behaves the exact same!  WTF is going on?

Hashrate using 16 threads (out of 32) - no affinity settings:
Around 400 H/s

Hashrate using 16 threads - affinity set to 1 (previously):
Around 850 H/s

Hashrate using 16 threads - affinity 0x55555555:
Around 600 H/s

Hashrate using after going back to affinity 1, still 16 threads:
Around 600 H/s



I tried also on the Ryzen.  So affinity 1 = only mines on core 0.  With Affinity set to 0x5555 (8 threads out of 16), around 60% cpu utilization spread across all cores (same behavior as TR).


I'm baffled.

Put something in my tip jar if I made your day. Smiley
BTC:
1MkmBHDjonAFXui6JEx9ZmEemfMtUo9Cmu
joblo (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1114


View Profile
February 05, 2018, 10:59:11 PM
 #3345

I'm baffled.

If you ignore the TR with affinity 1 it makes sense. I don't understand that one. Maybe the TR
has some kind of override that won't let you set stupid affinity. Wink

The CI only accepts decimal or hex at this time. I don't think it's worth the effort to support it
as converting from binary to hex is trivial.

Regarding the technicalities of the CCX and modular cache, it has nothing to do with the logical
CPU mapping. AMD could just have easily mapped them so that cores 0 to n/2-1 would all be on different
physical cores and n/2 to n-1 would be SMT (hyperthreaded). That's how it works on my Haswell.

You seem to confirm that AMD has messed things up, not only compared to Intel but within their own
products.

The need to use alternating cores with Ryzen seems consistent, TR should be the same. I don't know
if it carries to their older CPUs, or their servers.

AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
https://bitcointalk.org/index.php?topic=5226770.msg53865575#msg53865575
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
guytechie
Hero Member
*****
Offline Offline

Activity: 677
Merit: 500


View Profile
February 05, 2018, 11:50:32 PM
 #3346

I'm baffled.

If you ignore the TR with affinity 1 it makes sense. I don't understand that one. Maybe the TR
has some kind of override that won't let you set stupid affinity. Wink

The CI only accepts decimal or hex at this time. I don't think it's worth the effort to support it
as converting from binary to hex is trivial.

Regarding the technicalities of the CCX and modular cache, it has nothing to do with the logical
CPU mapping. AMD could just have easily mapped them so that cores 0 to n/2-1 would all be on different
physical cores and n/2 to n-1 would be SMT (hyperthreaded). That's how it works on my Haswell.

You seem to confirm that AMD has messed things up, not only compared to Intel but within their own
products.

The need to use alternating cores with Ryzen seems consistent, TR should be the same. I don't know
if it carries to their older CPUs, or their servers.

"More research is needed." (c)

Put something in my tip jar if I made your day. Smiley
BTC:
1MkmBHDjonAFXui6JEx9ZmEemfMtUo9Cmu
joblo (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1114


View Profile
February 06, 2018, 03:21:35 AM
 #3347

cpuminer-opt-3.8.0.1 fixes X16R AVX2 low hashrate.

https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.8.0.1

There were actually 2 bugs. The first one prevented any shares from being submitted from
lanes 1 to 3 which hid the second bug that caused only rejects from those lanes. As a result
only the valid shares were submitted and the only symptom was the low hashrate reported
by the pool. A strange coincidence.

Thanks to 4ward for noticing and reporting the problem.

AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
https://bitcointalk.org/index.php?topic=5226770.msg53865575#msg53865575
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
stevascha
Member
**
Offline Offline

Activity: 312
Merit: 10


View Profile
February 06, 2018, 08:33:06 AM
 #3348

cpuminer-opt-3.8.0.1 fixes X16R AVX2 low hashrate.

https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.8.0.1

There were actually 2 bugs. The first one prevented any shares from being submitted from
lanes 1 to 3 which hid the second bug that caused only rejects from those lanes. As a result
only the valid shares were submitted and the only symptom was the low hashrate reported
by the pool. A strange coincidence.

Thanks to 4ward for noticing and reporting the problem.

thanks!! currently i use v3.8.0 and doing fine
ryzen 7 1700x yescryptR16 1300khs with cpu affinity 5555

YENTEN - YescryptR16 - NO PREMINE - ASIC RESISTANT - WALLET MINING - COMMUNITY MANAGED - ADULT MALES
Yenten is a Japanese cryptocurrency of the cpu, by the cpu, for the cpu.
No ASIC. ASIC is for girls and kids. Join us!
nizzuu
Full Member
***
Offline Offline

Activity: 187
Merit: 100

Cryptocurrency enthusiast


View Profile
February 06, 2018, 08:40:17 AM
 #3349

hi,
possible to use in solo mining for ZOI?

Yes, getwork in cpuminer-opt does work for lyra2z330

Hi. I have only ~650H/s with my 4690k (lyra2z330), what's wrong?

Hi. Make shure you do not use -t 4 setting for your CPU. Use avx2 build with "-t 2 -cpu-affinity 3" to get the maximum hashrate.

4ward
Member
**
Offline Offline

Activity: 473
Merit: 18


View Profile
February 06, 2018, 08:46:20 AM
 #3350

cpuminer-opt-3.8.0.1 fixes X16R AVX2 low hashrate.

https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.8.0.1

There were actually 2 bugs. The first one prevented any shares from being submitted from
lanes 1 to 3 which hid the second bug that caused only rejects from those lanes. As a result
only the valid shares were submitted and the only symptom was the low hashrate reported
by the pool. A strange coincidence.

Thanks to 4ward for noticing and reporting the problem.

Significant improvement on pools side now
Thank you for the swift fix )

nizzuu
Full Member
***
Offline Offline

Activity: 187
Merit: 100

Cryptocurrency enthusiast


View Profile
February 06, 2018, 08:50:01 AM
Last edit: February 06, 2018, 09:01:07 AM by nizzuu
 #3351

v3.8.0.1, -a x16r, sse2 build at rvn.suprnova.cc - rejects only Undecided Pool reports about low difficulty shares.

No issues with avx2 and aes-sse42 builds.
joblo (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1114


View Profile
February 06, 2018, 04:42:14 PM
 #3352

v3.8.0.1, -a x16r, sse2 build at rvn.suprnova.cc - rejects only Undecided Pool reports about low difficulty shares.

No issues with avx2 and aes-sse42 builds.

Too bad you didn't find it yesterday. It'll be fixed in 3.8.1.

AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
https://bitcointalk.org/index.php?topic=5226770.msg53865575#msg53865575
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ol92
Sr. Member
****
Offline Offline

Activity: 445
Merit: 255


View Profile
February 06, 2018, 08:05:47 PM
 #3353

I'm baffled.

If you ignore the TR with affinity 1 it makes sense. I don't understand that one. Maybe the TR
has some kind of override that won't let you set stupid affinity. Wink

The CI only accepts decimal or hex at this time. I don't think it's worth the effort to support it
as converting from binary to hex is trivial.

Regarding the technicalities of the CCX and modular cache, it has nothing to do with the logical
CPU mapping. AMD could just have easily mapped them so that cores 0 to n/2-1 would all be on different
physical cores and n/2 to n-1 would be SMT (hyperthreaded). That's how it works on my Haswell.

You seem to confirm that AMD has messed things up, not only compared to Intel but within their own
products.

The need to use alternating cores with Ryzen seems consistent, TR should be the same. I don't know
if it carries to their older CPUs, or their servers.

For linux, physical cores and logical ones are divided as you said, but on windows numbers pairs are for physical cores and impairs for logical even for intel.
joblo (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1114


View Profile
February 06, 2018, 08:36:43 PM
 #3354

For linux, physical cores and logical ones are divided as you said, but on windows numbers pairs are for physical cores and impairs for logical even for intel.

It appears you are right. I just did a test with cryptonight on Windows. The total hash rate was the same but the per-thread
hash rates had 2 high and 2 low with default affinity, all 4 threads showed the same rate with affinity 0x55.

AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
https://bitcointalk.org/index.php?topic=5226770.msg53865575#msg53865575
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
joblo (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1114


View Profile
February 07, 2018, 09:57:55 PM
 #3355

cpuminer-opt-3.8.1

Fixes x16r on CPUs with only SSE2.
More Optimizations for X algos, qubit & deep.
Corrected algo optimizations for scrypt and yescrypt, no new optimizations.

https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.8.1

I have reviewed the scrypt algos for potential optimizations and updated the
specs to show the actual optimizations currently available in the algo.
No new optimizations were added, performance has changed.

Scrypt was taken from pooler and is highly optimized with AVX2.
No further optimizations seem possible at this time.

Yescrypt uses SSE4.1 (128 bit vectors) and also SHA which is also 128 bit. This suffers
the same problem as AES algos because the HW acceleration of SHA is limited to 128 bits.

Neoscrypt may have some potential. It currently uses some SSE2 but may have the potential
for full paralization. It will be lot of work and has some instances of data dependent memory accesses
which could kill performance. No results are expected any time soon.

Scrypt-Jane seems dead, Nicehash has zero activity, can't find it on any of the major pools. No plans.

AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
https://bitcointalk.org/index.php?topic=5226770.msg53865575#msg53865575
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
wurzelsepp1982
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
February 08, 2018, 09:23:34 AM
 #3356

Hi all,

what is the best config for "Xeon E5 5465v4" and "Xeon E5 2620v2"
Trying to mine verium, but hasrate is really slow (80H/s)

at the moment im running with:
virtual memory is 32000Gb and Large Page is enabled

Xeon E5 5465v4 --> -t 20  = 50H/s
Xeon E5 2620v2 --> -t 10  = 24H/s

Best regards
guytechie
Hero Member
*****
Offline Offline

Activity: 677
Merit: 500


View Profile
February 09, 2018, 06:00:39 AM
 #3357

With 3.8.1, trying to mine xevan it would start, but then exits without any errors.

I tried on different pools, and same behavior.

Code:
F:\Miners\CPU>cpuminer-avx2-sha.exe -a xevan -o stratum+tcp://xevan.mine.zpool.ca:3739 -u 1MkmBHDjonAFXui6JEx9ZmEemfMtUo9Cmu -p c=BTC

         **********  cpuminer-opt 3.8.1  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AES_NI and AVX2 and SHA extensions.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT

CPU: AMD Ryzen Threadripper 1950X 16-Core Processor .
SW built on Feb  7 2018 with GCC 5.3.1.
CPU features: SSE2 AES AVX AVX2 SHA.
SW features: SSE2 AES AVX AVX2 SHA.
Algo features: SSE2 AES AVX AVX2.
Start mining with AES AVX2.

[2018-02-08 23:50:41] Starting Stratum on stratum+tcp://xevan.mine.zpool.ca:3739
[2018-02-08 23:50:41] 32 miner threads started, using 'xevan' algorithm.
[2018-02-08 23:50:41] Stratum difficulty set to 0.062
[2018-02-08 23:50:47] xevan block 223318, diff 39.822

F:\Miners\CPU>

This is also happening for bitcore.  I don't know what other algos this could be happening to since I didn't test it all.

I do know that yescrypt, m7m, cryptonight, and lyra2z is working fine though.

Put something in my tip jar if I made your day. Smiley
BTC:
1MkmBHDjonAFXui6JEx9ZmEemfMtUo9Cmu
4ward
Member
**
Offline Offline

Activity: 473
Merit: 18


View Profile
February 09, 2018, 06:54:43 AM
 #3358

With 3.8.1, trying to mine xevan it would start, but then exits without any errors.

I tried on different pools, and same behavior.

Code:
F:\Miners\CPU>cpuminer-avx2-sha.exe -a xevan -o stratum+tcp://xevan.mine.zpool.ca:3739 -u 1MkmBHDjonAFXui6JEx9ZmEemfMtUo9Cmu -p c=BTC

         **********  cpuminer-opt 3.8.1  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AES_NI and AVX2 and SHA extensions.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT

CPU: AMD Ryzen Threadripper 1950X 16-Core Processor .
SW built on Feb  7 2018 with GCC 5.3.1.
CPU features: SSE2 AES AVX AVX2 SHA.
SW features: SSE2 AES AVX AVX2 SHA.
Algo features: SSE2 AES AVX AVX2.
Start mining with AES AVX2.

[2018-02-08 23:50:41] Starting Stratum on stratum+tcp://xevan.mine.zpool.ca:3739
[2018-02-08 23:50:41] 32 miner threads started, using 'xevan' algorithm.
[2018-02-08 23:50:41] Stratum difficulty set to 0.062
[2018-02-08 23:50:47] xevan block 223318, diff 39.822

F:\Miners\CPU>

This is also happening for bitcore.  I don't know what other algos this could be happening to since I didn't test it all.

I do know that yescrypt, m7m, cryptonight, and lyra2z is working fine though.

3.8.1 crashes also on x16r and x17. didnt test others yet

somaton
Jr. Member
*
Offline Offline

Activity: 204
Merit: 5


View Profile
February 09, 2018, 07:19:49 AM
 #3359

Same problems here. Using Awesome Miner with 3.8.0.1 and no problems. Updated to 3.8.1 and run benchmarks with Awesome Miner -> 10 benchmarks crashed (c11, neoscrypt, timetravel, all X, xevan). So, 5 min of testing was enought to see that this version is not working Smiley Back to 3.8.0.1.
phuocduong
Member
**
Offline Offline

Activity: 182
Merit: 10


View Profile
February 09, 2018, 08:33:21 AM
 #3360

useful for mining RVN algo x16r, thanks dev
Pages: « 1 ... 118 119 120 121 122 123 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 192 193 194 195 196 197 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!