a little speedup by better compiling:
Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz
AES_NI: No.
SSE2: No, start mining without optimizations...
[....]
[2016-01-26 13:39:37] accepted: 7/7 (100.00%), 224.92 kH/s yes!
about 5-10% more by using this commandline (to be adapted to your own cpu):
./configure CFLAGS="-march=nehalem -Ofast -DNO_AES_NI" CXXFLAGS=$CFLAGS --with-crypto --with-curl
and remember to "make clean"
Think any of this would help me to get a completion compile on the problem AMD system I posted about a few pages back? https://bitcointalk.org/index.php?topic=1326803.msg13657053#msg13657053the cpu doesn't look to have AES: did you try compiling with -DNO_AES_NI? I just tried that and still get errors. maybe someone could help me on this one I'm a real noob with this stuff. ./configure CFLAGS="-march=?  ?? -Ofast" CXXFLAGS=$CFLAGS --with-crypto --with-curl ?? Processors Information
-------------------------------------------------------------------------
Processor 1 ID = 0
Number of cores 8 (max 8)
Number of threads 8 (max 8)
Name AMD Opteron 6124
Codename Magny-Cours
Specification AMD Opteron(tm) Processor 6124 HE
Package Socket G34 (1974)
CPUID F.9.1
Extended CPUID 10.9
Core Stepping HY-D1
Technology 45 nm
TDP Limit 74.4 Watts
Core Speed 1039.8 MHz
Multiplier x Bus Speed 4.0 x 259.9 MHz
HT Link speed 2859.4 MHz
Stock frequency 1800 MHz
Instructions sets MMX (+), 3DNow! (+), SSE, SSE2, SSE3, SSE4A, x86-64, AMD-V
L1 Data cache 8 x 64 KBytes, 2-way set associative, 64-byte line size
L1 Instruction cache 8 x 64 KBytes, 2-way set associative, 64-byte line size
L2 cache 8 x 512 KBytes, 16-way set associative, 64-byte line size
L3 cache 10 MBytes, 96-way set associative, 64-byte line size
FID/VID Control yes
FID range 4.0x - 9.0x
Max VID 1.050 V
# of P-States 5
P-State FID 0x2 - VID 0x2F - IDD 6 (9.00x - 0.962 V)
P-State FID 0x0 - VID 0x31 - IDD 6 (8.00x - 0.937 V)
P-State FID 0x10A - VID 0x34 - IDD 5 (6.50x - 0.900 V)
P-State FID 0x106 - VID 0x35 - IDD 4 (5.50x - 0.887 V)
P-State FID 0x100 - VID 0x37 - IDD 4 (4.00x - 0.862 V)
Package Type 0x3
Model 25
String 1 0x0
String 2 0x0
Page 0x0
CmpCap 8
ApicIdCoreSize 16
TDC Limit 48 Amps
Boosted P-States 0
Max non-turbo ratio 9.00x
Max turbo ratio 9.00x
Max CPU COF 18
Core Performance Boost no
P-State 0, FID 0x2 - VID 0x2F (9.00x - 0.962 V)
P-State 1, FID 0x0 - VID 0x31 (8.00x - 0.937 V)
P-State 2, FID 0x10A - VID 0x34 (6.50x - 0.900 V)
P-State 3, FID 0x106 - VID 0x35 (5.50x - 0.887 V)
P-State 4, FID 0x100 - VID 0x37 (4.00x - 0.862 V)
Attached device PCI device at bus 0, device 24, function 0
Attached device PCI device at bus 0, device 24, function 1
Attached device PCI device at bus 0, device 24, function 2
Attached device PCI device at bus 0, device 24, function 3
Attached device PCI device at bus 0, device 24, function 4
TSC 2339.8 MHz
Temperature 0 29°C (84°F) [0xE8] (Core #0)
Power 0 27.60 W (Package) First post your console session with your command line and error messages. * And stick with the instructions in the READme.md file. You've got an AMD Opteron 64 so try to find a match https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html* I can be prickly, so be careful with your questions, This is your first warning. I'm not trying to be mean, it just happens, so don't take it personally. Well formulated questions with supporting data and a demonstration you did your best to solve it will always get the best response (and not just from me). |
|
|
|
Mining with an Intel GPU? I need to look into that. No source? I want to import the Intel GPU mining. I wanna expand my territory. Went googling, found out cgminer 3.7 supports Intel GPU mining. Hard to find files, recent version dropped support. Found a source file and a windows binary that only does blake256. Haven't got the source compiled yet but gave the binary a spin with wine and blake at zpool. It found the GPU, connected to the pool and started hashing, but... all rejects. Maybe an incompatible form of blake. It's a start. Why is iy everytime I say I'm going to give windows another shot something really, really interesting pops up? |
|
|
|
Even more (x11):
[2016-01-26 15:00:11] accepted: 6/6 (100.00%), 229.12 kH/s yes!
With:
./configure CFLAGS="-march=nehalem -Ofast -fomit-frame-pointer -Wno-write-strings -funroll-loops -fvariable-expansion-in-unroller -ftree-loop-if-convert-stores -fmerge-all-constants -fbranch-target-load-optimize -fsched2-use-superblocks -DNO_AES_NI -DSPH_SMALL_FOOTPRINT_HAVAL -DSPH_KECCAK_UNROLL=1 -DSPH_KECCAK_NOCOPY -DSPH_KECCAK_INTERLEAVE=0 -DSPH_SMALL_FOOTPRINT_SHA2" CXXFLAGS=$CFLAGS --with-crypto --with-curl
YMMV
Did you get that from Wolf0's cryptonight? Yet another thing to look into is all those compiler switches. Some are obvious by their name but other I have no clue, yet. |
|
|
|
It doesn't support AES, it's a Nehalem.
I think the miner should be compiled with the best "-march" as it will impact the performance of most kernels, regardless how far your optimisations will go.
On a side note, I've found out that -march=native may lead to slower binaries than -march=<the best for your cpu>
AFAIK corei7-avx is tops do you know of anything better? The best is your right chipset name: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.htmlI was looking for something like that. It works down to nocona, only one generation older than core2 and the first with X86_64. It looks like the legacy code can be tossed unless I want to try supporting 32 bit. Naaah. I will include a link to that page in the build instructions. Edit: Core2 includes SSE4.1 and I recall seeing some hooks for that in the code. I may be able to define a new second tier for core 2 and better and improve their performance. Edit2: I tried haswell down to sandybride and none worked. corei7-avx worked. I'll do some performance comparisons to see if it makes a difference on my haswell. |
|
|
|
Cool. I didn't mean slack was obsolete, just that people who like it are old school. I've played with it but never any real work. At one time I had 8 different distros multibooted on 2 20GB HDDs running on a pentium 1. Now the're all in VMs. A guy I used to work with was a slackware fan. Give him the keyboard, toss the mouse, and he could do magic. He's was also pretty sharp in networking, knew his protocols inside out. I started using Linux with Slackware 2.0 :-) RH 5.2 for me, bought the CDs. I discovered Slack around v5 or 6, when PV was sick and out of action for a while. |
|
|
|
Is it correct that "SSE2: No"?
AFAICS, it runs fast anyway.
Checking CPU capatibility...
Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz
AES_NI: No.
SSE2: No, start mining without optimizations...
[2016-01-26 10:17:55] Starting Stratum on stratum+tcp://hashpower.co:3533
[2016-01-26 10:17:56] 4 miner threads started, using 'x11' algorithm.
[2016-01-26 10:17:56] Stratum difficulty set to 0.016
[2016-01-26 10:17:56] hashpower.co:3533 x11 block 1821843
[2016-01-26 10:17:56] hashpower.co:3533 x11 block 108239
[2016-01-26 10:18:01] CPU #1: 57.09 kH/s
[2016-01-26 10:18:01] CPU #0: 56.81 kH/s
[2016-01-26 10:18:01] CPU #2: 53.73 kH/s
[2016-01-26 10:18:02] CPU #3: 52.40 kH/s
[2016-01-26 10:18:18] CPU #0: 56.23 kH/s
[2016-01-26 10:18:18] CPU #3: 53.29 kH/s
[2016-01-26 10:18:18] CPU #1: 56.55 kH/s
[2016-01-26 10:18:18] CPU #2: 56.11 kH/s
Nope, it's a bug. I think it will be irelevant when I implement X86_64 compiling. But "-march=x86_64" won't configure. I don't know if it's the wrong target name or if GCC has dumped support for it. Maybe I need to install some compat packages. Edit: just checking your output again. even though it says no for SSE2 it should still the SSE2 kernel. Formyour hashrate it appears to be normal for and i5 SSE2. I guess the early corei didn't have AES_NI. Do you want to give it try to make sure? Just edit cpu-miner.c:1949 and hardcode cpu_aesni=true. Then compile with AES_NI enabled and let me know if it works. Thanks I intalled the x86_64 cross compiler and it still doesn't work. |
|
|
|
Is it correct that "SSE2: No"?
AFAICS, it runs fast anyway.
Checking CPU capatibility...
Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz
AES_NI: No.
SSE2: No, start mining without optimizations...
[2016-01-26 10:17:55] Starting Stratum on stratum+tcp://hashpower.co:3533
[2016-01-26 10:17:56] 4 miner threads started, using 'x11' algorithm.
[2016-01-26 10:17:56] Stratum difficulty set to 0.016
[2016-01-26 10:17:56] hashpower.co:3533 x11 block 1821843
[2016-01-26 10:17:56] hashpower.co:3533 x11 block 108239
[2016-01-26 10:18:01] CPU #1: 57.09 kH/s
[2016-01-26 10:18:01] CPU #0: 56.81 kH/s
[2016-01-26 10:18:01] CPU #2: 53.73 kH/s
[2016-01-26 10:18:02] CPU #3: 52.40 kH/s
[2016-01-26 10:18:18] CPU #0: 56.23 kH/s
[2016-01-26 10:18:18] CPU #3: 53.29 kH/s
[2016-01-26 10:18:18] CPU #1: 56.55 kH/s
[2016-01-26 10:18:18] CPU #2: 56.11 kH/s
Nope, it's a bug. I think it will be irelevant when I implement X86_64 compiling. But "-march=x86_64" won't configure. I don't know if it's the wrong target name or if GCC has dumped support for it. Maybe I need to install some compat packages. Edit: just checking your output again. even though it says no for SSE2 it should still the SSE2 kernel. Formyour hashrate it appears to be normal for and i5 SSE2. I guess the early corei didn't have AES_NI. Do you want to give it try to make sure? Just edit cpu-miner.c:1949 and hardcode cpu_aesni=true. Then compile with AES_NI enabled and let me know if it works. Thanks It doesn't support AES, it's a Nehalem. I think the miner should be compiled with the best "-march" as it will impact the performance of most kernels, regardless how far your optimisations will go. On a side note, I've found out that -march=native may lead to slower binaries than -march=<the best for your cpu> AFAIK corei7-avx is tops do you know of anything better? |
|
|
|
Mining with an Intel GPU? I need to look into that. No source? I want to import the Intel GPU mining. I wanna expand my territory. |
|
|
|
Is it correct that "SSE2: No"?
AFAICS, it runs fast anyway.
Checking CPU capatibility...
Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz
AES_NI: No.
SSE2: No, start mining without optimizations...
[2016-01-26 10:17:55] Starting Stratum on stratum+tcp://hashpower.co:3533
[2016-01-26 10:17:56] 4 miner threads started, using 'x11' algorithm.
[2016-01-26 10:17:56] Stratum difficulty set to 0.016
[2016-01-26 10:17:56] hashpower.co:3533 x11 block 1821843
[2016-01-26 10:17:56] hashpower.co:3533 x11 block 108239
[2016-01-26 10:18:01] CPU #1: 57.09 kH/s
[2016-01-26 10:18:01] CPU #0: 56.81 kH/s
[2016-01-26 10:18:01] CPU #2: 53.73 kH/s
[2016-01-26 10:18:02] CPU #3: 52.40 kH/s
[2016-01-26 10:18:18] CPU #0: 56.23 kH/s
[2016-01-26 10:18:18] CPU #3: 53.29 kH/s
[2016-01-26 10:18:18] CPU #1: 56.55 kH/s
[2016-01-26 10:18:18] CPU #2: 56.11 kH/s
Nope, it's a bug. I think it will be irelevant when I implement X86_64 compiling. But "-march=x86_64" won't configure. I don't know if it's the wrong target name or if GCC has dumped support for it. Maybe I need to install some compat packages. Edit: just checking your output again. even though it says no for SSE2 it should still the SSE2 kernel. Formyour hashrate it appears to be normal for and i5 SSE2. I guess the early corei didn't have AES_NI. Do you want to give it try to make sure? Just edit cpu-miner.c:1949 and hardcode cpu_aesni=true. Then compile with AES_NI enabled and let me know if it works. Thanks Edit2: I intalled the x86_64 cross compiler and it still doesn;t work. |
|
|
|
Mining with an Intel GPU? I need to look into that. |
|
|
|
Numbers are looking very good on the 3 I have setup with v3.03.
2xSR2 have 24 cores if you count HT cores 1xSR2 has 20 cores counting HT. "E5620+E5645 CPU"
3.2GHz 1002 KH/s 21 of 24 cores used in the command line VB set to 24 cores. No mining video cards.
3.33Ghz 924.80 kH/s 21 of 24 cores used in the command line VB set to 22 cores. 2x R270 and why I left 2 unused by the VM. << should get a little better numbers once I set this one full 24 cores.
3.6Ghz 790 KH/s 17 of 20 cores used in the command line VB set to 20 cores. 2x R270x
I've found odd numbers with some free cores seems to give just a little better KH/s.
the free cores helps keep my video cards running at there max MH/s. Full load on all
CPU cores hurts the video cards & no real improvement to the CPU scores either.
This is due to running in a VBox, learned this back with Folding@Home, so nothing new there.
Thanks for posting your results. Running all cores does afffect GPU performance on the same machine and we don't want to do that. It's also cool you can do it in a VM. |
|
|
|
Edit: Packages I have to install in order for it to compile:
sudo apt-get install libssl-dev
sudo apt-get install libcurl4-openssl-dev
sudo apt-get install g++
Just a side note for anyone compiling this. I don't think the order matters in which each is
installed this is what I have to do on the systems I have setup so far.
Thanks, I'll add that to the build instructions in the next release. |
|
|
|
Cool. I didn't mean slack was obsolete, just that people who like it are old school. I've played with it but never any real work. At one time I had 8 different distros multibooted on 2 20GB HDDs running on a pentium 1. Now the're all in VMs. A guy I used to work with was a slackware fan. Give him the keyboard, toss the mouse, and he could do magic. He's was also pretty sharp in networking, knew his protocols inside out. |
|
|
|
i didnt trace to understand but xmr rejects the shares.. else i also use fedora 22 and 23, not yet centos... and ive an ubuntu 15.10 but dont really like it and some Slackware usb sticks  I pulled support for cryptonight at the last minute because I broke it. Use Wolf0's for now. Yeah I know I promissed. Oh well. Slackware? Old school. |
|
|
|
i got the same issue with the sse grso-asm.c with GCC 4.8.4 (ubuntu server 14.04.3 LTS)
look like the asm() style is incorrect
Thanks for popping in. I welcome and encourage your involvement. Edit: I've nere like ubuntu, even before they changed their desktop. I like Mint better but I still prefer the red hat family. If only I didn't have to add extra repositories all the time. I like te init system better although I'm still not comfortable with systemd. I flip flop betwen Fedora and Centos depending on wether I need the latest features. |
|
|
|
cpuminer v3.0.3 is released. https://drive.google.com/file/d/0B0lVSGQYLJIZT1cyRFJEeTd0cVk/view?usp=sharingIt fixes support for SSE2 capable CPUs, core2 family, and adds support for 2 more algos. The build instructions have changed, a new option is required for SSE capable CPUs. See the README.md file for details. See also the OP for more dtails about this release. I seem to have lost some hash in a few algos. I'll have to try to find it or maybe I smoked it. I will now take a little break and recharge before diving in to Windows again. This will likely be the last release in the 3.0 stream unless there are urgent issues or Windows continues to be delayed. A special thanks goes out to bobben2 for his excellent testing which helped solve the SSE2 issues. Enjoy |
|
|
|
I think I have something that works. I justhave to bundle it up and build another debug load for you.
It should run straight out of the box on your CPU.
But things aren't perfect. There are two problems I had to workaround.
The #define AES_NI in miner.h is not being seen in any files that reference AESNI. I therefore had
to add #define AES_NI in every file with any reference to AES_NI code.
The other problem is that has_sse2() isn't working so I hard coded it.
I tested it 4 ways:
1. AES_NI defined and march=native: my normal environment
2. AES_NI defined and march=core2. this fails to compile as expected.
3. AES_NI not defined and march=native, this compiles but performs at SSE2 rates as expected
4. AES_NI not defined and march=core2. this simulates your environment and works at SSE2 rates
as expected.
The only thing now is to confirm it works with the default build instructions on your machine and
performs at SSE2 levels.
Follow up items:
investigate why #define in miner.h not seen
Investigate has_sse2 failure
Investigate ways to define AES_NI from the configure command line,
It's currently setup so simulate a CPU without AES_NI and with SSE2
Edit: PM sent
Hi joblo, The package you sent almost built out of the box, but only after I modified the build.sh I removed the -p switch and added -march=native. With your original build.sh, the following two files threw compiler errors: 1. algo/sse2/groestl/grso-asm.c <- will not accept the -p switch. Perhaps the function call is using too many registers when in profiling mode 2. algo/aes_ni/echo512/hash.c <- tons of errors when not building with -march=native After fixing build.sh the produced executable ran fine. I also built on one of my Haswell I5s, but mining X11 shares never got accepted... EDIT: It Does accept shares on my I5. But the hash is much lower than the "standard" version (cpuminer-opt-3.0.2) - 84 vs 128 kH/s per thread. [/quote] Thanks very muchfor your testing. I have never used the build script so thanks for that too. Your haswelll performnce was lower because I rigged AES_NI to always be false and force it to use the SSE kernels. Test Passed! I'll have a new release out later today thanks to your testing. Cryptonight support coming, and maybe one or two more. |
|
|
|
The cpu check fails on this computer and I suspect cpuid has been disabled in the BIOS. I will check when I get a chance. I downloaded the code you sent. I had to do the following mods to get it to compile. 1. Commented out #define AES_NI and Added #ifdef AES_NI to effectively comment out code in algo/cryptonight/cryptonight-aesni.c. 2. Added #undef AES_NI in algo/aesni/echo512/hash.c since miner.h is not included. 3. Added #ifdef AES_NI_ON a lot of places in algo/aesni/groestl/groestl-intr-aes.h After these changes, I could leave both #define AES_NI #define AES_NI_ON 1 in miner.h and it compiled/runs fine. Hashrates: With cpu_sse2 = false I get [2016-01-24 13:05:53] CPU #0: 25.50 kH/s [2016-01-24 13:05:53] CPU #1: 25.50 kH/s Set to true: [2016-01-24 13:06:36] CPU #0: 43.38 kH/s [2016-01-24 13:06:36] CPU #1: 43.38 kH/s EDIT: You might want to move the calls to has_aes_ni() and has_sse2() to the top of main() and make the boolean flags global. So that these functions are not called every pass of the main loop. No need to call these more than once  I've di there was already some cpuid checks in the code that will all have to be consolidated/ It's not a priority because the check is not expensive and is only really done at startup. Your x86_64/SSE2 performance ratio is 25.0 / 43.38 = .58 my 4790K is 266 / 472 = ,56 That's pretty close. If effect your CPU SSE2's performance is just as good as mine. My only advantage is the addition of AES_NI and possibly higher power efficiency. There' slife in those old CPU yet. I'll take some time to digest the rest of your report, I just woke up. I think I have something that works. I justhave to bundle it up and build another debug load for you. It should run straight out of the box on your CPU. But things aren't perfect. There are two problems I had to workaround. The #define AES_NI in miner.h is not being seen in any files that reference AESNI. I therefore had to add #define AES_NI in every file with any reference to AES_NI code. The other problem is that has_sse2() isn't working so I hard coded it. I tested it 4 ways: 1. AES_NI defined and march=native: my normal environment 2. AES_NI defined and march=core2. this fails to compile as expected. 3. AES_NI not defined and march=native, this compiles but performs at SSE2 rates as expected 4. AES_NI not defined and march=core2. this simulates your environment and works at SSE2 rates as expected. The only thing now is to confirm it works with the default build instructions on your machine and performs at SSE2 levels. Follow up items: investigate why #define in miner.h not seen Investigate has_sse2 failure Investigate ways to define AES_NI from the configure command line, It's currently setup so simulate a CPU without AES_NI and with SSE2 Edit: PM sent |
|
|
|
I can confirm that old intel cpus (>= core2) can have performance/power similar to much newer amd processors.
So don't buy amd cpus for mining... well... do not buy any cpu for mining ;-)
Agreed, just use what you already have, which is why I'm trying to suport older HW. |
|
|
|
|
Latest github
Centos 6, EVGA 750ti SC
cuda 7.5 ---> 135 KH/s
pool rate 175 KH/S !!!
works at -i 15, crashes at -i 16
no nonce errors after 5 minutes
cuda 6.5
client: 125 KH/s client
pool: +/ 5%
same intensity limits
SP_MOD r74 cuda 6.5 ---> 105 Kh/s
same intensity limits
The pool rate can't be faked by the miner so congratulations, 70% increase.
This is a critical milestone for ccminer and cuda 7.5. It is proof it can be more efficient
than 6.5. I much prefer your approach of more substantial increases in performance
with a limited period of exclusivity for donors. Keep up the good work.
Edit: corrected cut/paste error.
|
|
|
|
|
Show Posts
