Ok, once more around the block with capabilities checks. Edit: made some changes and added more examples. Edit2: changed checking order to all AES variables first. For this quasi-debug release it wil continue to perform all checks. The production version will only check SSE2 in AES fails. For the debug release SSE2 support is taken literally but in the production version it will mean (SSE2 && !AES) to the YES/NO response is more appropriate. I am trying out a more detailed permissive check that will display all variables used and hopefuly give an informative message to the user. I hope this balances out the need for technical info and user-friendliness. The only risk is that the miner will always attempt to mine and may crash if incompatible. Here are some examples of the output most users are likely to see. I don't check for the newer features like AVX2 because they are not used in the decision making that determines the final message. AES: Checking CPU capatibility... Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz CPU arch has AES...........YES. CPU arch has AVX...........YES. SW built for AES & AVX.....YES. Algo supports AES & AVX....YES. System supports AES & AVX..YES. CPU arch has SSE2..........YES. SW built for SSE2..........YES. System supports SSE2.......YES. Start mining with AES-AVX optimizations...
SSE2: Checking CPU capatibility... Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz CPU arch has AES...........NO. CPU arch has AVX...........NO. CPU arch has SSE2..........YES. SW built for AES & AVX.....NO. SW built for SSE2..........YES. Algo supports AES & AVX....YES. System supports AES & AVX..NO. System supports SSE2.......YES. AES not available, starting mining with SSE2 optimizations...
Nehalem CPU using Westmere build: Checking CPU capatibility... Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz CPU arch has AES...........YES. CPU arch has AVX...........NO. CPU arch has SSE2..........YES. SW built for AES & AVX.....YES. SW built for SSE2..........YES. Algo supports AES & AVX....YES. System supports AES & AVX..NO. System supports SSE2.......YES. Unsupported CPU or SW configuration, miner will likely crash!
This will hopefully solve the issue for good. Only when this code has proven itself will I consider turning enforcement back on. At this time there are no pressing issues to prompt a new release. Too many releases in the past week. I'll wait for more feedback from users especially those with 1st gen corei CPUs before releasing. However I can provide the source code to those who can compile their own and are willing to share their test results. This change only affects the CPU capabilities check at miner startup so if you don't have any problems with that you don't need this and can wait for the general release.
|
|
|
whitespace cleaner tool alias trimfile="sed -r 's~[[:space:]]+\$~~g' -i"
To keep merge compatibility with joblo's google-drive dumps, I don't touch much. Cleaning up whitespace without joblo doing it in upstream will result in a lot of merge conflicts. What's the intended purpose? Whitespace is good. Whitespace is good. Endspace at end of lines is not good. http://vim.wikia.com/wiki/Remove_unwanted_spacesSo that command will only strip trailing whitespace, ok. Edit: I ran the sed command on a test file and it did nothing, it didn't strip any whitespace.
|
|
|
@joblo: i tried compiling the cpuminer-opt-3.3.4 on my ubuntu xenial laptop, the building complained about missing "-std=c++11" at some point, fixed it by manually editing the makefile on some 400ish line to include this. edit: g++ -DHAVE_CONFIG_H -I. -Iyes/include -Iyes/include -fno-strict-aliasing -I./compat/jansson -I. -Iyes/include -Iyes/include -g -O2 -MT algo/hodl/cpuminer-hodl.o -MD -MP -MF algo/hodl/.deps/cpuminer-hodl.Tpo -c -o algo/hodl/cpuminer-hodl.o `test -f 'algo/hodl/hodl.cpp' || echo './'`algo/hodl/hodl.cpp In file included from /usr/include/c++/5/unordered_map:35:0, from algo/hodl/hodl.cpp:11: /usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options. #error This file requires compiler and library support \ ^ Makefile:3176: recipe for target 'algo/hodl/cpuminer-hodl.o' failed You didn't read the new compile instructions or build.sh ./autogen.sh CFLAGS="-O3 -march=native -Wall" CXXFLAGS="$CFLAGS -std=gnu++11" ./configure --with-curl make
|
|
|
Trying to mine with suprnova.
What is wrong?
[03:25:11] Pool: 0 URL: stratum+tcp://xre.suprnova.cc:2114 User: mine Passwor d: mine [03:25:11] Press any key to exit, or sgminer will try again in 15s. [03:25:26] xre.suprnova.cc difficulty changed to 0.004 [03:25:27] No servers were found that could be used to get work from. [03:25:27] Please check the details from the list below of the servers you have input [03:25:27] Most likely you have input the wrong URL, forgotten to add a port, or have not set up workers [03:25:27] Pool: 0 URL: stratum+tcp://xre.suprnova.cc:2114 User: mine Passwor d: mine [03:25:27] Press any key to exit, or sgminer will try again in 15s.
suprnova requires you to set up a miner so your username would be like mine.miner1 or whatever you name it. Hope that's the problem for you. that was the problem, thank you, now its okay Shame to suprnova for making not obvious instructions. Weblogin.Worker is not that obvious like they think it is. You started this mess with your sarcastic comment about Suprnova. You are new and not familiar with the concept of login.worker. Nothing wrong with that for a newbie. The answer was direct and polite with no sarcasm. But then you crossed the line with your sarcastic comment and senior members rightfully called you out, so you pick a fight with them. Not a good introduction for you.
|
|
|
whitespace cleaner tool alias trimfile="sed -r 's~[[:space:]]+\$~~g' -i"
To keep merge compatibility with joblo's google-drive dumps, I don't touch much. Cleaning up whitespace without joblo doing it in upstream will result in a lot of merge conflicts. What's the intended purpose? Whitespace is good.
|
|
|
xeon e5 2670 X2 @361K HMQ1725
This speed is not abnormal?
Yes.
|
|
|
Thanks for your fix, but it's still not working. ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FA6QYbCa.png&t=663&c=HJLljue-ZhsspA) I get this and then crash. It's the same for nist5 and cryptonight. Thank you very much. This is important information. As mentioned in a subsequent post your CPU actually uses the nehalem compile arch, the westmere build is incompatible. This solves part of the mystery. There are two compile targets for 1st generation corei CPUs, Nehalem which will not run the miners' AES code, and Westmere which will. CMB has chosen to only support the AES optimizations with their binaries. I'm not sure why considering the apparent interest, particularly with nehalem. I continue to encourage Windows users to compile their own. That is always the best way
|
|
|
Here you go, Westmere capabilities check:
Checking CPU capatibility... Intel(R) Xeon(R) CPU E5649 @ 2.53GHz CPU arch supports AES-AVX...YES. SW built for AES-AVX........YES. Algo supports AES-AVX.......YES. Start mining with AES-AVX optimizations...
[2016-06-02 23:18:22] Starting Stratum on stratum+tcp://xre.suprnova.cc:2114 [2016-06-02 23:18:22] 24 miner threads started, using 'x11evo' algorithm.
Thanks, more good info. Based on the current implementation of the capabilities check, the fact the miner didn't crash and the hash rate you're getting I believe you are mining with AES on that Westmere. That changes things. I'm going to have to review previous data to see if it is consistent with this new data. I'll also wait for more new data from other users.
|
|
|
By the way, after that patch, I've found a bug: Checking compatibility of this cpuminer and CPU (Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz) cpuminer expects SSE2: YES. cpuminer expects AES: no cpuminer expects AVX: no CPU supports SSE2: YES. CPU supports AES: no CPU supports AVX: YES. requested algo supports AES+AVX: YES. [2016-06-03 04:57:04] 4 miner threads started, using 'hodl' algorithm.
See that "CPU supports AVX: yes"? That's a bug in has_avx(). For some reason the code you inherited returns yes if CPU either has AVX or OSXSAVE flag. Fix — https://github.com/hmage/cpuminer-opt/commit/5975fcf2ecad7057a254cc358e55434059124971I looked into this a bit more and there is more to this bug than I first thought. The way the flags are defined is illogical and does not agree with the wikipedia reference with no explanation for the discrepency. The coding does not seem like a typical error. That's not the kind of definition you do by mistake. This bizarre definition also applies to the FMA3 flag. These flags are used in best_cpu_feature function so one would think that if anyone ever used that function they might have noticed some bizarre results. That is all to say there might be some legitimacy to the way the flags are defined. I noted in the wikipedia article that the bit definitions were as of 2011. This suggests that the flags were different prior to 2011 which includes westmere. Even if the coding is legitimate I would not have done it that way. I woul dhave defined the bits individually and only used the compound expression when they were being read. I'm not convinced it is a bug. It may be a relic of a previous CPUID format. But it's a moot point because I don't intend to revisit this issue without a breakthrough.
|
|
|
sry just saw it on the first page.
Westmere Xeon E5649 now works fine, 2 CPU's are throwing ~700kH/s (using cpuminer.exe)
Sandybridge build on i5-2500K gets ~250kH/s
Older Xeon's E5540 (Gainestown) with only SSE2 support are starting miner but crashes every time after receiving first data (using cpuminer.exe)
Checking CPU capatibility... Intel(R) Xeon(R) CPU E5540 @ 2.53GHz CPU arch supports AES-AVX...NO. CPU arch supports SSE2.....YES. YES. Starting mining without AES-AVX optimizations...
Thank you for your testing, the crash of Gainstown is expected because it has no AES whatsoever. This proves the Westmere build is not compatible with core2, another significant data point. cpuminer-opt does work on core2 on linux (all algos) and Windows (all except hodl). This I have tested. You will either have to compile your own with -march=native or ask CMB to do it for you. Can you post the capabilities check results from the Westmere CPUs?
|
|
|
First snippet says no to AES, yes to SSE2, and yes for nothing.
Wrong. First snippet says yes to AES CPU, second snippet says YES to SSE2 CPU, third snippet say YES to SSE2 CPU again.
|
|
|
By the way, after that patch, I've found a bug: Checking compatibility of this cpuminer and CPU (Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz) cpuminer expects SSE2: YES. cpuminer expects AES: no cpuminer expects AVX: no CPU supports SSE2: YES. CPU supports AES: no CPU supports AVX: YES. requested algo supports AES+AVX: YES. [2016-06-03 04:57:04] 4 miner threads started, using 'hodl' algorithm.
See that "CPU supports AVX: yes"? That's a bug in has_avx(). For some reason the code you inherited returns yes if CPU either has AVX or OSXSAVE flag. Fix — https://github.com/hmage/cpuminer-opt/commit/5975fcf2ecad7057a254cc358e55434059124971cpuid on that machine reports that OSXSAVE flag is supported by this cpu but not AVX: $ cpuid -1|egrep -i 'avx|xsave' FXSAVE/FXRSTOR = true XSAVE/XSTOR states = true OS-enabled XSAVE/XSTOR = true AVX: advanced vector extensions = false AVX2: advanced vector extensions 2 = false AVX512F: AVX-512 foundation instructions = false AVX512PF: prefetch instructions = false AVX512ER: exponent & reciprocal instrs = false AVX512CD: conflict detection instrs = false XSAVE features (0xd/0): XCR0 field supported: AVX state = false XCR0 field supported: AVX-512 state = false bytes required by XSAVE/XRSTOR area = 0x00000240 (576) XSAVE features (0xd/1): XSAVEOPT instruction = false XSAVEC instruction = false XSAVES/XRSTORS instructions = false
I need to make two points. In v3.3.4 the checks are all non-enforcing, regardless of the results of the capabilities check. Without a Westmere of my own to test with I need to know how it really works so I had to make it permissive and risk the miner crashing. Yes you found a bug, mine by the way. I just assumed the AVX1 flag was what it says. It could result in a false positive CPU AES check only if the CPU has AES but not AVX. If the CPU does not have AES the false AVX reading has no effect. This bug may have a bearing on the Westmere problem but is no worse than the previous check that only read the AES bit of CPUID. I need to fully understand the architecture of Westmere as well as why the __AES__ macro seems to return different results on different CPUs with the same SW build. The problem with westmere CPUs is all about the __AES__ macro. I repeat it's all about the __AES__ macro on Westmere CPUs using the Westmere binary. At this point I don't really care what the flags say, I just want the miner to work on Westmere. Once the Westmere architecture is characterized and if the __AES__ discrepency is understood, only then will I think about revisiting the flags. I've already broken enough shit with my inability to test on Westmere. These guys need a working build. The key questions are: 1. Are there two versions of Westmere CPUs with differing support for AES and AVX but using the same compile arch. 2. Was the CMB Westmere build compiled natively on Westmere or crosscompiled using -marh=corei7. 3. What CPU capabilities does the corei7 compile arch support and is it compatible with all Westmere CPUs. I need those questions answered before trying anything else.
|
|
|
Joblo, can you make Windows version so I can test on Xeon E5649 (Westmere-EP, AES without AVX)
Cryptomining Blog has made binaries, follow the link in my sig for details. They have a westmere build. You should also try the sandybridge build. I'd like to see your results.
|
|
|
Yes, I'm getting all YESes with cpuminer.exe
Thanks.
|
|
|
Yes, for HODL. It is a Westmere-EP CPU, not Ivybridge. It is a lower power model and has less hashrate It only works with cpuminer.exe, the others all crash when I try them including the amd one.
Just rebooted the computer and it seems to work normally again, the cpu load is maxed out and the hashrate is high., will monitor it for a while just in case. Before rebooting the load was getting to minimum and maximum all the time with cpuminer.exe, but with wolfs miner it was maxing out at 100% and providing normal hashtrate.
Yours is the first Westmere that reports support for AES and AVX. Did you get all YESes? If so that's another data point in to the previous problems. If you got a YES for AES SW build it helps explain the problems some of the other Westmeres have had. Their CPUs say NO to AES then fail to detect a comtabible SW build. It fails for SSE2 because it's actually AES. With v3.3.4 the miner will no longer error out in a situation where it believes the CPU does not support AES but the SW does. It will try to run anyway. If the CPU Is in fact missing AES it will crash. This would also mean that some westmere's (like yours) support AES and others don't. Still a confusing situation. This may leave some westmere users without a useable binary for cpuminer-opt unless they compile their own. Waiting for feedback from them.
|
|
|
AMD ********** cpuminer-opt 3.3.4 *********** A CPU miner with multi algo support and optimized for CPUs with AES_NI and AVX extensions. 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... AMD Phenom(tm) II X4 940 Processor CPU arch supports AES-AVX...NO. CPU arch supports SSE2.....YES. YES. Starting mining without AES-AVX optimizations...
Something is missing there... Intel ********** cpuminer-opt 3.3.4 *********** A CPU miner with multi algo support and optimized for CPUs with AES_NI and AVX extensions. 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 arch supports AES-AVX...YES. SW built for AES-AVX........YES. Algo supports AES-AVX.......YES. Start mining with AES-AVX optimizations...
Nothing missing just something extra, two answers to the same question. I'm in no rush to fix it but thanks for pointing it out.
|
|
|
which is the best miner for windows so far wolf or cpuminer-opt???
They are essentially the same mining hodl. cpuminer-opt supports more algos.
|
|
|
I'm starting to prepare v3.3.4 for release. I will check for new posts before I publish As it stands there are two changes: - removed incompatible SW build check to fix problems for users with Westmere class CPUs. - optimized m7m AES +65%, SSE2 %59% Edit: This is what v3.3.4 should look like when compiler for and run on westmere. It is not actual program output because I don't have a westmere CPU. CPU arch supports AES-AVX...NO. CPU arch supports SSE2......YES. Starting mining without AES-AVX optimizations...
cpuminer-opt v3.3.4 released. https://drive.google.com/file/d/0B0lVSGQYLJIZVTFNSkZ0elRQZ2M/view?usp=sharing
|
|
|
I'm starting to prepare v3.3.4 for release. I will check for new posts before I publish As it stands there are two changes: - removed incompatible SW build check to fix problems for users with Westmere class CPUs. - optimized m7m AES +65%, SSE2 %59% Edit: This is what v3.3.4 should look like when compiler for and run on westmere. It is not actual program output because I don't have a westmere CPU. CPU arch supports AES-AVX...NO. CPU arch supports SSE2......YES. Starting mining without AES-AVX optimizations...
|
|
|
|