joblo (OP)
Legendary
 Offline
Activity: 1470
Merit: 1114
|
 |
April 06, 2016, 11:09:37 PM |
|
No CPU mining here but I like your style,
0cc24f5a79ad5200fc546bd534523d2cb25da73420830d59eed7c9cf4732e99b
Cheers!
WOW, my first donation. Many thanks. I'll have to make sure I don't post any sarcastic replies to any of your mining questions, CPU or otherwise. |
|
|
|
|
|
|
|
|
|
|
It is a common myth that Bitcoin is ruled by a majority of miners. This is not true. Bitcoin miners "vote" on the ordering of transactions, but that's all they do. They can't vote to change the network rules.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
th3.r00t
|
|
April 07, 2016, 08:49:44 AM |
|
Is it me ot the new algo is missing from help? ~/cpuminer-opt-3.1.10/cpuminer --help
********** cpuminer-opt 3.1.10 ***********
A CPU miner with multi algo support and optimized for CPUs
with AES_NI extension.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
Forked from TPruvot's cpuminer-multi with credits
to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
Wolf0 and Jeff Garzik.
Checking CPU capatibility...
Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
CPU Supports AES_NI: YES.
SW Supports AES_NI: YES.
Start mining with AES_NI optimisations...
Usage: cpuminer-opt [OPTIONS]
Options:
-a, --algo=ALGO specify the algorithm to use
scrypt scrypt(1024, 1, 1) (default)
scrypt:N scrypt(N, 1, 1)
sha256d SHA-256d
pentablake Pentablake
quark Quark
qubit Qubit
shavite3 Shavite3
x11gost sib (SibCoin)
skein Skein+Sha (Skeincoin)
skein2 Double Skein (Woodcoin)
s3 S3
vanilla blake256r8vnl
x11 X11
x13 X13
x14 X14
x15 X15
x17
yescrypt
zr5 ZR5
-o, --url=URL URL of mining server |
|
|
|
|
ryen123
|
|
April 07, 2016, 09:06:52 AM |
|
Is it me ot the new algo is missing from help? It works for me, hodl algo is there and works. Maybe you compiled without libboost. See the OP about requirement. ********** cpuminer-opt 3.1.10 ***********
A CPU miner with multi algo support and optimized for CPUs
with AES_NI extension.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
Forked from TPruvot's cpuminer-multi with credits
to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
Wolf0 and Jeff Garzik.
Checking CPU capatibility...
Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz
CPU Supports AES_NI: YES.
SW Supports AES_NI: YES.
Start mining with AES_NI optimisations...
Usage: cpuminer-opt [OPTIONS]
Options:
-a, --algo=ALGO specify the algorithm to use
scrypt scrypt(1024, 1, 1) (default)
scrypt:N scrypt(N, 1, 1)
sha256d SHA-256d
axiom Shabal-256 MemoHash
blake Blake-256 (SFR)
blakecoin blake256r8
blake2s Blake-2 S
bmw BMW 256
c11 flax
cryptolight Cryptonight-light
cryptonight Monero
decred
drop Dropcoin
fresh Fresh
groestl groestl
hodl hodlcoin
heavy Heavy
keccak Keccak
luffa Luffa
lyra2re lyra2
lyra2rev2 lyrav2
myr-gr Myriad-Groestl
neoscrypt NeoScrypt(128, 2, 1)
nist5 Nist5
pluck Pluck:128 (Supcoin)
pentablake Pentablake
quark Quark
qubit Qubit
shavite3 Shavite3
x11gost sib (SibCoin)
skein Skein+Sha (Skeincoin)
skein2 Double Skein (Woodcoin)
s3 S3
vanilla blake256r8vnl
x11 X11
x13 X13
x14 X14
x15 X15
x17
yescrypt
zr5 ZR5
|
|
|
|
|
th3.r00t
|
|
April 07, 2016, 09:09:49 AM |
|
I have the dependencies installed:
libboost-dev
libboost-system-dev
libboost-thread-dev
Can you she your ./configure ?
|
|
|
|
|
ryen123
|
|
April 07, 2016, 09:23:21 AM |
|
./configure CFLAGS="-Ofast -march=corei7-avx" CXXFLAGS="-Ofast -march=corei7-avx" --with-crypto --with-curl
|
|
|
|
|
th3.r00t
|
|
April 07, 2016, 09:34:35 AM |
|
./configure CFLAGS="-Ofast -march=corei7-avx" CXXFLAGS="-Ofast -march=corei7-avx" --with-crypto --with-curl
Thanks. Nope, that does'nt work for me. Still no HOdl in list. Maybe I should include somehow required boost libs? |
|
|
|
|
ryen123
|
|
April 07, 2016, 09:37:59 AM |
|
Just to point out, my pc is running ubuntu 14.04 and I install the entire libboost lib (libboost1.55-all-dev). Not individually.
|
|
|
|
|
th3.r00t
|
|
April 07, 2016, 09:50:26 AM |
|
Same here - Ubuntu 14.04 Server.
Installed libboost1.55-all-dev and still no luck.
|
|
|
|
|
ryen123
|
|
April 07, 2016, 09:58:54 AM |
|
Ok. Just to be clear these are my own steps.
1) Download cpuminer-opt-3.1.10.tar.gz and extract
2) ./autogen.sh
3) ./configure CFLAGS="-Ofast -march=native" CXXFLAGS="-Ofast -march=native" --with-crypto --with-curl
4) make -j4
5) strip cpuminer
Works for me.
|
|
|
|
|
th3.r00t
|
|
April 07, 2016, 10:21:42 AM |
|
Well... After reboot it compiled OK. -a, --algo=ALGO specify the algorithm to use
scrypt scrypt(1024, 1, 1) (default)
scrypt:N scrypt(N, 1, 1)
sha256d SHA-256d
axiom Shabal-256 MemoHash
blake Blake-256 (SFR)
blakecoin blake256r8
blake2s Blake-2 S
bmw BMW 256
c11 flax
cryptolight Cryptonight-light
cryptonight Monero
decred
drop Dropcoin
fresh Fresh
groestl groestl
hodl hodlcoin
heavy Heavy
keccak Keccak
luffa Luffa
lyra2re lyra2
lyra2rev2 lyrav2
myr-gr Myriad-Groestl
neoscrypt NeoScrypt(128, 2, 1)
nist5 Nist5
pluck Pluck:128 (Supcoin)
pentablake Pentablake
quark Quark
qubit Qubit
shavite3 Shavite3
x11gost sib (SibCoin)
skein Skein+Sha (Skeincoin)
skein2 Double Skein (Woodcoin)
s3 S3
vanilla blake256r8vnl
x11 X11
x13 X13
x14 X14
x15 X15
x17
yescrypt
zr5 ZR5 |
|
|
|
Epsylon3
Legendary
Offline
Activity: 1484
Merit: 1082
ccminer/cpuminer developer
|
|
April 07, 2016, 02:22:01 PM |
|
the build.sh script is made for that, it does a "make clean" before
tested, and i see a good hashrate on the miner side, but seems to be only 150H/s on pools side (both suprnova and blockquary)
|
|
|
|
|
th3.r00t
|
|
April 07, 2016, 03:31:28 PM |
|
the build.sh script is made for that, it does a "make clean" before
tested, and i see a good hashrate on the miner side, but seems to be only 150H/s on pools side (both suprnova and blockquary)
Yeah...  But recently we was discussing build.shI haven't looked at build.sh since the fork, I should clean it up.
It got me errors on AMD SSE2 compile and slower binary on Intel i7. Epsylon3, thanks for cpuminer-multi, which is the main base for this great cpuminer! |
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
|
April 07, 2016, 04:08:40 PM |
|
the build.sh script is made for that, it does a "make clean" before
tested, and i see a good hashrate on the miner side, but seems to be only 150H/s on pools side (both suprnova and blockquary)
Yes that is a problem. I don't understand, the hashrate calculation is very simple and the hashes_done calculation is all self contained in the algo source file. scanhash_hodl is counting the collisions and the miner thread measures the time and it's a simple division. I don't see where it could go wrong. It happens with both AES_NI and NON_AES_NI implementations of hodl. It doesn't happen with any other algo. If the hashes_done calculation is wrong then it is in code was copied as-is from the original hodlminer. If the time is wrong it is in code that is the same for all algos. The only other thing I can think of is phantom accepts or silent rejects. Either the miner is dsplaying shares that were never submitted or not reporting shares that were rejected. It happens with both AES_NI and NON_AES_NI implementations of hodl. It doesn't happen with any other algo. The pool reported hashrate appears to be inline with both precedessors, although it's hard to be sure with the flunctuations. I've seen it as high as 400 H/s with both Wolf and opt/wolf on an i7-4790K and i7-6700K repsectively. I will do some instrumenting to gather data to see if I can figure out what's going on. FYI, I haven't maintained build.sh, so YMMV |
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
|
April 07, 2016, 04:10:22 PM |
|
Epsylon3, thanks for cpuminer-multi, which is the main base for this great cpuminer!
Hear! Hear! He has made my job much easier. |
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
|
April 07, 2016, 06:28:51 PM
Last edit: April 07, 2016, 08:22:19 PM by joblo |
|
Here's some data i colllected for hashrates [2016-04-07 14:22:25] 1 miner threads started, using 'hodl' algorithm.
[2016-04-07 14:22:28] Stratum difficulty set to 1
[2016-04-07 14:22:38] scanh start hashes done= 0
[2016-04-07 14:22:44] scanh ret 1 hashes done= 328
[2016-04-07 14:22:44] diff.tv_sec= 6 usec= 16424
[2016-04-07 14:22:44] thr rate= 54.517434
[2016-04-07 14:22:44] CPU #0: 54.52 H/s
[2016-04-07 14:22:44] accepted: 1/1 (100%), 54.52 H/s yes!
Everything adds up. This is exactly what it's getting back from the scan. The problem must be happening later with the submission. Edit: I think I have found a long standing bug. When a share is submitted the miner reports the sum of the hashrates of the last scan of each thread. That's is usually a good approximation but doesn't take into account failed scans. It also doesn't take into account super-scans where a solution is found by 2 threads at the same time. A share is submitted only when the scan returns success. Otherwise the scan was wasted time. This wasted time doesn't get measured by the miner but the pool sure notices the delay since the last submit. That appears to account for discrepency between the miner rate and the pool rate. Fixing that will take some thought. The displayed share submission rate should be the sum of all the scans since the last submission. This will cause volatility in the displayed hashrates but they will be accurate and should match the pool. The per-thread hashrate could also be improved. The display could indicate when a scan has suceeded or failed. That problem seems understood but now the issue is why so many scans fail. I'm going to try to fix that before redesigning the hashrate display. |
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
|
April 07, 2016, 09:15:10 PM |
|
I think I need to redeesign the hashrate display in order to troubleshoot the scan failures, first to quantify and compare with other miners. I've added a quick efficiency factor by simply using the inverse of the number of fails between successes. 100% means every thread is successful on every scan. The efficiency is also already indicated by the number of thread hashrate lines between shares. Here's what it looks like. [2016-04-07 17:12:20] CPU #7: 32.76 H/s
[2016-04-07 17:12:20] scan efficiency 12.50%
[2016-04-07 17:12:20] accepted: 38/38 (100%), 415.59 H/s yes!
[2016-04-07 17:12:21] CPU #0: 64.15 H/s
[2016-04-07 17:12:21] scan efficiency 100.00%
[2016-04-07 17:12:21] accepted: 39/39 (100%), 427.02 H/s yes!
[2016-04-07 17:12:22] CPU #3: 65.58 H/s
[2016-04-07 17:12:22] CPU #4: 53.58 H/s
[2016-04-07 17:12:22] CPU #2: 49.79 H/s
[2016-04-07 17:12:22] CPU #6: 53.61 H/s
[2016-04-07 17:12:22] CPU #5: 54.44 H/s
[2016-04-07 17:12:22] CPU #1: 50.27 H/s
[2016-04-07 17:12:25] CPU #2: 67.54 H/s
[2016-04-07 17:12:25] scan efficiency 14.29%
[2016-04-07 17:12:25] accepted: 40/40 (100%), 441.93 H/s yes!
[2016-04-07 17:12:27] Stratum difficulty set to 4.96669
[2016-04-07 17:12:27] CPU #6: 58.60 H/s
[2016-04-07 17:12:27] CPU #5: 58.98 H/s
[2016-04-07 17:12:27] CPU #4: 53.22 H/s
[2016-04-07 17:12:27] CPU #1: 45.70 H/s
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
|
April 07, 2016, 09:55:58 PM |
|
Something is bugging me about hashrates. First I will point out that the current method the miner
reports hashrate generally agrees with the pools.
This bugs me for the simple reason that one thread finds the solution but the reported hashrate
is the sum of all threads. The hashrate is only correct when a single thread finds a solution each scan.
If all 8 threads find a solution my pool rate would be 800% what the miner reports. This explains somewhat
why the pool sometimes reports hashrates much higher than the miner.
Now to the pools. They don't know how many threads are running, they just get a solution and the number of
hashes to find it (an assumption). They look at the size of the solution and the time it took to find it and
calculate a hashrate. How in hell could the miner ever agree? I must be missing something.
I've been running for about 120 accepts calculating an average efficiency and it's running at about
7%.
That's 7% of 800% = 56%.
Miner reports 450 H/s, multiply by 56% = 252 H/s.
That should be my actual hashrate at the pool.
I think I need to let that sink in for a while. I'm getting dizzy.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
|
April 08, 2016, 02:00:24 AM |
|
My theory was wrong, at least with respect to hodl. With hodl the threads work cooperatively
by spliting the scratchpad into sections with each thread searching their own section. First thread
to find it scores a collision.
I had a bug that was getting new work in every thread.
That seems to have solved the most important part of the problem, the hashrate reported at the pool.
Unfortunately it's not the same high hashrate still being reported by the miner.
I will likely build another release with this fix and continue to investigate the local hashrate display issue.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
|
April 08, 2016, 03:31:02 AM |
|
Release 3.1.11 of cpuminer-opt is available for download. https://drive.google.com/file/d/0B0lVSGQYLJIZZ3VCOERfMHZiQmM/view?usp=sharingNew in 3.1.11 - hodl algo hashrate issue partially fixed. Errata: The hash rate reported at the pool should now be the same as hodlminer-wolf although the miner stilll reports an erroneously high rate. The performance chart uses the pool reported rate. - argon2 algo added, 6% faster than encel version |
|
|
|
citronick
Legendary
Offline
Activity: 1834
Merit: 1080
---- winter*juvia -----
|
|
April 08, 2016, 05:12:57 AM |
|
Hi All,
I recently inherited an AMD FD8350FRHKBOX FX-8350 FX-Series 8-Core Black Edition Processor.
My mining experience are GPU and ASICs, and a forum member recommended I visit this thread to get help and ideas.
Any ideas how can I use this CPU to mine the most profitable CPU only alt-coins?
Cheers!
|
If I provided you good and useful info or just a smile to your day, consider sending me merit points to further validate this Bitcointalk account ~ useful for future account recovery...
|
|
|
|
