[LOCKED] cpuminer-opt v3.12.3, open source optimized multi-algo CPU miner

[joblo]

You need the correct parameter values, ask the coin's devs.

Edit: Actually the real problem is too funny. The litb miner screwed up the key length:

Code:

	static const yespower_params_t v5 = {YESPOWER_0_9, 2048, 32, "LITBpower: The number of LITB working or available for proof-of-work mining", 73};

The string is actually 75 chars but the length is hardcoded at 73. This means the key is actually the first 73 chars of the string:

Code:

"LITBpower: The number of LITB working or available for proof-of-work mini"

[1713946607]

1713946607

[1713946607]

1713946607

[joblo]

I noticed this too, how to fix it?
There is a working miner from the pool

https://github.com/cpu-pool/cpuminer-opt-cpupower/blob/master/algo/yespower/yespower.c

Thank you

It's a coin issue, there's nothing for me to fix.

[Ngenah Euy]

Hi Joblo ...

may be you interest to add CNX-v1 algo to CPUminer
https://bitcointalk.org/index.php?topic=5172572.0
 thanks

[joblo]

My take on RandomX, cryptonight, Monero, etc.

As previously reported I have stopped trying to support the high level of algo development
by Monero and the variants of cryptonight. There exist excellent open source miners already
for this family of algos that are being actively developped. They are very well written with
little to no potential for further optimization.

In other words I have nothing to contribute. Trying to keep up would be a lot of work for no
benefit beyond the convenience of the additional algos in a single miner. Many Monero
miners are dedicated and don't usually mine other algos so the extra 100 algos would be just
bloat to them.

When and if development stabilizes and the dust settles I may consider re-importing
Cryptonight and RandomX and resume support.

I make no promises and there is no timeline.

[joblo]

I'm considering more changes to the share display to address 2 specific issues.

1. Share difficulty is not used by pools except when it solves a block. All valid shares are
otherwise considered equal regardless of difficulty. This makes the sharediff and share ratio
(block %) irrelevent. I am proposing eliminating the  reporting of share ratio and removing
the colour ranking from the share diff. The share diff will still be reported without any
highlighting for high diff shares.

This creates a bit of a dilema for calculating the effective share hash rate as it uses the
sharediff as well as time while the pool uses only time. To match the pool's calculations
I would need to know the expected share rate, which is not available to the miner AFAIK.
The existing calculation using share diff seems to track the pool's reported hashrate fairly
well in the summary report so until I find a better way I won't change it.

2. Job ID reporting was introduced due to a specific issue with persistent stale shares in
one pool affecting a couple of algos. I've debugged down to the stratum/curl level and
it appears the pool is sending stale jobs. There has been little interest from the pool admin
in pursuing this issue but all indications are it's a pool issue.

The only other benefit to job id reporting is to confirm expected stale rejects where it shows
a new job received between the submission of a share and it's acceptance by the pool.
I don't think this is enough to justify the added verbosity in the output. I am proposing to remove
all reporting of job ids.

I am aslo planning on removing the timestamp on all lines of a multiline report. Only the first
line will have a timestamp.

I may also make some changes to the share rate reporting to place more emphasis on this statistic
as it has a direct effect on mining performance.
Comments?

[TheWolf666]

Keep up the good work, looking forward to test the new version once it is ready!

[joblo]

cpuminer-opt-3.9.8

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

Changes to log output to provide data more relevant to actual mining performance.
phi2 can now handle pools with a mix of coins that use and don't use roots.
phi2-lux added as an alias for phi2 as they are identical except for roots.
Add x16rv2 algo for Ravencoin fork.

Detailed notes...

Please read the folllowing before reporting log questions.

The main motivation for the log changes was to focus on data that the pool uses to calculate earnings instead
of the traditional hash rate displayed by most miners. That hash rate is calculated by the miner counting hash
iterations over time.

Pools use the rate of share submission over time and the stratum difficulty to determine a user's share of a block.

As a result more focus has been placed on these data with the addition of detailed timing data in the 5 minute
summary report.

