[ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 131.

NiceHashSupport

hero member

Activity: 588

Merit: 501

Quote from: scryptr on September 27, 2016, 06:21:58 PM

Quote from: NiceHashSupport on September 27, 2016, 05:15:01 PM

Rather than march, try with -msse2

And old cryptonight miners will not work correctly on NiceHash - we had to add small protocol adjustment to be able to redistribute hashing power because cryptonight algo does not have extranonce. Besides that, these miners also send additional newlines (bug), which our implementation will not tolerate and would kill con.

THANKS FOR THE REPLY--

I was not able to compile the NiceHash CryptoNight CCminer, either. I run Lubuntu 14.04, and am able to compile tsiv's original CCminer with no problem. Your code is based on his miner, but cloning git from the NiceHash repository, then compiling with the same steps used for tsiv's miner only results in errors.

I'd appreciate some help in compilation, or Linux binaries available for download. --scryptr

EDIT: I tried the "-msse2" switch, and no "cpuminer" executable was produced. The "march=core2" flag works, but the result is a miner that produces an "illegal instruction" and dumps core. If there is an appropriate command flag for Athlon X II CPUs, please let me know. Thanks... -scryptr

We use this build script on mingw for building for SSE2: https://github.com/nicehash/cpuminer-opt/blob/master/mingw64sse2.sh

There are no issues and executable is built.

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: scryptr on September 27, 2016, 03:51:09 PM

Quote from: joblo on September 25, 2016, 02:57:02 PM

Quote from: scryptr on September 25, 2016, 02:21:24 PM

Quote from: joblo on September 25, 2016, 12:33:29 PM

What are the differences between the rigs that compile and those that don't? OS version, gcc version?

Edit: I found this, their solution was to add the m4 directory. Let me know if it works.

https://github.com/dirkvdb/ffmpegthumbnailer/issues/37

THAT TRICK DID NOT WORK--

I tried it earlier. My Sempron rigs likely won't benefit from the optimizations, thay are doing fine on Lyra2re. What bothers me is that tpruvot's CPUMiner-Multi is not working on CryptoNight at NiceHash. --scryptr

Could be more than one problem, AMD often doesn't compile with "-march=native", give it a try with "-march=core2". There is some discussion
about this with an AMD user several pages back in this thread. He has a good handle on the problems and I've let him take the lead as I don't have
any AMD CPUs.

The issue with cryptonight at Nicehash is they threw in a twist to the protocol that requires a miner update. TPruvot has been
quite busy with ccminer and yiimp so I don't expect a quick fix to cpuminer-multi, especially since those other projects are producing revenue.

THE COMPILATION WITH "-MARCH=CORE2"--

The compilation worked, and generated an executable cpuminer. However, the miner errors out with "illegal instruction" when it begins to mine. It will print out its version, and "./cpuminer -h > help.txt" generates a readable help file, but it won't mine. The cpuminer recognizes my CPU as an Athlon X II, links to the pool, and then errors out. What other options do I have for the "-march=" string?

I am simply using the "build.sh" file. A Sempron 145, unlocked to an Athlon X II, is not a Core2 Intel chip. Is there a specification for the older Athlon chips? Or, anything else in the "build.sh" that I should alter?

Thanks! --scryptr

I see no reason for an illegal instruction if you compiled for core2. Please post the miner console session.

scryptr

legendary

Activity: 1797

Merit: 1028

Quote from: NiceHashSupport on September 27, 2016, 05:15:01 PM

Rather than march, try with -msse2

And old cryptonight miners will not work correctly on NiceHash - we had to add small protocol adjustment to be able to redistribute hashing power because cryptonight algo does not have extranonce. Besides that, these miners also send additional newlines (bug), which our implementation will not tolerate and would kill con.

THANKS FOR THE REPLY--

I was not able to compile the NiceHash CryptoNight CCminer, either. I run Lubuntu 14.04, and am able to compile tsiv's original CCminer with no problem. Your code is based on his miner, but cloning git from the NiceHash repository, then compiling with the same steps used for tsiv's miner only results in errors.

I'd appreciate some help in compilation, or Linux binaries available for download. --scryptr

EDIT: I tried the "-msse2" switch, and no "cpuminer" executable was produced. The "march=core2" flag works, but the result is a miner that produces an "illegal instruction" and dumps core. If there is an appropriate command flag for Athlon X II CPUs, please let me know. Thanks... -scryptr

NiceHashSupport

hero member

Activity: 588

Merit: 501

Rather than march, try with -msse2

And old cryptonight miners will not work correctly on NiceHash - we had to add small protocol adjustment to be able to redistribute hashing power because cryptonight algo does not have extranonce. Besides that, these miners also send additional newlines (bug), which our implementation will not tolerate and would kill con.

scryptr

legendary

Activity: 1797

Merit: 1028

Quote from: joblo on September 25, 2016, 02:57:02 PM

Quote from: scryptr on September 25, 2016, 02:21:24 PM

Quote from: joblo on September 25, 2016, 12:33:29 PM

What are the differences between the rigs that compile and those that don't? OS version, gcc version?

Edit: I found this, their solution was to add the m4 directory. Let me know if it works.

https://github.com/dirkvdb/ffmpegthumbnailer/issues/37

THAT TRICK DID NOT WORK--

I tried it earlier. My Sempron rigs likely won't benefit from the optimizations, thay are doing fine on Lyra2re. What bothers me is that tpruvot's CPUMiner-Multi is not working on CryptoNight at NiceHash. --scryptr

Could be more than one problem, AMD often doesn't compile with "-march=native", give it a try with "-march=core2". There is some discussion
about this with an AMD user several pages back in this thread. He has a good handle on the problems and I've let him take the lead as I don't have
any AMD CPUs.

The issue with cryptonight at Nicehash is they threw in a twist to the protocol that requires a miner update. TPruvot has been
quite busy with ccminer and yiimp so I don't expect a quick fix to cpuminer-multi, especially since those other projects are producing revenue.

THE COMPILATION WITH "-MARCH=CORE2"--

The compilation worked, and generated an executable cpuminer. However, the miner errors out with "illegal instruction" when it begins to mine. It will print out its version, and "./cpuminer -h > help.txt" generates a readable help file, but it won't mine. The cpuminer recognizes my CPU as an Athlon X II, links to the pool, and then errors out. What other options do I have for the "-march=" string?

I am simply using the "build.sh" file. A Sempron 145, unlocked to an Athlon X II, is not a Core2 Intel chip. Is there a specification for the older Athlon chips? Or, anything else in the "build.sh" that I should alter?

Thanks! --scryptr

felixbrucker

hero member

Activity: 700

Merit: 500

regarding windows compiles:

i have successfully gotten a build environment setup using the steps provided by nicehash, credit to them.

personal notes/walkthrough:

1) get the first three GNUStep packages noted and install in this order: msys,core,devel. The other three are not needed (just GUI stuff).

