joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
 |
January 03, 2020, 07:39:40 PM |
|
Yet another asshole is posing as me and posting malware as cpuminer-opt. As always be careful.
|
|
|
|
|
|
"In a nutshell, the network works like a distributed
timestamp server, stamping the first transaction to spend a coin. It
takes advantage of the nature of information being easy to spread but
hard to stifle." -- Satoshi
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
 |
January 06, 2020, 07:15:17 PM |
|
cpuminer-opt-3.11.1 is released. https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.11.1Faster panama for x25x AVX2 & AVX512. Fixed echo VAES for Xevan. Removed support for scryptjane algo. Reverted macro implemtations of hash functions to SPH reference code for SSE2 versions of algos. Use older release for scryptjane of SSE2 mcro support.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
 |
January 23, 2020, 10:35:03 PM Last edit: January 24, 2020, 09:37:47 AM by joblo |
|
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.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
 |
January 26, 2020, 11:18:45 AM Last edit: February 05, 2020, 05:16:28 PM by joblo |
|
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.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
 |
January 26, 2020, 06:39:50 PM |
|
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.
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.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
 |
January 26, 2020, 08:15:11 PM |
|
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.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
 |
February 01, 2020, 06:20:25 AM Last edit: February 03, 2020, 02:37:59 AM by joblo |
|
Notice to API usersThis 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 Feb2Change will be in the next release. More details: https://github.com/JayDDee/cpuminer-opt/issues/234
|
|
|
|
alucard20724
|
 |
February 09, 2020, 06:09:24 AM |
|
@joblo
skein, skein2, and skunk fails for 3.11.8+ for avx2, and avx sha, however works fine for avx512. i've tested up to the most recent release with version 3.12.1. only tested avx512 on my i7-7820X. tested avx2 on 7820X, 9900K, and 8700K. tested avx sha on 3600, and 3900X
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
 |
February 09, 2020, 06:43:08 AM Last edit: February 09, 2020, 08:44:14 AM by joblo |
|
@joblo
skein, skein2, and skunk fails for 3.11.8+ for avx2, and avx sha, however works fine for avx512. i've tested up to the most recent release with version 3.12.1. only tested avx512 on my i7-7820X. tested avx2 on 7820X, 9900K, and 8700K. tested avx sha on 3600, and 3900X
Looks very similar to https://github.com/JayDDee/cpuminer-opt/issues/238, which I'm working on as I write. I'll make sure to test Skein & skein2 as well. I've been doing a lot of testing lately, There was more damage from the restructuring in the past couple of months than I realized. I don't test avx-sha because you miss out on 4 way parallel hashing on many algos, including skein. Going from 4 way AVX2 to 1 way even slows down Ryzen. Most Lyra2 based algos are ok with AVX because they can still do 4 way (and 16 way AVX512), but most other algos require AVX2. You should try both AVX & AVX2 to find the best for each algo. As far as SHA goes there is a crossover between HW sha256 and parallel SW sha256. With the current situation HW SHA is used up to and including AVX2, and parallel SW AVX512. When AMD improves AVX2 that may change. Edit: Yup. Same problem, same fix.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
 |
February 09, 2020, 06:41:43 PM |
|
@joblo
skein, skein2, and skunk fails for 3.11.8+ for avx2, and avx sha, however works fine for avx512.
I just released cpuminer-opt-3.12.2 which fixes xevan skein & skein2 but I overlooked skunk. It will be in the next release. It also uses skein as the first funtion in the chain so it's the same issue.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
 |
February 09, 2020, 07:47:44 PM |
|
FYI:
scryptn2 == scrypt:1048576
|
|
|
|
JayDDee
|
 |
February 13, 2020, 07:58:20 PM |
|
Guess who?
With some scammers trying to peddle malware disguised as cpuminer-opt I decided to take some action to protect my identity and created a new BCT user more closely associated with my real identity.
This user is still a newbie and should be treated as one. Don't trust me, yet.
Over time I will move the cpuminer-opt discussion to a new thread started by me.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
 |
February 13, 2020, 08:00:26 PM |
|
Look who just joined BCT.
Yes, it's really me.
|
|
|
|
JayDDee
|
 |
February 13, 2020, 08:19:54 PM |
|
What an asshole. This multiple personality thing could be fun.  I'm going to begin posting under this user to increae my post count and remove the newbie restrictions. One of those restrictions seems to be I can't have a sig. I will also add a note to README.md at my github repository to confirm my identity. It will be in the next release.
|
|
|
|
|
|