|
I don't see much potential for ARM mining. It's intended for low power devices so it probably has
a bigger performance penalty than a performance oriented architecture. The cost of scaling to x86_64
performance woulbe higher. It's also limited to 128 bit vectors (NEON) at this time while Intel will
have 512 bit vectors on mainstream CPUs later this year. On the software side all the optimized
x86_64 code would have to be rewritten for NEON. That's a huge task. When it comes to mining,
the bigger the better, like a Xeon Phi.
|
|
|
|
can anyone give me a link on how to under clock my CPU mining?
I have a GPU rig working in another room, but using my laptop to play around and learn about CPU mining.
using awesome mining, with miningpoolhub digging for Electroneum.
click everything I can click and it looks like I can't just tell awesome mining to use less CPU power.
I did find I can run a VR and only allocate X number of cores and memory to the program, but IMO that is too much work on my personal gaming rig just to play around with.
With out this ability, I will only mine about an hour at a time and shut it down for a few hours. can't take a chance to hurt my 8 core i7 as it is my work horse for everything else other then mining.
Thanks for any help and links.
geoff
You're bettter off looking in forums dedicated to CPU overclocking. I don't know if laptop CPUs can do it. |
|
|
|
Cpuminer can only use cores it can see. If it won't use the second package it's because it can't see it.
That's an OS issue.
 HWMonitor (and many other softwares) can see the second CPU, so IMHO it's not an OS issue. If you want to further investigate the issue, I can do testing for you. Thank you again. You're right, it's not an OS issue, it's a user issue. The OS is only doing what the user configured it to do. |
