NICE! I guess it's important to use the right version, or?? cpuminer-sandybridge-ivybridge.exe cpuminer-haswell-broadwell.exe cpuminer-amd.exe cpuminer.exe Yes it is. Or?? it does not work.  ...or works slower. Haswell is for core i 4000 series, sandy for Core i 2000. If your not sure give them all a try and use the one that works best. If the algo is not AES_NI optimized you won't notice much difference. |
|
|
|
I have observed for several releases that on occasion cpuminer-opt fails to start up properly mining hodl and produces only low difficulty shares. Also when mining there is the occasional low difficulty share at a rate of 1 or 2%. This only seems to occur on certain systems. For example it occurs on my i7-6700K Linux, but not on my i7-4790K windows or i5-2400 linux. Cryptomining blog has also noted this problem. If you get low difficulty shares on startup when mining hodl hit Ctrl-C and try again. I would also appreciate if users could report whether they have this problem and which CPU and OS they use. Please respond in my thread. https://bitcointalk.org/index.php?topic=1326803.msg15037087#msg15037087 |
|
|
|
|
I have observed for several releases that on occasion cpuminer-opt fails to start up properly
mining hodl and produces only low difficulty shares. Also when mining there is the occasional
low difficulty share at a rate of 1 or 2%. This only seems to occur on certain systems.
For example it occurs on my i7-6700K Linux, but not on my i7-4790K windows or i5-2400 linux.
Cryptomining blog has also noted this problem.
If you get low difficulty shares on startup when mining hodl hit Ctrl-C and try again. I would also
appreciate if users could report whether they have this problem and which CPU and OS they use.
|
|
|
|
cpuminer-opt now supports Revolver coin with x11evo algo. x11evo has been optimized 109% on CPUs with AES_NI and 42% for CPUs with only SSE2. Windows support was also recently added to cpuminer-opt using mingw_64 and msys. See README.md for instructions on how to install mingw_w64 and msys. No precompile Windows binaries are provided, must compile from source. There is a small undocumented change in the build procedure for this release. A new option has been added to the configure command. This procedure works for both Linux and Windows. ./autogen.sh
./configure CFLAGS="-O3 -march=native" CXXFLAGS="$CFLAGS -std=gnu++11" --with-curl
make
Download it here or visit the link in my sig for more details. https://drive.google.com/file/d/0B0lVSGQYLJIZWlJaOWtPZ2tESmM/view?usp=sharing |
|
|
|
Cpuminer-opt v3.3.1 released with support for new algo x11evo (Revolver coin). The algo has been optimized +109% for AES_NI and 42% for SSE2. https://drive.google.com/file/d/0B0lVSGQYLJIZWlJaOWtPZ2tESmM/view?usp=sharingThere is a small change in build procedure, a new option to configure not documented in README.md or supported in build,sh. ./autogen.sh
./configure CFLAGS="-O3 -march=native" CXXFLAGS="$CFLAGS -std=gnu++11" --with-curl
make
Full Windows support is provided except for hodl algo on CPUs without AES_NI. See README.md for instructions to install mingw_w64 and msys for compiling on Windows. Compiling with Visual Studio is not supported and no precompiled Windows binaries are provided. Edit: Cryptomining Blog has built Windows binaries for v3.3. Will give it a try. http://cryptomining-blog.com/7900-windows-binaries-for-the-cpuminer-opt-3-3-cpu-miner/Edit2: The CMB package comes with a bunch of DLLs needed to run so it should work for most users. It runs fine on my i7-4790K Windows 8.1. |
|
|
|
@joblo I'm getting this error while trying to solo-mine hodlcoin. The launch parameters (below), works with the original hodlminer and hodlminer-wolf versions. ./cpuminer -a hodl -o http://192.168.1.x:xxxx -u xxxx -p xxxx -t 4 --coinbase-addr=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --no-getwork -q  It looks like you are trying to solo mine the wallet. I have not been able to test this and didn't know if it worked. Thanks for being my tester. I'll look into it to see what I can do. Edit: can you provide the output without -q? |
|
|
|
[2016-05-31 16:48:25] x11evo block 4752, diff 11.644
[2016-05-31 16:48:33] x11evo block 4753, diff 15.657
[2016-05-31 16:49:19] GPU #0: EVGA GTX 970, 7656.44 kH/s
[2016-05-31 16:49:19] accepted: 1299/1299 (diff 0.106), 14.98 MH/s yes!
[2016-05-31 16:49:21] GPU #1: ASUS GTX 970, 7320.42 kH/s
also made yiimp support ^^ all since 5h this morning i use autoreconf alone when i add a file in Makefile.am, i rarely use -fi Pretty good, that's .85 x11, I get .78 x11 on cpuminer-opt. |
|
|
|
Thanks, you beat me to it. Got it working last night on Linux. trying to get it working on Win, might be similar issue to non AES hodl on Win and I have an idea how to fix it, otherwise I would have released x11evo last night. The implementation took: 1 line added to Makefile.am 3 lines added to miner.h to define algo enum, name and help. 1 line added to algo-gate-api.c to call register function 1 line in x11evo.c to #include algo-gate-api.h 4 lines to define algo register function 1 line changed to fix scanhash parameter list Total 11 lines. This was a particularly easy implementation because it uses the defaults for everything. The I added the optimizations and doubled the speed. Is autoreconf the solution to the issue with configure that was being discussed, how to migrate to a new compiler or both? |
|
|
|
You shouldn't edit configure, but the files used to generate it: configure.in for example.
Funny thing is the only thing I do differently than cpuminer-multi is, presumably, manually edit configure but noticed no change in the building after doing so. I edit once every release with many make distclean before and after the edit. My changes never get tossed so there must be something preventing make distclean from deleting configure and autogen.sh from overwriting it, and it's nothing I've done. I don't disagree philosophically with anything that has been said about it, but it's not my problem, I'm just doing what the previous guy did. Since I didn't break it I can't fix it in the sense of putting it back the way I found it. Also configure.in doesn't exist, configure.ac hasn't changed since October. I'd be shooting in the dark trying to figure it out. if it didn't work immediately I'd be lost. Make distclean will not touch configure, because configure generates makefiles. https://www.gnu.org/software/automake/manual/html_node/Standard-Targets.htmlmake clean
Erase from the build tree the files built by make all.
make distclean
Additionally erase anything ./configure created.
Generating configure is one level of abstraction higher. PS: I think the reason why editing configure gave you false impression that this is the right thing to do is because configure.ac you inherited from another fork uses AM_MAINTAINER_MODE. Which disables such checks. https://www.gnu.org/software/automake/manual/html_node/maintainer_002dmode.htmlSeveral years ago François Pinard pointed out several arguments against this AM_MAINTAINER_MODE macro. Most of them relate to insecurity. By removing dependencies you get non-dependable builds: changes to sources files can have no effect on generated files and this can be very confusing when unnoticed. He adds that security shouldn’t be reserved to maintainers (what --enable-maintainer-mode suggests), on the contrary. If one user has to modify a Makefile.am, then either Makefile.in should be updated or a warning should be output (this is what Automake uses missing for) but the last thing you want is that nothing happens and the user doesn’t notice it (this is what happens when rebuild rules are disabled by AM_MAINTAINER_MODE).
Jim Meyering, the inventor of the AM_MAINTAINER_MODE macro was swayed by François’s arguments, and got rid of AM_MAINTAINER_MODE in all of his packages. emphasis mine. Counter intuitively, the presence of that macro disables maintainer mode, and if you run ./configure --enable-maintainer-mode, then edit configure.ac (just change the version number from 1.2-dev), then run make, such edit will be detected and autoconf will be used to re-generate configure from its source file (configure.ac), effectively deleting all changes you did to that file because you were running in non-maintainer mode. It can be frustrating at times when you bring up issues I inherited, know nothing about, and aren't causing me any problems at the moment. But other than that you know your stuff and I could learn a lot from you, but preferably at a time of my choosing. |
|
|
|
You shouldn't edit configure, but the files used to generate it: configure.in for example.
Funny thing is the only thing I do differently than cpuminer-multi is, presumably, manually edit configure but noticed no change in the building after doing so. I edit once every release with many make distclean before and after the edit. My changes never get tossed so there must be something preventing make distclean from deleting configure and autogen.sh from overwriting it, and it's nothing I've done. I don't disagree philosophically with anything that has been said about it, but it's not my problem, I'm just doing what the previous guy did. Since I didn't break it I can't fix it in the sense of putting it back the way I found it. Also configure.in doesn't exist, configure.ac hasn't changed since October. I'd be shooting in the dark trying to figure it out. if it didn't work immediately I'd be lost. |
|
|
|
That's not how it currently works in cpuminer-opt. configure is persistent and is not modified by anyone or anything
but me.
Write a warning about that somewhere, because this is not how the rest of the world does it. https://wiki.debian.org/AutoreconfDebian (and, by extension, Ubuntu) deletes configure and regenerates it from configure.ac on almost every single package that is in the repository. Your copy of configure also might be too old for newer distros like Arch or Gentoo, and will end up tripping on errors. A simple run of "autoreconf -f -i -v" fixes many of those problems by regenerating that configure script. Keeping nonperishable source-class information in that place is not sane idea. This is equivalent of editing *.o files after compilation from *.c. PS: if you insist on keeping configure, then remove it from .gitignore and delete the source file -- configure.ac. Noted, something must be done before I upload to git. |
|
|
|
Uh. no, configure is part of the clean package, I edit it every version with the new version number.
No, configure is not part of clean package, it is an auto-generated script. Here's a way to prove that: * Delete configure and then run build.sh -- magically it somehow reappears. * Where from? From configure.ac! If you want your changes in configure to persist, change the source of that file -- configure.ac For more info how configure works, read the docs -- https://www.gnu.org/software/autoconf/manual/autoconf.pdfThat's not how it currently works in cpuminer-opt. configure is persistent and is not modified by anyone or anything but me. Whether it is the correct way or not is irrelevent, it works And once again, you are making the claim, you prove it. I'm not saying you are wrong in that using configure.ac is the correct way of doing things but there are obviously others and you have, not only, failed to show any evidence the current cpuminer-opt implementation is wrong, you have failed to accept that it even exists. I don't know about autoconf to debate the virtues of either method but I'm not about to implement a disruptive change for no apparent benefit. Sound familiar? Thanks for the link, I'll add it to the long list of reading material. |
|
|
|
|
After this long I think an update is appropriate and hopefully an estimate of return to service.
|
|
|
|
Edit2: I downloaded your code but there are files missing, most noticeably configure. What's up with that?
Regarding files missing, I cloned hmage's source from github so I have the same files that he put up there. configure is generated by autoconf, which is called by autogen.sh, which is called by build.sh. There's no point in keeping build artifacts. Same goes for Makefile, Makefile.in, aclocal.m4, autom4te.cache, compile, config.guess, config.log, config.status, config.sub, cpuminer-config.h, cpuminer-config.h.in, depcomp, install-sh, missing and stamp-h1 -- they are generated during complete build process and it's general etiquiette to not commit those (since their output will vary from machine to machine). PS: they're even mentioned in joblo's .gitignore Uh. no, configure is part of the clean package, I edit it every version with the new version number. Thanks for the tip about _WIN32, I'll add it back in the next release. |
|
|
|
Will be doing a reboot of some servers shortly to apply some tuning improvements and system patches.
Yes I see stratum is down for improvements. waiting for reboot to come back up. It's taking abnormally long unfortunately. bleh of course, it shows an error status from the hosting console. Hang tight. Take you time .. good things take time.  I hate reboots. Tix logged with provider to investigate. I'm a little bummed it's still down but you picked a good time, mining revenue is low so I'm not missing much. Keep up the good work. |
|
|
|
interesting algo ...
any gpu miner around? ... namely for nvidia ( ccminer ) ...
#crysx
Not that anyone can confirm, possibly a canine is working on an AMD version, but no cuda AFAIK. There's already an AMD one out (not from me) - I'm pretty sure. And I thought mine was the fastest. well - if there is anything that can be included in ccminer kernels - then this algo should be one ... i wonder if tpruvot / epsylon3 is willing to add it? ... #crysx I think it's fairly easy to implement by a cuda dev, all the pieces are there it's just a matter of aranging them in the right order, just like the CPU implementation. The issue is the size of the algo. As I believe Wolf0 said "it's fucking huge". I'm not sure how well a cuda implementation would perform. |
|
|
|
interesting algo ...
any gpu miner around? ... namely for nvidia ( ccminer ) ...
#crysx
Not that anyone can confirm, possibly a canine is working on an AMD version, but no cuda AFAIK. There's already an AMD one out (not from me) - I'm pretty sure. And I thought mine was the fastest. |
|
|
|
interesting algo ...
any gpu miner around? ... namely for nvidia ( ccminer ) ...
#crysx
Not that anyone can confirm, possibly a canine is working on an AMD version, but no cuda AFAIK. |
|
|
|
|
Show Posts
