|
Yet another suggestion that might already be in the works...
I think I've mentioned before that the process for selecting a TD deposit address
is a bit clumsy. In summary: go to receive tab, click on address, click show, click copy address,
go to deposit tab, paste address, ...
It would be nice if we could select the address from the deposit tab. The button is there but
no previously used addresses are listed.
But today's suggestion is to display the maturing block number when a TD is created. You have
chosen to model TD based on time, but technically it is based on blocks. The familiarity
of the time model may be comforting to some but I'm a geek, I want the technical details.
My ideal model would be to have the choice of selecting the duration of a TD in number of blocks,
or the maturation block number, in addition to the current time based option. This would also
provide more granularity as multiple TDs can mature the same day but at different block numbers.
Currently, to find the maturation block number of a TD I have to find it in the random list after creating
it. That can get boring with lots of TDs.
|
|
|
|
taskkill -t -f /im ccminer*
I start all my launch .bat's with that to avoid crashing the cards or freezing the rig in case a ccminer instance lingers around.
Very good idea.....thx bathrobehero  -t, or /t, I'll have to give that a try. |
|
|
|
Promissing news for Windows users. I have successfully compiled and run cpuminer-opt using CygWin. I won't go into a lot of details but install CygWin base, the g++/autoconf toolchain and all the dependencies required by cpuminer-opt and compile like on linux from the cygwin terminal. Caveats: v3.1.9W is a repackage of v3.1.9 and is therefore missing some new algos, optimizations and other changes. It should be considered beta quality. Algos are hit and miss, x11 and quark work but cryptonight does not. Only AES_NI is supported in this release. Source code is modified from original v3.1.9 so don't try to use it on Linux. I expect some issues to arise especially for those unfamiliar with Linux and Cygwin. Please be patient and try to work things out for yourselves. Do some research. When you ask for help please provide complete information and what you have tried to solve the problem so I don't have to retrace your steps. I also welcome other more experienced users to help out answering the newbie questions. Here's the download link for v3.1.9W: https://drive.google.com/file/d/0B0lVSGQYLJIZLUU5Njd2bVRKMUE/view?usp=sharing |
|
|
|
that's comforting, at least we will not be left without hope, but it is yet to be seen if pascal will be a real game changer, or just vaporware
i would be happy with a 2x increase with the same comsuption, not the other way around...
I'm hoping cuda 8 will be better than 7.5 out of the box. Most of the 7.5 work has been to recover lost performance from 6.5. I'm also hoping pascal will perform well with existing code compiled with 7.5 or 6.5. Then the pacal optimizing can begin. |
|
|
|
Ok found the problem... The profiler did it  I run the program through an indirect call: valgrind --tool=callgrind ./cpuminer -a x11 --benchmark and then exported the profile data to KCachegrind to get the graph. I don't know how running it indirectly can do that, except if it emulates another cpuid. Normal run is ok, it detects Q8200. Thanks for the follow up, had me worried when your cpuid was shown correct. |
|
|
|
Edit2: I just realized there is a typo, it should be "-march=bdver1". Give it a try, it might be
faster for some algos.
This might be the best I can come up with. Now that you both have it figured out for your
own situation are the tips in README.md clear enough for other users? I've added another phrase
to the existing in italic.
Some users with AMD CPUs without AES_NI have reported problems compiling
with build.sh or "-march=native". Problems have included compile errors
and poor performance. These users are recommended to compile manually
specifying "-march=btver1bdver1" on the configure command line. If all else fails
"-march=core2" will provide the best compatibility but the lowest performance".
 As you can see, there is btver1 and bdver1. They are NOT the same and they refer to different CPUs. bdver1 uses AES, AVX and so on CPU instructions. Thanks, I also found this tidbit: AMD Opteron™ and AMD FX series processors with “Bulldozer” processor core (options: -march=bdver1 and -mtune=bdver1) and AMD processors with “Bobcat” core (options: -march=btver1 and -mtune=btver1). http://developer.amd.com/community/blog/2012/04/23/gcc-4-7-is-available-with-support-for-amd-opteron-6200-series-and-amd-fx-series-processors/ |
