My opinion is 2 2070s would push the PSU too hard, especially if you're OCing.
750-850 would be good, 1000 is overkill. Whatever the wattage get good qiuality
well revewed one.

It's claims are so outrageous it's pretty obvious but better to be warned. Thanks.

Adding some detail to phillipma's reply...



A ratio of 2MB cache / core(thread) is optimum.

1. cache / cores

I believe RandomX use the same cache as the old Cryptonight, 2 MB/thread.
You only need as many cores as you have cache to support them.

2. Frequency

3. Cores, see 1.

It's easier to implement an ASIC for a GPU algo than a CPU algo.
It's usually only a matter of time and the algo's popularity.

A well designed CPU algo would be unprofitable or nearly technically
impossible to develop an ASIC.

Ethereum is unique, it's a GPU algo but has properties that make ASIC too expensive.

Just to expand on the other good advice.

There is solo mining using the wallet's built in miner (wallet mining) which is CPU only
(usually un-optimized).Then there is solo mining using an external miner which could
be a CPU (often optimized), GPU (more optimized), or FPGA or ASIC miner (extremely optimized).

Wallet mining is a waste of time and electricity with any coin.

Solo mining is very dependent on the algo and mining device.
Algos like sha256d, scrypt, X11, and many others require an ASIC for viable
mining. Some other algos can do well with a GPU when an ASIC or FPGA isn't available,
while others are better with a CPU.

Solo mining requires much more hashpower than pool mining because pool mining combines all
the hash of the individual miners, and divides the rewards.

If you want to solo mine with a CPU you need to find the right coin. There are several threads
discussing which coins are CPU minable.

Notice to API users

This is a heads up of my plan to disable the API by default in an upcoming release.

If you currently use the API with default configuration you should add
-b  127.0.0.1:4048
to the command line or configuration script.

If you already manually enable the API with -b or --api-listen no changes are required.

Another notice will be posted prior to the release that implements the changed default.

Update Feb2

Change will be in the next release. More details: https://github.com/JayDDee/cpuminer-opt/issues/234

Mining with a laptop CPU or GPU is not a good idea, they can't handle the heat.

How about showing me the respect of reading my post before going passive-aggressive and asking
the questions I already answered? I counted 3.

1. Pooler can't mine ethereum, only sha256d and scrypt.

2. CPUs aren't "strong" enough to mine litecoin anymore, Ten years ago you could so you're ten years
too late.

3. I mentioned a good CPU miner and you also completely ignored the one in my sig.

As for your other questions, do you're own research.

I feel like listening to some Aretha Franklin.

About 10 years late.

This miner is obsolete and has been for about that long. It was awesome in its time but its time is gone.
It only mines sha2d and scrypt.

Mining anything with a single ARM CPU is futile. A cluster, maybe, but that gets really complicated.

ARM miner software is poor as there is little interest from good developpers due to the futility previously
mentioned. TPruvot has a multi algo miner that supports ARM but it hasn't been updated in about a year.

If you want to learn about mining just use your regular PC's CPU or GPU with a wide choice of excellent
up to date mining software.

Mining on a Pi is just child's play, but it makes a good wallet host.

Anything involving referrals is a pyramid scheme.

Another note, this time about share counting.

The share counts are calculated mostly independent of one another,
particularly the submit count and the acknowledged results.