2) install win-builds as noted, for me the installer always failed to download the packages/info so i got it working with the steps mentioned here, that being:

get the portable windows wget package
run:

Code:

wget -r --no-parent --no-host-directories http://win-builds.org/1.5.0/packages/

use C:\winbuilddir\1.5.0 in the win-builds installer as http mirror

and select plain C:\GNUStep as install dir (not C:\GNUStep\msys or something as noted in the nicehash guide), press "OK", and "Process" on the next Page when the Packages show up.

3) after the win-builds install is finished just execute C:\GNUStep\msys\1.0\msys.bat, set the PATH to include "/c/GNUstep/msys/1.0/opt/windows_64/bin/" by either doing

Code:

PATH="/c/GNUstep/msys/1.0/opt/windows_64/bin/:$PATH"

in the cmd window (it does not support copy/paste) or creating a file with the following content:

Code:

PATH="/c/GNUstep/msys/1.0/opt/windows_64/bin/:$PATH"
bash

and saving it as setPath.sh in C:\GNUstep\msys\1.0\home\USERNAME so you can easily execute it each time you want to build cpuminer-opt

Note: afaik it should also work by setting this in the windows system variables (permanently) so you dont need to enter/execute it each time, not tested though

4) now just change to your cpuminer-opt src and run winbuild.sh

AngryDwarf

sr. member

Activity: 476

Merit: 501

I think you can get git to create an empty directory by putting an empty .gitignore file in it.

joblo

legendary

Activity: 1470

Merit: 1114

I just pushed an update to git. This is not a full release. There are no algo changes so no binaries will be built.

https://github.com/JayDDee/cpuminer-opt

Changes in v3.4.8-dev:

- deleted some trash files
- deleted all .dirstamp files, I don't know where they came from but they seems to have stayed away.
- added non-empty m4 directory
- fixed API output of diff for cryptonight
- removed cpuminer-multi artifacts

Let me know of any problems

joblo

legendary

Activity: 1470

Merit: 1114

It seems git has thrown me another curveball.

Some may remember discussion about the configure file and that it should be automatically generated
using configure.ac and that in my case it was static. I only editted it to change the package version each release.

That has now changed. Git did not upload configure as instructed by .gitignore. No problem as long as it compiles
and it does. configure got generated and everything is ok, with the git clone.

However, deleting configure in my original code will break the compile.

It appears there is something in my code that requires configure to be present but when the code was uploaded
to git that requirement was removed so configure could be deleted.

