Topic: [ANN] cpuminer-opt v3.14.2, open source optimized multi-algo CPU miner - page 13. (Read 9705 times)

I don't know if it is the Algo or the miner, but with Yescryptr32 AMD Ryzen CPUs can barely produce anything.

There's so much I'm not sure where to start.

First you should learn about Linux command line options. There are short and long form options.
-x and --proxy  are the short and long forms of the same option, therefore specifying both is an error.

Second you always need a mining URL, -o or --url, not both.

Most pools have specific instructions on how to set required options.

Don't try using a proxy until you learn the basics.

what is the proper syntax for selecting proxy?
-x, --proxy=[PROTOCOL://]HOST[:PORT]

assuming you have a proxy server running on 192.168.55.10 with listening ports 8333 for stratum and 8335 for getwork

I tried different combinations but always receive:
./cpuminer: no URL supplied
Try `--help' for more information.

in the easiest form should work as -x --proxy=192.168.55.10

-x --proxy=stratum://192.168.55.10:8333
-x --proxy=stratum+tcp://192.168.55.10
-x --proxy=tcp://192.168.55.10:8335
-x --proxy=//192.168.55.10

all yield same result

cpuminer-opt doesn't support Monero or any Cryptonight variants anymore.

Supporting ARM is easier said than done. cpuminer-multi already supports it but the optimization
potential is minimal.

SBC is not a growing mining business, it's focused on portability and low power. When big ARM CPUs
start getting built there may be more interest.

Hi
I remember mining monero on cpuminer-opt back in 2017, cold winter past and I sold my coins for a good price
@JayDDee would you please consider supporting ARMv8 architetcure? I am asking you this because there are pretty powerful SBC's like Odroid N2 and VIM3 with Amlogic s922x, and there will be more of them when Rockchipp 3588 will find it's place in numerous chromebooks, tablets and SBC's.
Don't you think it's worth taking part in this growing mining business?

Allways use the "native" build to ensure it matches the CPU's capabilities. The algo
will use whatever it can.

Sorry didn't explain myself well enough.
I am not messing with options (yet) that's why I asked.

When I compile I noticed that using ./build.sh gives me the best result. When miner start it shows the number of thread used and tells me SSE xxx which I assume it picks what the cpu is capable of... and set the best flags?

So question one was more like.... should you use native for better general performance or set flags to be more specific in relation to cpu used? if cpu handle SSE2 and SSE4, should you "force" the compiler to set SSE4....

Sorry, english is not my first language 

I am experimenting with uraniumX mining

The first thing you're doing wrong is overcomplicating things. Don't mess with options
until you know what you're doing. Next pay attention to the messages at startup to see
what optimizations are available and used, every algo is different. If you think there's a problem
post the console log.

Hi JayDDee, I have few questions about optimization.
I run linux, ubuntu server 18.04 on my machines.
I compile locally on each machine using [./build.sh] followed by [make -j (cpu thread)]
Is this the right way to do it or I should use different build options depending on the cpu?
Also, is cpu-affinity a paramount value to set? I am struggling to find the right hex value to put.
Is huge page important?
Is cpu-priority important?
All my machines are only mining, no other tasks performed.
As example, two machines, exactly the same hardware, one with a i3-2130 and one with a i7-2600.
Performance difference is only 22%, I can't figure out what I am doing wrong.
Comparing different cpu, I achieve better performance with older core2 quad than gen2 i7 cpu.
I think I am not compiling it right?

[/quote]

-x, --proxy=[PROTOCOL://]HOST[:PORT] connect through a proxy
[/quote]

A PROXY WILL WORK--

I used a proxy recently until the coin went PoS.  Try "GitHub.com/stratehm".  Getting it configured was the hard part.       --scryptr
[/quote]


Thanks guys!

scryptr.... if I get stuck I may send you a message   

A PROXY WILL WORK--

I used a proxy recently until the coin went PoS.  Try "GitHub.com/stratehm".  Getting it configured was the hard part.       --scryptr

-x, --proxy=[PROTOCOL://]HOST[:PORT] connect through a proxy

Is it possible use a proxy?

If you have a bunch of CPUs can you point the miners to a proxy and point the proxy to the mining pool.

Basically I would like to point clusters of PCs to a proxy (local in one of my machines) and point the proxy to the mining pool

sha256d (LCC)  was recently tested as was minotaur (RING):

https://bitcointalksearch.org/topic/m.54463714

It's not al algo issue but a coin issue.

Understanding why some coins work and other don't is critical to solving the problem
but that requires testing a large number of coins and looking for patterns.

zlib only? You got it to work twice, you're on to something.

no mixups
replacing all 3.12.8 dlls with 3.14.2's kills the thing for good (same error),
no change in messages

P.S.
ok it's my last, i've tried it 5 times and it works:
replacing both libcrypto-1_1-x64.dll and libcurl-4.dll simultaneously removes the error,
(replacing them one after the other either removes or not)
but i have a lot of rejects for block 2 in sha256d, like it's never gonna resolve,
less rejects after i replace all other dlls,
still this miner never gives me the same efficiency as cpuminer-multi on that sha256d coin,
so i'd stick to multi for "classic" algos

I having trouble parsing this. It looks like you got it to work twice by changing zlib.
Is it possible you got versions mixed up after that?

Also it would be good to try to break v3.12.8 the same way, by using the newer DLLs from v3.13.0+.

Any change in error messages is significant.

I should also note this problem wasn't seen while tesing soloming mining minotaur with segwit.
The only problem was the lack of segwit support which was fixed.

was my thought exactly, firts i replaced libcurl - no dice, + libcrypto-1_1.dll - same,
+ zlib - error's gone, then reverted to all new dll's again - doesn't work,
changed only zlib - errors gone, then changed back to all new - error, copied zlib - error, copied 2 others - error,
copied all of them - working,
so you see it's smth i can't help with
error's always the same, algos i tried - sha256d, x11, m7m

That's unfortunate, it makes it more difficult to solve. The DLLs are newer versions compiled with a newer
compiler. Some were taken from the mingw packages available in Ubuntu, the others were compiled from
source using the same version as the host Ubuntu 20.04 package.

It's the exact same procedure as before, only the base system, DLL versions and compiler version have changed.
It's also notable that it works when the DLLs are compiled with a different version of GCC than the
cpuminer code.

This is not a simple problem. It could be a combination of factors including cpuminer, the compiler,
mingw, any of the DLL packages, or the wallet. It could be Windows only or also affect Linux.

Troubleshooting will be difficult. At this point I don't even have any clues as to what it might be or how to
fix it. And using Windows make troubleshooting more complicated.

You said previously it failed with any algo or any coin. Do you have examples?

Also note if any test cases result in a different failure mode or error messages. This applies to the DLL swapping as well.

Edit: did you test with only the old libcurl-4.dll? That package looks like the most likely to cause RPC errors, it's also one of
only 2 that were built from source, the other is libcrypto-1_1.dll. All the others were already avaiable in the mingw packages.

well it works if and only if i replace zlib1.dll,
oops, not simple at all, i can't figure out which one,
it's not one or two, it's a sequence or a system setting which some of old dll's change
i can dance all night with that, so copying the whole bunch is simpler