Under most circumstances the numbers should always add up
(don't add blocks sloved, they are also counted as accepted).
The miner can even handle multiple shares submitted before
receiving replies. It can stack up to 8 pending submits.

There is no direct linkage between the submitted shares and the
replies. they are simply matched up in the same order as the the
shares were submitted and the replies received. A lost reply will
result in an unresolved discrepency that can only be corrected by
restarting the miner.

If there is a brief pile up of pending shares the miner will try to
re-synch when the replies are recieved. Some share statistics may
be lost. In such cases the miner may recover but long term statistics
may be affected. It may be desireable to restart the miner.

I found an error in the network hashrate calculation. The actual hashrate is the displayed
rate divided by the block time. Will be fixed in next release.

A note about low difficulty shares.

I have recently noticed some instances of low difficulty shares being rejected.
It is intermittant, has been  seen on 2 algos, each with a specific stratum difficulty.
If the stratum difficulty is changed low difficulty shares are no longer submitted.

Higher share difficuty is good, high enough in solo mode and a block is solved.
In pool mode only the number of shares with a difficulty higher than the target
matter, all valid shares regardless of difficulty are of equal value.

Low difuculty rejects can occur when the target is set incorrectly. This can be a pool or
miner configuration error. They are usually intermittant as some shares will naturally
be higher than the actual target.

Low difficulty shares do not represent lost performance. These shares would normally be
discarded instead if submitted.

The opposite problem can also occur if the targetting is not exact. Valid shares could be
discarded. This is lost performance. This is also a silent error, the only indication would be
a low hash rate reported at the pool.

I have been tweaking the hash test to ensure targetting is precise. This may be why some
low difficulty shares are being seen. It could be a problem calculating the target for certain
stratum difficulties.

Given the pros and cons I'm willing to tolerate some low difficulty shares if it guarantees
no good shares are being tossed.

Stale shares are also explainable and unavoidable. Shares are stale when they are submitted
for a job that has expired. They are more likely to occur with higher network latency.
Finding a low latenc connection is good.

Stale share can be confirmed withthe log messages. The stale share is always preceded by a new
job issued after the share was submitted. The job id of the stale share does not match the new job id.

Invalid shares are always bad. If they are not user error, ie wrong algo or port, It's a software bug.

 

Newbie indeed. Your miner needs to find a share, submit it to the pool and be
accepted before anything shows up on the dashboard.

Your miner is "working" in the sense it's hashing nonces but it will
likely never find a share and submit it to the pool. Groestl is just too difficult
for a CPU, or even a GPU, It's ASIC only for that one.

Try something a little more CPU friendly, at least until you know what you're doing.
There's a lot of discussion and choices about coins that are mineable with a CPU.

A couple of notes about v3.11.6.

CPU temperature on Linux is still a work in progress. I have 4 CPUs and each
has a different path to the CPU temperature. I don't know if the difference is
because of the CPU or the OS version.

I finally have all my CPUs' temperatures being reported correctly but I have no
idea of any others.

It would be appreciated if any Linux users could post whether they see the correct
temperature. Please include CPU and OS version.

Those ambitious enough may explore what works for their system by browsing the /sys
file system. Some sampe file path are listed in sysinfos.c. Some ppaths don't exist on some
systems or may report a bogus value. Note the values are multiplied by 1000.

I added a new line to the block log reporting another TTF and hash rate. The hash rate is
a representation of the network difficulty converted to hashes and the TTF is just
counting the new blocks over time.

The usefullness of this new information is yet to be determined. It is
not displayed for a multipool where block numbers differ among different coins.

The other changes should be intuitive. They are intended to make the logs more compact
to reduce the chance of line wrap and to highlight the important fields in the logs.

Statum difficulty is a pool issue, not a miner issue but you didn't mention which pool.
You need to follow the pool's instructions on how to set difficulty.

In this case it looks like the pool is automatically raising the difficulty to high and
causing stratum errors. It's not a big problem, with higher dificulty it takes longer find
find shares but they are worth more so it evens out.

Thanks for responding.

The values depend on the algo. My interests are in algos that can be mined with a
reasonable CPU, which is almost anything.

Like I said the starting diff is not the problem for CPUs if vardiff can lower it to
a reasonable level (3 shares/min seems appropriate). There doesn't need to be an absolute
minimum as long as vardiff is in control.

Currently vardiff will only adjust down by one step resulting in a share time of several
minutes on many algos even with a 16 thread CPU. It also affects some smaller GPUs.

If vardiff had a wider range it would reduce the need for manual setting with "d=" or "sd=".

It's a pyramid scheme and has nothing to do with crypto mining.

It's always good to keep reminding people.

Also be aware that some malware looks like legitimate miners, faking the ANN post
but with altered download links.

Always check the links before you download.