It makes a big difference if you have excess solar generation that can't be sold to the grid or stored in batteries.
The usual profit models don't apply. Using mining as a sink is a win-win, you dispose of excess power and generate some revenue.

Good luck with that. DYOR would be an appropriate response to your question.

Here a couple of general tips:
There is nothing good to mine at the moment with any GPU. Unless you have free electricity you'd likely pay more you'd earn miing.
There are no differences with any Nvidia GPU with any coins as long as the GPU has enough VRAM. There may be differences between Nvidia,
AMD & Intel, some brands may be better with some algorithms.
The 3060ti, being 2 generations old, would put you at a disadvantage over the more efficient 4000 & 5000 series.
Mining with a single GPU, particularly a 5 year old mid level model, is a waste of effort regardless.

Fool me once shame on you, fool me twice shame on me. Don't be the fool.

Power is a function of voltage. Lowering the voltage reduces the power but can introduce other problems if the voltage is too low.
Some miners have an intensity setting. In most cases it's set autromatically for for each GPU model for best performance but can be set manually.
In either case it's trial and error.

I think the answer is in the question. It's overheating, deal with that. Make sure the fans are all working & clean
& you have good air flow. ASICs are designed for data centres that have environmental control so you might
need more cooling.

They're all scams. The apps are click bots that generate revenue for the scammers while users get worthless tokens.

Multi CPU systems are more complicated, they usually use NUMA.
Try starting 2 instances of cpuminer, one on each node (assuming there are 2 nodes).

Only way to merge mine is using a pool, create your own.

It's the worst kind of problem to troubleshoot. It's intermittant, takes time to become apparent & has no obvious trigger.
It could anything, SW like a memory leak, HW like a failing PSU, environment like poor cooling/ventilation, anything.
Furthermore very little information was provided. It's just guessing at this point.

Free, as in beer, is not the same as free, as in speech. If ASIC miners are not permitted then GPU rigs would probably
be treated the same way. The issue is likely the abuse of free power, not the kind of device used. Either way your GPU farm's
power usage would attract a lot of unwanted attention.

I also am not familiar with Antminer.

1. Typically miners count the number of nonces hashed, whether submitted or not, which would also includes HW errors. I would assume the same unless there is
some indication HW errors are specifically excluded.

5. I assume the same. But I don't see a problem. It's likely you did solve a block but you weren't solo minning so it only counted as another share. Behind the scenes
the block would be created and the accumulated shares distributed to the miners. Best share doesn't really mean anything for pool mining, every share has the same value
based on stratum diff. The different diff factor for scrypt algo should not affect the share diff, it's only used to calculate the target hash associated with the stratum diff.



 

Comparing different algos will only add to the confusion. Figuring out P vs E vs HT is confusing enough.
I suggest you stick with one algo until it makes sense. The radically different results on similar CPUs is
of concern.  Some factors to consider are L2 cache size, and monitoring the CPU cores to confirm thread
distribution is as intended.

There's no real short answer for this, pretty much all of the above. You can enable transparent huge pages on Linux and give it a try.

You're welcome.

cpuminer-opt can mine any yescrypt  or yespower coin by specifying the parameters. See https://github.com/JayDDee/cpuminer-opt/wiki/Supported--Algorithms.

The parameters are part of the coin's specification and should be published by the coin's developpers. Tide chose not to publish the parameters,
in their mining guide, however I found the parameters buried in the code:


Simply add "-N 2048 -R 8" to the command line and it will mine Tide.  Pers (-K) is left at the default of NULL.

RISC_V is another story. Pi is not a viable mining platform, whether ARM or RISC-V. ARM now has Apple and Snapdragon-X
that produce more powerful CPUs but they only perform as a light desktop. They can't compare with Intel Core or AMD Ryzen.

On the HW side the most interesting thing for RISC-V is the HiFive P550: https://www.sifive.com/boards/hifive-premier-p550
but the CPU Is still very weak.

On the SW side all the vector code would have to be rewritten for RISC-V. Translation layers like sse2neon (for ARM) don't cut it.
They only provide compatibility by emulating SSE instructions using NEON. Performance is terrible.

I'm still trying to understand ARM SVE with uses vector length agnostic programmimg, meaning the code doesn't know the size of
the vector registers and can't be optimized for the HW. Tuning SVE for a particular vector length is critical for cpuminer-opt but it
will add run time overhead which will affect it's performance. It will likely also require a complete rewrite of all vector code in cpuminer-opt.
This is a lot more complex that implementing NEON. RISC-V is also vector length agnostic but I don't yet knw how its implemented.

The short answer is no RISC-V anytime soon if ever.

On a tangent, Bitmain released a XMR miner that actually uses a cluster of RISC-V CPUs. Some people mistakinly call it an ASIC but it's just CPUs.
AFAIK it hasn't sold well.

That's interestng. I have no personal experience with a hybrid so I'm learning too.
Yespower is I/O bound, AKA memory hard, so compute performance is less important than cache size
and memory performance. E-cores have smaller cache and lower clock but I would have expected them
to help some without interfering with the P-cores. It's basically trial and error, and it's probably different for each
CPU based on its combination of P vs E cores.

Alternating threads is pretty standard for yespower on non-hybrid CPUs, it avoids hyperthreading and distributes the cache load evenly.

If you're seeing all the CPUs the binaries should be ok, your initial post implied something weird was going on and the miner wasn't seeing all the cores.

I don't understand what you are saying. Unless you are using the --threads option it should use all available cores.

Hybrid CPUs are a pain for mining, especially Intel where P-cores have hyperthreading and E-cores don't.
Setting the affinity correctly is a nightmare.

Start with using --hashmeter to help identify hich CPUs are P-core and which are E-core.
You can also disable hyperthreading in the BIOS to help identify which cores have it and which don't.

Once you have your CPU all mapped out you can play with different thread counts & affinity strategies to see what work best.
Typically you would use half the P-cores to avoid hyperthreading while using all the E-cores.

Ryzen is simpler because all the cores on a hybrid Ryzen have the same features including hyperthreading.

cpuminer-opt-25.3

#442, #443: Fixed a regression in Makefile.am.
Updated dockerfile.
Removed algo features log display.
Some code cleanup.

It usually means someone is using an employer or school system, probably without asking.

Thanks for the heads up. I'll remove all references to DYN in cpuminer-opt.

As far as supporting argon2d-1000, I'm undecided. If it's only a matter of changing the mcost it should
be simple. But there isn't much happening with argon2d anywhere at this time.
If I see it pop up in a pool I'l take a look.

cpuminer-opt-25.2

ARM: Fixed regression from v25.1 that could cause build fail.
BSD: FreeBSD is now supported. Other BSDs may also work.
MacOS: build with installed jansson library instead of compiling the included source code.
Windows: remove "_WIN32_WINNT=0x0601" which is a downgrade on Win11.
Changed build.sh shell from bash to sh.

This should be the last new release for a while unless something comes up. Support has been expanded to
MacOS and FreeBSD operating systems on both x86_64 & ARM64 CPU architectures. Other BSDs may also work but
have not been tested. Unfortunately Windows on ARM64 is still a work in progress.

The build process has also been streamlined and tweaked over the past few releases. Once all the packages are installed
for the specific environment a single command will build cpuminer-opt. The Wiki has also been updated to reflect these changes.