Does anyone know what that mechanism is so I can remove configure from the clean code?

Edit: Do not download from git until this message is updated. I just pushed an update that broke the compile.
On the bright side I think it answers my questions above.

See next post.

felixbrucker

hero member

Activity: 700

Merit: 500

Quote from: joblo on September 26, 2016, 11:10:32 AM

Quote from: felixbrucker on September 26, 2016, 10:49:13 AM

Quote from: joblo on September 26, 2016, 10:39:50 AM

Maybe I did something wrong but all I wanted to do was upload my entire project to git.
I followed this procedure: https://help.github.com/articles/adding-a-file-to-a-repository-from-the-command-line/

I created a test directory and cloned the initial repo which only contained a README file.
Replaced README with cpuminer-opt files.
Did add, commit, push as per procedure.

I did nothig else.

There were no .dirstamp files in cpuminer-opt, but there was .gitignore and .gitattributes.
gitignore had a line "./.dirstamp" in it.

cpuminer-opt had an empty m4 directory.

After uploading, .dirstamp files had been magically created and the m4 directory had disappreared.
But .dirstamp is in .gitignore and m4 is not. This makes no sense to me.

i dont know about the dirstamp files, but empty folders are not added to git, maybe add an invisible file (with a dot as first char) into the dir and it should work

Like a .dirstamp file? Grin

I will actually try that but I'm not going git rm all the .dirstamps. When I do the next upload I will delete the entire local tree and replace it
with a fresh copy. The fresh copy won't have any .dirstamp files and hopefully git will straighten itself out. If not I will just ignore .dirstamp.

this should work, though my git created from your tarballs does not contain any dirstamps, they only seem to get created on compile (search in the git repo for dirstamp and you will find it in the Makefile.in)

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: felixbrucker on September 26, 2016, 10:49:13 AM

Quote from: joblo on September 26, 2016, 10:39:50 AM

Maybe I did something wrong but all I wanted to do was upload my entire project to git.
I followed this procedure: https://help.github.com/articles/adding-a-file-to-a-repository-from-the-command-line/

I created a test directory and cloned the initial repo which only contained a README file.
Replaced README with cpuminer-opt files.
Did add, commit, push as per procedure.

I did nothig else.

There were no .dirstamp files in cpuminer-opt, but there was .gitignore and .gitattributes.
gitignore had a line "./.dirstamp" in it.

cpuminer-opt had an empty m4 directory.

After uploading, .dirstamp files had been magically created and the m4 directory had disappreared.
But .dirstamp is in .gitignore and m4 is not. This makes no sense to me.

i dont know about the dirstamp files, but empty folders are not added to git, maybe add an invisible file (with a dot as first char) into the dir and it should work

Like a .dirstamp file? Grin

I will actually try that but I'm not going git rm all the .dirstamps. When I do the next upload I will delete the entire local tree and replace it
with a fresh copy. The fresh copy won't have any .dirstamp files and hopefully git will straighten itself out. If not I will just ignore .dirstamp.

felixbrucker

hero member

Activity: 700

Merit: 500

Quote from: joblo on September 26, 2016, 10:39:50 AM

Maybe I did something wrong but all I wanted to do was upload my entire project to git.
I followed this procedure: https://help.github.com/articles/adding-a-file-to-a-repository-from-the-command-line/

I created a test directory and cloned the initial repo which only contained a README file.
Replaced README with cpuminer-opt files.
Did add, commit, push as per procedure.

I did nothig else.

There were no .dirstamp files in cpuminer-opt, but there was .gitignore and .gitattributes.
gitignore had a line "./.dirstamp" in it.

cpuminer-opt had an empty m4 directory.

After uploading, .dirstamp files had been magically created and the m4 directory had disappreared.
But .dirstamp is in .gitignore and m4 is not. This makes no sense to me.

i dont know about the dirstamp files, but empty folders are not added to git, maybe add an invisible file (with a dot as first char) into the dir and it should work

joblo

legendary

Activity: 1470

Merit: 1114

Maybe I did something wrong but all I wanted to do was upload my entire project to git.
I followed this procedure: https://help.github.com/articles/adding-a-file-to-a-repository-from-the-command-line/

I created a test directory and cloned the initial repo which only contained a README file.
Replaced README with cpuminer-opt files.
Did add, commit, push as per procedure.

I did nothig else.

There were no .dirstamp files in cpuminer-opt, but there was .gitignore and .gitattributes.
gitignore had a line "./.dirstamp" in it.

cpuminer-opt had an empty m4 directory.

After uploading, .dirstamp files had been magically created and the m4 directory had disappreared.
But .dirstamp is in .gitignore and m4 is not. This makes no sense to me.