|
|
|
Images snipped. 3.1.18 is kind'a buggy in cpu detection. In a Q8200 it says: Checking CPU capatibility... Intel(R) Core(TM) i5 CPU 670 @ 3.47GHz CPU arch supports AES_NI...YES. SW built for AES_NI........NO. Algo supports AES_NI.......YES. CPU and algo support AES_NI, but SW build does not. Rebuild with "-march=native" for better performance. Starting mining without AES_NI optimizations... ...so naturally it thinks I have AES, even though the build is not for AES (-march=native / no AES in Intel quad core q8200). Anyway I did a profile run in x11 to check the slowdowns: A couple of them, with echo512 being the biggest culprit, dominate the process in terms of time wasted. It seems there is a very optimized AES version for it: https://bench.cr.yp.to/impl-hash/echo512.htmlhttps://bench.cr.yp.to/impl-hash/echo512.htmlhttps://github.com/floodyberry/supercop/tree/master/crypto_hash/echo512/aes/aes64Let me get this straight. You compiled with -march=native on a core2 that thinks it's a i5-670. The compile succeeded and the miner ran ok. That's pretty special. The CPU model and AES support comes directly from CPUID and has been reliable until now. Even the AMD guys haven't reported CPUID problems. Can you confirm CPUID is correct: cat /proc/cpuinfo |grep model It would be interesting to see what the compiler thought: gcc -march=native -Q --help=target | fgrep march Regarding echo512, yes you will get the slow version. Unfortunately I'm unaware of a SSE2 optimized version and the AES version is already used by cpuminer-opt on capable CPUs. I have yet to study your data in any detail but the following may put performance into perspective. Echo512 and groestl have AES optimizations for most algos. Cryptonight and hodl have their own unique AES optimizations. The rest of the x11 chain, including groestl but excluding echo, have SSE2 optimized versions. The algos in the longer X chains, as well as non-aes echo, are filled with slow SPH versions. |
|
|
|
cpuminer-opt v3.1.18 is one of the best in recent version history. Talking both Intel and AMD wise. Thank you for your hard work! Can't wait to see what branch 3.2 will offer.  The algo-gate work won't be user visible but will make it easier to add new algos. Thanks for your support and invaluable help in getting to the bottom of the compile issue. |
|
|
|
|
With things, hopefully, settling down after a period of rapid development
and many algo additions algo-gate has evolved significantly and delelopped
some mutations. Some functions developped multiple personalities or had names
that made no sense which deviated from the highly structured goals of the gate system.
Nevertheless it proved its worth when merging new algos by isolating all the algo
specific code. It also showed promise in gating other functions such as jsonrpc2.
I'll start working on v3.2 and do some genetic engineering on algo-gate so it doesn't
turn into a monster. I will also convert jsonrpc2 functions to use the gate and possibly
others
In the meantime only bug fixes and high priority features will be added to the 3.1
stream.
|
|
|
|
with -march=native o.k., with "btver1" negative
Checking CPU capatibility...
AMD Sempron(tm) 145 Processor
CPU arch supports AES_NI...NO.
CPU arch supports SSE2.....YES.
SW built for SSE2..........YES.
Starting mining without AES_NI optimizations...
[2016-04-23 22:06:15] Starting Stratum on stratum+tcp://hodl.suprnova.cc:4693
[2016-04-23 22:06:15] 1 miner threads started, using 'hodl' algorithm.
[2016-04-23 22:06:18] Stratum difficulty set to 1
[2016-04-23 22:07:07] hodl.suprnova.cc:4693 hodl block 43933
[2016-04-23 22:07:07] CPU #0: 373 H, 7.66 H/s
[2016-04-23 22:08:17] CPU #0: 529 H, 7.63 H/s
[2016-04-23 22:08:17] accepted: 1/1 (100%), 529 H, 7.63 H/s yes!
Edit @Giulini: what do you get from "gcc -march=native -Q --help=target"? Edit2: I just realized there is a typo, it should be "-march=bdver1". Give it a try, it might be
faster for some algos.This might be the best I can come up with. Now that you both have it figured out for your own situation are the tips in README.md clear enough for other users? I've added another phrase to the existing in italic. Some users with AMD CPUs without AES_NI have reported problems compiling with build.sh or "-march=native". Problems have included compile errors and poor performance. These users are recommended to compile manually specifying "-march= btver1bdver1" on the configure command line. If all else fails
"-march=core2" will provide the best compatibility but the lowest performance". |
|
|
|
Agreed. In his efforts to advertise higher hashrates for certain algos on certain cards he has detsabilized
other algos and other cards.
I run my farm on my modded and optimized kernals and I make a profit. If you get crashes it might be because your powersupply is not good enough. Higher intensities can increase the power usage with 5%. Wrong. You've optimized your kernels for your farm and tell your paying customers to expect the same results with different configs. |
|
|
|
p45 - r7 on riser 1xpci e works
p45 - r9 nano on riser 1x pcie doesnt work
z97 anniversary- r7 on 1x doesnt work
z97- r9 nano on 1x doesnt work
z97- r9 nano 16x works
Do you have more than one riser? One of them is bad. - the riser on the P45 with the 240 works - the riser on the P45 with the nano doesn't work - the riser on the Z97 doesn't work with either card - the nano works on the Z97 works without a riser |
|
|
|
EDIT: Sp should list every algos default intensities.
Agreed. In his efforts to advertise higher hashrates for certain algos on certain cards he has detsabilized other algos and other cards. |
|
|
|
mobo is z97 anniversary , i have tried on old p45 to jump it from 16x to 1x and it works fine with R7 240 but again R9 nano p45 doesnt see , and z97 doesnt see nothin (r9 nano and r7 240 )
The nano is new so it might need newer drivers. If the 240 doesn't work in the x16 slot without the riser it might be a bad mobo. If it does work it's probably a bad riser. |
|
|
|
why motherboard doesnt see my card on pcie 1X ? used standard ribbon raiser
Make sure you use a powered riser and check to see if you need to short out two pins in the x1 slot to allow high power. Google it. |
|
|
|
Yep, -march=native still fails.
Also ./build.sh produces slightly slower binary for me on Intel and AMD (with changed -march=), maybe too many CFLAGS?
Thanks. -march=native chooses a lower arch than your CPU is capable of. You can confirm this with this command gcc -march=native -Q --help=target You will likely see amdfam10 but will get better performance with btver1. |
|
|
|
When using the git fork with this command line ./autogen.sh && CXXFLAGS="-std=gnu++11" ./configure CFLAGS="-O3 -march=btver1" --with-curl --with-crypto && make I got a successful compile and working binary on AMD ********** cpuminer-multi 1.2-dev ***********
A CPU miner with multi algo support and optimized for CPUs
with AES_NI extension.
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 of AMD Phenom(tm) II X4 940 Processor...
CPU arch supports AES_NI... NO.
CPU arch supports SSE2..... YES.
SW built with AES_NI....... NO.
SW built with SSE2......... YES.
Algo supports AES_NI....... YES.
Starting mining without AES_NI optimisations... Thanks. I presume -march=native still fails. I will soon release 3.1.18 with the following: - Implement CPU check logic from hmage - remove check for inferior SW build on SSE2 CPU - add check for superior build - Suppress messages not used in decision making - document AMD workaround - fix set_data_size bug Edit: here is a draft of the test I intend to add to the build instructions: Some users with AMD CPUs without AES_NI have reported problems compiling with build.sh or "-march=native". Problems have included compile errors and poor performance. These users are recommended to compile manually specifying "-march=btver1" on the configure command line. |
|
|
|
@hmage
I see the difference in your logic in the sse2 check. I checked for an inferiour build missing sse2 (since removed in 3.1.17)
and you check for a superiour build including aes_ni. In practical terms the superiour check seems more important as that
scenario could occur if cpuminer-opt was cross compiled on a CPU with aes-ni. On the other hand cross compiling on a
CPU without sse2 would have failed.
Removing the check for inferiour build, as done in 3.1.17 and your fork, is harmless and will become permanent.
I will add a check for superiour build because that is a possible scenario. Both pending test results from users with
real AMD CPUs with sse2 but without aes-ni.
So if I read correctly - we should use github fork of hmage, which is with fixed CPU, OS and algo checks. If everything is OK on AMD CPUs it will become the main branch of cpuminer-opt? It's up to hmage whether he wants to maintain his fork. I intend to implement the fix on mine once it has been properly tested. Even with the fix I believe AMD will require a workaround for -march |
|
|
|
|
@hmage
I see the difference in your logic in the sse2 check. I checked for an inferiour build missing sse2 (since removed in 3.1.17)
and you check for a superiour build including aes_ni. In practical terms the superiour check seems more important as that
scenario could occur if cpuminer-opt was cross compiled on a CPU with aes-ni. On the other hand cross compiling on a
CPU without sse2 would have failed.
Removing the check for inferiour build, as done in 3.1.17 and your fork, is harmless and will become permanent.
I will add a check for superiour build because that is a possible scenario. Both pending test results from users with
real AMD CPUs with sse2 but without aes-ni.
|
|
|
|
|
Show Posts