The diff adjusted average share submission rate is converted to a share equivalent hash rate and displayed in the
summary report. The miner reference hash rate is also displayed there for comparison and monitoring of CPU performance.
The miner reference hash rate is also displayed in the TTF calculation of the block report as it is used to
calculate the TTF for a block and share. The share equivalent hash rate should better match the pool's reported hash rate.
Although most pools use a 5 minute window they are not synchronized with the miner and will sometimes differ.
Edit: The summary data will be inacurrate if the stratum difficulty changed during the period.

A share's difficulty is also not used by the pool, unless it solves a block, and is no longer displayed on the first line of the
share report. The display of share difficulty and share ratio is FYI only due to it's lack if significance and is suppressed
if --quiet option is used.

The first line of the share report focusses on time, displaying the time since the last share and the network latency,
the time between submitting the share and receiving the reply from the pool. Timing information is also prominent
in the summary report.

Some compromises were made to avoid adding too much overhead that could reduce mining performance. For example the 5
minute summary is not exactly 5 minutes. Also, at startup block reports will show some zero values until a baseline
reference hash rate has been calculated. This can take a few minutes.

Everything else should be intuitive or easilly deduced if you've mined before. If you still can't figure it out please ask.

[Kodaman]

Do you support randomx or will you support it?

[joblo]

Do you support randomx or will you support it?

Randomx is under heavy development. I'm waiting until the dust settles to look at it in any detail.

[TheWolf666]

There is a Microsoft Visual Studio .sln file. Is it compiling with MVS?

[joblo]

There is a Microsoft Visual Studio .sln file. Is it compiling with MVS?

All the VS files are garbage, the project needs to be rebuilt from scratch.
Even so the code probably wouldn't compile due to incompatibilities
introduced over time.

It would be a bigger task than trying to compile on Apple Mac which a few have tried and
given up.

The process of using a Linux VM to cross compile using mingw is a lot of work to setup but
once done it's trivial to compile new versions. It's essentially 3 commands now to build the
binary release package.

[joblo]

cpuminer-opt-3.9.8.1

Summary log report will be generated on stratum diff change or after 5 minutes,
whichever comes first, to prevent incorrect data in the report.

Removed phi2-lux alias introduced in v3.9.8 due to Luxcoin's planned fork
to a new algo. The new Luxcoin algo is not supported by cpuminer-opt.
Until the fork Luxcoin can be mined using phi2 algo.

--hide-diff option is deprecated and has no effect. It will be removed in a
future release.

Edit: TTF estimates and hash rates for algos like x16r that have variable hash rates are
innacurate. No solution is apparent.

[joblo]

Before this becomes a FAQ...

Power2b algo now used by MicroBitcoin is incompatible with current yespower code
and can't be mined with cpuminer-opt at this time.

A new version is required. I'm working on it.

[joblo]

cpuminer-opt-3.9.9

https://github.com/JayDDee/cpuminer-opt/releases

Added power2b algo for MicroBitcoin.

Added generic yespower-b2b (yespower + blake2b) algo to be used with
the parameters introduced in v3.9.7 for yespower & yescrypt.

Display additional info when a share is rejected.

Some low level enhancements and minor tweaking of log output.

Additional notes:

yespower-b2b is yespower with sha256 replaced with blake2b. There is no default parameter
configuration when using yespower-b2b, the N and R parameters and the personalization key,
if used, must be specified. The parameters work in the same way as yespower (sha256) and
yescrypt.  power2b is just yespower-b2b with the parameters preset for power2b.

[joblo]

I think it's time to reflect on the cpuminer-opt project.

TLDR:

Not going to compete with already optimized new CPU algos like RandomX.
Next big phase is AVX512.
I know I'm flogging a dead horse.
Everything depends on my motivation.

The long version:

Mining is in the dumps in general, exchange rates way down. Competition from ASICs
& FPGAs is making it worse for GPUs and even worse for CPUs.

One exception is the CPU-friendly algos like yespower and randomx, and Ryzen CPUs.

I started this project in better times with the purpose of importing existing X11
functions that were optimized for AES & SSE2. That was mostly cut & paste.

Some of those functions were easilly promoted to AVX2 like cubehash and lyra2.

I then started to optimize other functions to hash in parallel similar to how GPUs hash.
SIMD has some limitations so not all functions can be parallelized efficiently.