|
|
|
|
Cpuminer can only use cores it can see. If it won't use the second package it's because it can't see it.
That's an OS issue.
|
|
|
|
CPU affinity is not working as expected (by me  ) on dual Xeon E5-2460v3 on Windows 2012 R2 I want to use only 1 thread per physical core on both the CPUs, but I'm not able to do it. I'm testing v3.7.9 with the following cmd line: cpuminer-aes-avx2 -a lbry -t 16 --cpu-affinity 0xAAAAAAAA [...] I'd like to spread the threads over the 16 available physical cores, but I'm only able to saturate 16 logical processor of the first CPU:  No matter what I set in the affinity option, I always obtain the same result. If I start cpuminer with "-t 1" I get 526 kH/s per CPU, when I start it with "-t 16" I obtain only 249 kH/s per CPU. On a single CPU system with 8 cores and 16 logical cpu, I'm able to obtain exactly what I want with affinity. Like the pevious guy you're creating a problem where there is none. Use the default affinity and don't make assumptions. If you want to see which physical cores are working look at their temperature. If you have a problem after that post debug output. |
|
|
|
Can anybody explain me what is the meaning of "4way optimization" or give me a link to read about it? Will this optimization also be available for the hodl algorithm in the future? Thanks a lot!
It's all in this thread. |
|
|
|
Hi, i have a little problem, i have a dual E5649, when i set the thread count to 12 i have like 400 H/s with cryptonight, but when i set the thread count to 24 i have like 270 H/s, i was thinking that maybe if i set the --cpu-affinity to some value i can run another instance that use the other 12 cores.
How do you know it's not using both CPUs? What about the obvious, don't set the thread count and use the default? Also don't force me to make assumptions like what OS you're using, miner version, how/if you compiled etc. Sorry, I know im not using both looking at "top"  Interesting i have a little better performance using taskset -c 0,1,2,3,4,5,6,7,8,9,10,11 before the ./cpuminer (i expected to get better performance with even or odd cores considering that when i run numactl -H i get the even cores on one node and odd on the other) If i don't set the thread count it uses all the cores but the performance drops to ~300 H/s. Miner version is 3.7.9 and was compiled following the instructions on https://github.com/JayDDee/cpuminer-opt/blob/master/RELEASE_NOTES , im mining XMR and the OS is Centos 7. You're reading top wrong. With 12 threads it's using 12 of the 24 logical cores. You have 12 physical cores with 12 threads. You're jumping to the wrong conclusion. Now the issue is clear. Your problem is the number of miner threads, not the cpu affinity. For cryptonight the optimum thread count is: threads = L3 cache size / 2MB. Your CPUs have 12 MB each so that's 12 threads. Default affinity should spread them over all physical cores. |
|
|
|
Hi, i have a little problem, i have a dual E5649, when i set the thread count to 12 i have like 400 H/s with cryptonight, but when i set the thread count to 24 i have like 270 H/s, i was thinking that maybe if i set the --cpu-affinity to some value i can run another instance that use the other 12 cores.
How do you know it's not using both CPUs? What about the obvious, don't set the thread count and use the default? Also don't force me to make assumptions like what OS you're using, miner version, how/if you compiled etc. |
|
|
|
Finally I can mine with the tool on my ubuntu server and realized that the difficulty for cryptonight is pretty high thus resulting in a low mining performance. This has already been discussed before.
Now I have 10 ubuntu servers with ryzen 1700X CPUs.
Is there anyway to bundle the hashing power together to mine as one unit in order to get atleast the threshold needed to have a "stable" mining performance rather than just doing a stopNgo mining?
If all 10 servers mine with their standalone hashing power VS. bundling them as one hashing unit. Is there any way to do this to mine for nicehash servers?
Sincerely
Stratum proxy. |
|
|
|
Interesting and probably faster because it's benchmark tested. He had the benefit of seeing the results and tweaking. I gave up on super-optimizing memcpy and went with a simpler approach because all I wanted was to avoid some the overhead to detect alignment, odd sizes and vector capabilities. Most of the memcpy in cpuminer is with aligned data and integral sizes. |
|
|
|
New in v3.7.9
Partial 4way optimizations for veltor, skunk, polytimos, lyra2z. Thank you for the update and for you great work. Is lyra2z same as lyra2z330 and lyra2zoin? No, lyra2z is for zcoin. |
|
|
|
Claymore would probably do much better for 2 reasons:
a. it autodetects the amount of cache and amount of necessary threads
try allocating 1 thread per each 2mb of L2 cache you have
b. it supports memory locking mechanism that speeds up memory transfers
cpuminer is good in many things, but cryptonight is not one of them )
Aye, after writing this I tried setting "-t 8" as my CPU has 16MB of L3 cache, but there was no real change (if anything, it might have been a little slower!?). Also should have mentioned I always run miners as administrator just in case large memory pages can be used, but, apparently this is not the case here. Ah well, I'll keep my eye on this project anyway because I like rooting for the underdogs. There's definitely a problem at your end. I get 280 H/s on a i7-6700K with 8 MB L3 cache and 4 threads. Check your CPU load to make sure all cores are working. You may have to set a custom cpu-affinity. I don't have a Ryzen so I don't have any personal experience but you could browse back in this thread. There have been discussions about this gfrom real Ryzen owners. But as someone else pointed out I'm falling behind with cryptonight for a couple if reasons. There is a lot of competition for cryptonight and I don't feel like enterring that race. One reason I haven't implemented large pages yet is the need to be admin to use it on Windows. |
|
|
|
cpuminer-opt-3.7.9 Partial 4way optimizations for veltor, skunk, polytimos, lyra2z. Additional 4way optimizations for X algos. New algo yescryptr8 for BitZeny, not to be confused with original yescrypt Globalboost-Y. https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.7.9This release marks a milestone for cpuminer-opt. All 11 functions of x11 are now optimized. 5 have 4-way AVX2, 2 have serial AVX2, 3 have AES & SSE2 and 1 has only SSE2. nice... running 4way now with lyra2z on i7-7820X... shares are being accepted on miningpoolhub. thanks How does the hash rate compare? I saw less than 1% improvement on i7-6700K. |
|
|
|
cpuminer-opt-3.7.9 Partial 4way optimizations for veltor, skunk, polytimos, lyra2z. Additional 4way optimizations for X algos. New algo yescryptr8 for BitZeny, not to be confused with original yescrypt Globalboost-Y. https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.7.9This release marks a milestone for cpuminer-opt. All 11 functions of x11 are now optimized. 5 have 4-way AVX2, 2 have serial AVX2, 3 have AES & SSE2 and 1 has only SSE2. |
|
|
|
Hi. I tried multiple times to use the API feature but I think I didn't get how it works. I tried to open in Chrome http://127.0.0.1:4048 but I received "ERR_EMPTY_RESPONSE", same if I try http://127.0.0.1:4048/apiI also tried with telnet 127.0.0.1 4048 but I don't receive any response there as well. I am using the release version for Windows x64 3.7.8 You need to enter a command in telnet to get anything, start with help. |
|
|
|
First use hex because it's easier to map the bits to cores. 255 = 0x00ff = 0b0000000011111111
Only 8 bits/cores for 16 threads?
My previous post showed how to run 14 miner threads leaving one core (2 threads) free.
Some users when mining 8 threads have reported better performance with affinity 0x5555.
Second, priority isn't very useful unless you're also running background tasks and want to
prioritize between them and mining.
i didn't see what a different using hexa or dec im try 255, its running well 1700x yescryptr16 avx-sha around 1300khs (many reject) 4way-sha around 1200khs (many reject) avx2 around 1100khs (many reject) the reject appears after difficulty pool has changed im not tested long day because have ram problem stability (3200mhz)  I didn't say there was a difference with hex, I said it's easier to understand. As an example which cores are used with affinity= 43690? If you think it's running well with 16 threads and affinity 255 then you don't understand, That's only 8 cores for 16 threads meaning you have 8 cores idle and 8 cores with 2 threads each. The rejects and the share flood are pool issues. |
|
|
|
Hi Dev,
Can you please let me know the steps to install cpuminer in centos 6 as I am getting error.
algo/m7m.c:369: warning: implicit declaration of function ‘mpz_clears’
make[2]: *** [algo/cpuminer-m7m.o] Error 1
make[2]: *** Waiting for unfinished jobs....
mv -f algo/.deps/cpuminer-lbry.Tpo algo/.deps/cpuminer-lbry.Po
mv -f .deps/cpuminer-util.Tpo .deps/cpuminer-util.Po
mv -f .deps/cpuminer-cpu-miner.Tpo .deps/cpuminer-cpu-miner.Po
make[2]: Leaving directory `/root/cpuminer-opt'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/cpuminer-opt'
make: *** [all] Error 2
strip: 'cpuminer': No such file
[root@host cpuminer-opt]#
You didn't actually show the error but Centos6 is too old. |
|
|
|
any suggestions?
Yes. Read a few posts back, it's been discussed. |
|
|
|
Now that m7m is back (hashrefinery), some m7m numbers for cpuminer-opt v3.7.8v2 (maybe should call it 3.7.8.1, lol).
Ryzen Threadripper 1950X @ 3.7 GHz
sse2
545 kH/s
avx-sha
565 kH/s
4way-sha
545 kH/s
aes-avx
550 kH/s
aes-avx2
535 kH/s
aes-sse42
516 kH/s
sse42
580 kH/s
Those results are very suspicious, Particularly the fastest is sse42 and the slowest is aes-sse42.There is no aes in m7m so they should be identical. Also the sha builds are not significantly faster than the equivalent non-sha, but are significantly slower than sse42. I don't know why but I don't think it's due to mislabeled files. |
|
|
|
Hi Joblo! 3.7.8 avx-sha is better than ever! Im mining m7m algo, but I mine with both GPUs and Ryzen. The 16thread mining are slowing down the GPUs mining. How could I set CPU affinity for all threads but CPU0 (or threads 0 and 1)? I searched for an option to do it, but I havent found nothing  EDIT:' I found it: https://phempshall.github.io/cpuminer-affinity-setter/works  i wanna ask, for ryzen 7 do you use --cpu-affinity 255 --cpu-priority 4? or --cpu-affinity 255 --cpu-priority 2 what's different? First use hex because it's easier to map the bits to cores. 255 = 0x00ff = 0b0000000011111111 Only 8 bits/cores for 16 threads? My previous post showed how to run 14 miner threads leaving one core (2 threads) free. Some users when mining 8 threads have reported better performance with affinity 0x5555. Second, priority isn't very useful unless you're also running background tasks and want to prioritize between them and mining. |
|
|
|
|
Show Posts