pallas

legendary

Activity: 2716

Merit: 1094

Black Belt Developer

Quote from: joblo on September 26, 2016, 08:50:27 AM

Quote from: Epsylon3 on September 25, 2016, 10:43:14 PM

once tracked, they are in git... gitignore just ignore the junk when you do git add

so you need to git rm & commit to remove that from git.

m4/ we dont care, we just "need" an empty folder (os specific stuff)

Let me get this straight. Git created and started tracking files that it knows shouldn't be tracked but I'm supposed to clean
up the mess.

It also deleted the m4 directory which is needed.

If I can't upload a snapshot and trust that GIT won't fuck things up I won't use it.

you can even screw the currect cpus and build your own :-D

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: Epsylon3 on September 25, 2016, 10:43:14 PM

once tracked, they are in git... gitignore just ignore the junk when you do git add

so you need to git rm & commit to remove that from git.

m4/ we dont care, we just "need" an empty folder (os specific stuff)

Let me get this straight. Git created and started tracking files that it knows shouldn't be tracked but I'm supposed to clean
up the mess.

It also deleted the m4 directory which is needed.

If I can't upload a snapshot and trust that GIT won't fuck things up I won't use it.

Epsylon3

legendary

Activity: 1484

Merit: 1082

ccminer/cpuminer developer

once tracked, they are in git... gitignore just ignore the junk when you do git add

so you need to git rm & commit to remove that from git.

m4/ we dont care, we just "need" an empty folder (os specific stuff)

joblo

legendary

Activity: 1470

Merit: 1114

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: scryptr on September 25, 2016, 02:21:24 PM

Quote from: joblo on September 25, 2016, 12:33:29 PM

What are the differences between the rigs that compile and those that don't? OS version, gcc version?

Edit: I found this, their solution was to add the m4 directory. Let me know if it works.

https://github.com/dirkvdb/ffmpegthumbnailer/issues/37

THAT TRICK DID NOT WORK--

I tried it earlier. My Sempron rigs likely won't benefit from the optimizations, thay are doing fine on Lyra2re. What bothers me is that tpruvot's CPUMiner-Multi is not working on CryptoNight at NiceHash. --scryptr

Could be more than one problem, AMD often doesn't compile with "-march=native", give it a try with "-march=core2". There is some discussion
about this with an AMD user several pages back in this thread. He has a good handle on the problems and I've let him take the lead as I don't have
any AMD CPUs.

The issue with cryptonight at Nicehash is they threw in a twist to the protocol that requires a miner update. TPruvot has been
quite busy with ccminer and yiimp so I don't expect a quick fix to cpuminer-multi, especially since those other projects are producing revenue.

scryptr

legendary

Activity: 1797

Merit: 1028

Quote from: joblo on September 25, 2016, 12:33:29 PM

What are the differences between the rigs that compile and those that don't? OS version, gcc version?

Edit: I found this, their solution was to add the m4 directory. Let me know if it works.

https://github.com/dirkvdb/ffmpegthumbnailer/issues/37

THAT TRICK DID NOT WORK--

I tried it earlier. My Sempron rigs likely won't benefit from the optimizations, thay are doing fine on Lyra2re. What bothers me is that tpruvot's CPUMiner-Multi is not working on CryptoNight at NiceHash. --scryptr

joblo

legendary

Activity: 1470

Merit: 1114

Quote from: scryptr on September 25, 2016, 12:28:00 PM

Quote from: joblo on September 25, 2016, 11:43:38 AM

There is an m4 directory in the cpuminer-opt tarball but it got dropped from git. It is empty and unchanged for months. I can compile without it.
But it seems you can't. You could try adding it.

I could try uploading it to git again but I have no reason to expect different results. Maybe someone who understands autoconf better has
a suggestion.

Thanks. I did some web research, and tried a few suggestions, and it made no difference. Right now, all of my HASWELL CPU rigs have successfully compiled CPUMiner-OPT. The two rigs that won't compile your miner have Sempron 145 CPUs, and do not support AES. They are running CPUMiner-Multi, and mining Lyra2re. The HASWELL rigs are mining CryptoNight with yoiur software. The rigs with AES support are running the optimised CPU miner, the rigs without are doing fine on Lyra2re.

Thanks for answering my questions. I do wonder why tpruvot's CPUMiner-Multi is having difficulty with the NiceHash CryptoNight pool. Perhaps I should post in his thread. --scryptr

What are the differences between the rigs that compile and those that don't? OS version, gcc version?

Edit: I found this, their solution was to add the m4 directory. Let me know if it works.

https://github.com/dirkvdb/ffmpegthumbnailer/issues/37

Topic: [ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 131. (Read 444067 times)