I also attempted to optimize CPU algos in various ways with very limited success.
Many CPU algos can't be vectorized at all or can't be vectorized using SIMD.
Most ot of those than can have already been optimized.

So that brings things up to date. I don't anticipate there is much more performance I can
squeeze out of the code. cpuminer-opt 3.9.10 is probably as fast as it will get with AVX2.

The next big phase is AVX512. All of the parallel AVX2 can be promoted and some of the linear
AVX2 can also be promoted to AVX512. A rough estimate is a 1.5x improvement in algos
with a significant portion of AVX2.

There are a few factor that limit the gains: only the portions of algos that currently use AVX2 will
see improvement, memory usage is doubled possibly creating bottlenecks, AVX512 code runs
at a lower clock speed than AVX2, and AVX512 has extra overhead for some operations.

Starting serious AVX512 development requires a CPU with AVX512. With the release of Intel's
Cascade Lake X CPUs and the big price reductions, combined with the failure of my core2-quad
system, it may be time to buy a new Cascade Lake X.

The loss of my core2 means I don't have a CPU to test SSE2 natively. I don't expect that to cause
any problems. SSE2 code will be very stable going forward and I can still test the SSE2  build.

Why am I still doing this when these algos are even dead from a GPU perspective?

One reason is no one else is doing it. For many algos the existing CPU miners are not optimized and for
others CPU miners don't exist.

Another reason is for fun. I'm retired and this is a hobby. I have a lot of experience in development and
support but not on Intel CPUs and not using C and not using Linux. So this has been a big learning
experience. I've made a lot of mistakes, fixed those I've discovered but there are probably many more.

In addition to getting used to the environment I also learned about SIMD programming (linear and parallel)
using intrinsic functions and, more recently, using ASM.

The learning aspect is very important because it's exercise for my aging brain. Doing hex arithmetic
and permuting bytes in my head is quite a workout.

As usual I make no promisses. Development of AVX512 will depend on my level of motivation which
is influenced by many factors.

[ol92]

Thank you very much for all the work you have done with cpuminer. Funny, I was thinking you were a young programmer motivated by improving his cpu architecture understanding and close to machine coding skills. Well your example shows me I am not too old to improve my coding skill and may motivate me to do this.

[joblo]

While testing some blake2s code for x25x in v3.9.11 I noticed some peculiar results.
I made some changes to the AVX code whcih inproves performance on my Skylake
but the same changes slowed my Ryzen 1700.

Ryzen ver1 is known to have poor AVX2 performance but I have no idea about
ver2.

If anyone has done some comparison testing of Ryzen AVX vs AVX2, or would like to
do some testing please post your results. It will help me decide how to proceed
particularly with the Windows binaries package.

I wouild like to know whether AMD has improved AVX2 in zen2 and whether the compiler
makes a difference. znver2 is supported starting in GCC 9.

Blake2s is a good test algo for AVX and AVX2. There's no profit to be made mining blake2s
with a CPU but a benchmark test will do.

./cpuminer -a blake2s --benchmark --hash-meter

TIA.

[alucard20724]

@joblo
Any chance of getting verushash algo added?

[joblo]

@joblo
Any chance of getting verushash algo added?

This answer seems to apply here as well:

https://github.com/JayDDee/cpuminer-opt/issues/217

[joblo]

AVX512 is coming soon.

I've been waiting over a year for a reasonably priced CPU with AVX512. With
the price drops for Cascade Lake X I was thinking of getting one.
Instead I got an Ice Lake laptop for less than the cheapest Cascade Lake X CPU.
But I won't be using it to mine, just develop.

Ice Lake also has VAES which will can also speed up algos that use AES.

I'm setting it up now, had a problem with the NVME SSD being recognized by Ubuntu.
Got an external SSD and all was fine. I would have liked to use he built in SSD but I have
a feeling the BIOS is preventing it. Some tips suggest changing it to AHCI but there are
no BIOS options for the SSD. Another possibility is a lack of SATA support. I may revisit that
issue later, the external SSD works fine and it leaves the system otherwise untouched.
If anyone has some ideas I'll check them out.

AVX512 wil be rolled out gradually over the next several releases with single function algos
optimized first and the longer chained algos later. VAES will come much later.

Stay tuned.