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

v. 3.13.1 - yescrypt algo is broken - low diff share error from pool, maybe in latest version also, not tested.

Please add the "sha256csm" algorithm.

cpuminer-opt-3.14.1 is now released to address the solo mining log issues.

cpuminer-opt just got plugged at CMB:

https://cryptomining-blog.com/12386-cpu-mining-with-the-cpuminer-opt-free-and-open-source-miner/

I think you are right. There was a difference in the sequence of submitted and accepted blocks. Normally we see
236 Submitted
236 Accepted
237 Submitted
237 Accepted
But, in the screenshot that I posted there was a delay between submitted and accepted.
And I think the reason can be from my side or pool side. But, not in the miner.
Now, I'm doing again pool mining at rplant with v3.14.0, it seems everything okay; latency, TTF, sequence of submitted and accepted, everything is okay.



Yes, good Idea.
I saw in the pool some users are using v3.14.0 and some v3.13.1.1.
Let us use it for few days, whenever I will see something questionable/error/bug I will ask/report you.
And maybe other users will report if they find any bug/error.

Edit: I like the way you put your name in the title of cpuminer.

There's a lot of new stuff so I want keep things in perspective.

The high latency at rplant doesn't look like a miner problem. Take a look at the timestamp when share 238 was
submitted and when it was accepted. It looks correct to me.

That being said it is possible for stats to get out of sync and a high latency is one of the most obvious symptoms.
Stats synchronization problems occur when a submitted share doen't get acknowledged or there is an overflow
of pending acknowledgements. If you see a warning at any time that "share stats not available" it means that
corruption was detected and an attempt was made to handle it and recover.

You can also detect if there is corruption by auditting the data in the submit and accept logs. Do the share counts,
diff, block, job all match?

In any case if stats corruption is suspected all stats are unreliable but there is no other impact, shares still get submitted
and accepted. Restart the miner to reset the stats.

The low latency solo mining makes sense. The loopback interface doesn't use the eth card, it's just a memory copy.
The timer might not have resolution under 10ms.
Edit: on second though the interesting times might be related to the sheduler timeslice, which is 10 ms. The task submitting
the share suspends waiting for the response. The actual reponse time may be insignificant compared to the scheduling latency
which has 10 ms granularity. I had noticed a 10 ms granularity pattern in a previous log file but didn't think much more of it
at the time.

The zero effective hash rate in the summary is a problem, as is the still missing TTF in the new block log.
I thought I removed the "Curent block is..." log, oops.

Edit: I've got fixes for the 2 problems but I'll wait in case other issues are found with the release

I think time calculation is wrong during pool mining and solo mining.
When I do pool mining at rplant I get ping time 90-95ms and around 200ms at my2coins.
But, v3.14.0 is showing in thousands at rplant.
The ping time was okay with v3.13.2



And I think hash calculation in 5m summary is wrong during solo mining.

Great. I will check minotaur and yespower algorithms in solo and pool mining, sha256d algo in solo mining.
If I find any bug/error then I will report you. Thanks.

cpuminer-opt-3.14.0 released

Changes to solo mining:
  - segwit is supported by getblocktemplate,
  - longpolling is not working and is disabled,
  - Periodic Report log is output,
  - New Block log includes TTF estimates,
  - Stratum thread no longer created when using getwork or GBT.

Fixed BUG log mining sha256d.

Agreed. I'm surprised no one has copied it yet.

Thanks for your clarification. That (TTF) is a great addition. I didn't see it in any miner yet.
Maybe the reason is, I only used few miners for solo mining and they don't provide that info.

And waiting eagerly for your new release 

If it was correct it would mean the time it takes the miner or network to find a block based on the miner's reference hashrate
and the network hash rate. It's also an indirect way to report the hash rates. But it's obviously not correct. it will be fixed as
will the other issues.

About your suggestion, cpuminer-opt is the signature for the product. But since other forks have begun using it I see your point.
I have an idea.

New release will be available soon.

I did solo mining of yespower algo (LitecoinCash Gold, LTNCG) for around 2 hours and found 4 blocks too.

When I don't use `--no-longpoll`
1. The miner shows "new block report" in new format, then it shows in old format as it was doing with minotaur algo.
2. There was also Jason and HTTP error like minotaur.


Log file: https://drive.google.com/open?id=183CIraMTIsTPI938NoWyL8EPCurF2yLI

When I use `--no-longpoll`
1. The miner shows "new block report" in new format.
2. No error and it was running smoothly.


Log file: https://drive.google.com/open?id=1P1-C_Q9GAwJ6cU1oN-3K2kjF-YbIluOn

I did solo mining for a while with one thread and for a while with two threads.
And found that
1. It doesn't show 5 min summary.
2. Sometime it shows TTF and sometime it doesn't show TTF, no matter if I use 1 thread or 2 threads.

   

I have a question, what is the meaning of TTF here?

Edit: Why you don't use your signature on the title of CPUminer? I think you can add your signature here like this

**********  cpuminer-opt 3.13.2-segwit-test (JayDDee)  ***********

I'll wait for your results just in case something comes up.

Thanks.
Oh dude, I was just going to report about TTF, I already prepared to post the results of yespower mining.
I will do it after a while.

That's great work. I noticed the TTF estimates were missing from the new block log, I can fix that as well.

A new general release should be available in a few hours. No formal testing will be necessary. Just let me know
if you find any problems, new or pre-existing.

Sorry I'm late  :p

btw I did solo mining of Minotaur

1.  with --no-longpoll  -> miner ran smoothly
log file: https://drive.google.com/open?id=1IQNGI6kBr7TeuEjDJLQbW9kSIwFoh_G2

2.  with --no-longpoll --no-getwork  -> miner ran smoothly
log file: https://drive.google.com/open?id=1dHa8tnzW1fZI7zwceBP1Nl_2SWXTgOsh

3.  without --no-longpoll --no-getwork  -> received the Jason and HTTP error that we discussed earlier.

Don't bother with longpoll, use --no-longpoll from now on. I'll make it the default in the next release.

I undestand the missing summary log now as well as the "BUG".

That's now 3 issues unrelated to segwit.

When I was doing solo mining of LCC (sha256d algo) I found this Bug report as marked in the screenshot.



Miner of both versions (v3.13.1.1 and 3.13.2) is showing this bug report.

Here is the log file: https://drive.google.com/open?id=1OGFmZKF9ejfFKQtNHwgmkjl5tof-c8ka

I left the miner running more than 20 minutes during solo mining, but it didn't show 5 mins summary.
So, now I can say the miner of both versions (v3.13.1.1 and 3.13.2) is not showing summary during solo mining with Minotaur and sha256d algo.
It only shows summary during pool mining.



LTNCG wallet synchronization is complete, but I postponed it testing, cause I got busy with some other stuffs.
I will test it when Minotaur testing will complete.




When I do solo mining first it shows "new block report" in new format, then it shows in old format and it continues showing in old format.





I think you're right. I'm going to test Ring solo mining again and will post the result after few hours.



You're welcome dude.  
I'm also learning with these testing.