Try swapping the suspect card with card 0 (in the x16 slot I presume) to see if the probkem moves.
Swapping cards... but gpu0 is not the 16x slot. I think you're going in the wrong direction. You installed a new card and your system destabilized. You know the system was stable before but you don't know if the card is defective. That is your first objective. You need to isolate the problem. Swap the suspect card with whatever card just to see if the problem follows it. Try removing the suspect card to get back to a stable system. Try removing all but the suspect card. Look for a pattern. If the card proves ok then you can look at system problems, starting with power. Do you have enough power? Do you have too many risers on the same rail? There appears to be nothing in the software that has changed that could have caused it. |
|
|
|
Sorry sp I have no place to go but here to get help on my card 970 gtx gigabyte G1 not working. Ok I was mining ok on my rig then I got a 2nd 970 G1 and ever since my rig won't work constantly. Drivers crash.. ccminer crashes... ect. I tried replacing the power riser .. but still happening. It maybe a bad card I don't know. So I did a benchmark test and this is the result. And it doesn't matter which card I benchmark .. I still get gpu 0 found nonce plus the readout of the card I'm benchmarking. I don't know why. My rig just crashes or ccminer and or drivers crash. And help please... Anyone.  The benchmark thing may be unrelated to your problem. Try swapping the suspect card with card 0 (in the x16 slot I presume) to see if the probkem moves. |
|
|
|
I am right in thinking that higher diff accepts are worth more yeah ?
Yes, because they contain more hash. But they take longer to submit so it evens out in theory. |
|
|
|
its not the work of ccminer to create (and delete) pid files, os should have tools to do that... like start-stop-daemon
Agreed, it should be done in a script or a manager like miner-control. |
|
|
|
Please try with ./configure CFLAGS="-O3 -march=btver1" --with-curl --with-crypto Build successful on both AMD CPU's without -DNO_AES_NI Excelllent, thanks. |
|
|
|
Also, just to confirm, did you successfully compile without the -DNO_AES_NI flag?
I compiled successfully few times on each cpu with this configure ./configure CFLAGS="-DNO_AES_NI -O3 -march=btver1" --with-curl --with-crypto Please try with ./configure CFLAGS="-O3 -march=btver1" --with-curl --with-crypto |
|
|
|
Following the topic I get the impression that the new changes detects cpu, OS, algo (for AES-NI support)
and if the cpu, OS, algo doesnt support AES-NI it falls back to SSE2.
I will send you PM in a few minutes with the compile logs for both CPU's - Phenom II X4 940 and Sempron 145
That is correct. You need all three to get the best performance. I haven't found specifically whether either of your CPUs has AES_NI but I suspect not. Try compiling with -march=core2. It seems to have worked for others. Both AMD's are without AES-NI support. -march=core2 works on both, but the compiled binary is about 15% slower than with -march=btver1. AFAIK its related to SSE implementations on AMD CPU's. So with -march=btver1 which is AMD specific I got the best results. I tried several -march options, starting with core2 and measured the hashrate on the miner and the pool to choose that one for me. P.S. Logs are on the way  The logs you sent had no errors, but that's ok I found the nugget in the first line of the previous compile session: make[2]: *** [algo/echo/aes_ni/cpuminer-hash.o] Error 1 It's clear it was trying to compile AES code. Also, just to confirm, did you successfully compile without the -DNO_AES_NI flag? I've drafted the following note to be added to the README file: Also, just to confirm, did you successfully compile without the -DNO_AES_NI flag? |
|
|
|
Following the topic I get the impression that the new changes detects cpu, OS, algo (for AES-NI support)
and if the cpu, OS, algo doesnt support AES-NI it falls back to SSE2.
I will send you PM in a few minutes with the compile logs for both CPU's - Phenom II X4 940 and Sempron 145
That is correct. You need all three to get the best performance. I haven't found specifically whether either of your CPUs has AES_NI but I suspect not. Try compiling with -march=core2. It seems to have worked for others. |
|
|
|
New in v3.1.15
- unified build procedure fixed
- build.sh now works for CPUs with and without AES_NI
- it is no longer necessary to add "-DNO_AES_NI" CFLAG to the
configure command when building for CPUs without AES_NI.
- The system will automatically compile for the correct architecture
Thanks! Strange thing - when I compile with ./autogen.sh && ./configure CFLAGS="-DNO_AES_NI -O3 -march=btver1" --with-curl --with-crypto && make on AMD Sempron 145, all works like a charm. When I use ./build.sh I get an error in compile. Will try on AMD Phenom II X4 940 and see can I reproduce it. Edit: ./build.sh fails also on AMD Phenom II X4 940 make[2]: *** [algo/echo/aes_ni/cpuminer-hash.o] Error 1
make[2]: *** Waiting for unfinished jobs....
mv -f algo/groestl/sse2/.deps/cpuminer-grso-asm.Tpo algo/groestl/sse2/.deps/cpuminer-grso-asm.Po
mv -f algo/argon2/ar2/.deps/cpuminer-opt.Tpo algo/argon2/ar2/.deps/cpuminer-opt.Po
mv -f algo/argon2/ar2/.deps/cpuminer-ar2-scrypt-jane.Tpo algo/argon2/ar2/.deps/cpuminer-ar2-scrypt-jane.Po
make[2]: Leaving directory `/home/urban/cpuminer-opt-3.1.15'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/*****/cpuminer-opt-3.1.15'
make: *** [all] Error 2
The only real difference I see is -march. build.sh always uses native. -DNO_AES_NI is now redundant and should not be necessary unless -march=native is choosing an incompatible architecture. If that's the case I don't know what I can do other than document the workaround. It would be nice to see the compile errors to give me an idea what it was trying to do. I don't have a non-aesni CPU to test on so it would be nice if you could confirm the capabilities reported when the miner is started is correct. Edit: the real errors are further back but didn't cause the compile to fail immediately. Do they compile if you specify a specific arch but without -DNO_AES_NI? |
|
|
|
cpuminer-opt now supports 31 algorithms on CPUs with at least SSE2 capabilities including Intel Core2 and AMD equivalent. In addition 13 algorithms have optimizations to take advantage of CPUs with AES_NI for even greater performance, including the Intel Core-i 2xxx and AMD equivalent. See the first post of this thread and the README.md file for details. It is currently available in source code format compileable in Linux. Windows source and binary support is planned. cpuminer-opt v3.1.15 is available for download. https://drive.google.com/file/d/0B0lVSGQYLJIZdnI3SG9jNmZNRHM/view?usp=sharingAll users are encouraged to upgrade. New in v3.1.15 - unified build procedure fixed - build.sh now works for CPUs with and without AES_NI - it is no longer necessary to add "-DNO_AES_NI" CFLAG to the configure command when building for CPUs without AES_NI. - The system will automatically compile for the correct architecture |
|
|
|
I don't expect any performance improvements out of the box.
My bad, we were talking about this from different angles. Performance-wise there is no good reason for this. This will _not_ improve performance at all, in fact, the code that is in gcc's implementation of unordered_map and in boost is very similar and will likely behave exactly the same. The only difference is that users won't need to install boost, and on some platforms like Windows boost doesn't come pre-packaged. This harms eventual plans to port this to Windows. Not requiring boost means people won't have to deal with 210 pages of this -- http://stackoverflow.com/search?q=boost+visual-studioSo, to recap: * Performance wise -- there's no difference. * Maintenance wise -- there is. Sorry for misunderstanding. Many thanks, I appreciate your patience with my stubbornness and picky questions. I't's all clear now. |
|
|
|
I don't understand your point. A new compiler feature was added experimentally
Lemme stop you there, GCC supports C++11 since 4.8.1 as feature-complete and stable, not experimental. https://gcc.gnu.org/projects/cxx-status.html#cxx11They do not change defaults for other reason -- a lot of code will break if you upgrade to newer version of the standard, not because it's experimental. I'm still not sure it's the rigt thing to do. So c++11 is not the default until 6.1 over concerns it may break existing code. You have shown it is not the case with cpuminer-opt sothere is little risk. The fact the code is agnostic is good because it can still work on c++98 (not sure about this because I believe it requires code changes between versions). These are all reasons it's not a bad thing but I'm having a hard time coming up with any reasons it's a good thing. I don't expect any performance improvements out of the box, and if there are any to be realized it would require code chnages that would break compatibility. It's forward thinking but the migration could be done at any time, such as after c++11 v6.1 is released. If it had been done with the first hodl release it would have eliminated the need to install packages but now that hodl is in the wild with the libboost dependencies it's no longer an issue. Can you help me out here? Why is it a good thing? |
|
|
|
first off I apologize for my lack of info, I am relatively new to this. Let me describe what happened. I have had the Fury for about two months now and have been successfully mining various alternative cryptocurrencies on a number of pools. I let it run all day and had had no issues at all. Came home about two weeks ago and noticed the cooling fan on top was starting and stopping frequently. I immediately went to the Powersupply and It was not hot at all. Still thinking something was wrong with it, i powered everything down and opened the case on the powersupply found a bulging capacitor. Went and purchased a new power supply witht he same rating and plugged everything back in. When I fire up BFGMiner everything starts just fine, it sees the miner and even register a hashrate. Then I get the connection to stratum disrupted lost --- shares. and it just keeps repeating that over and over. The miner seems to be working properly as far as I can tell...
So the only difference is I am currently at my brothers house for a month and I am mining there. Could there possibly be something he has set up on his internet connection that would cause this? Firewall or something?
Thanks in advance for anything that may help resolve this.
I think you're on the right track, I did suggest a networking issue. Is there any indication there ever was a connection that was lost? Most home firewalls don't block outgoing connections. It could be something more fundamental like getting an IP address on the new network. Do you have any kind of network connectivity? How do you manage the miner, does it have its own KB and monitor inputs or do you use ssh or a web browser? You seem to have gotten lucky with the PSU failure. |
|
|
|
Guys i have downloaded the ufo coin wallet but what programm do i need to install to start mining and how do i install the program and from what website. :/ Im completely lost
Interested in UFOs or the coin? You've been given some good advice, use it. Every pool has instructions on how to mine. |
|
|
|
sigh... its too hard for you to launch 2 miners ?
LOL. I was wondering if one miner could optimize the resource allocation and perfom better than two competing instances. It doesn't matter if it's really that much better. It's brilliantly marketed and it sells! I suppose some users might think it's actualy merge mining. |
|
|
|
sigh... its too hard for you to launch 2 miners ?
LOL. I was wondering if one miner could optimize the resource allocation and perfom better than two competing instances. |
|
|
|
We have seen a nice steady increase in deposits..
Visualized:
If I understand correctly the grey in the left graph is the supply from mining and the grey in the right chart is the float. Is that correct. Edit: I hope this isn't feature creep but may suggest giving an indication of the time coin is locked up? Perhaps the radius of the slice could indicate it in a stepped form, with steps at one month, 3 months and 6 months. I think this would be valuable investor info. If by "float" you mean the remaining supply out there not locked up then yes.. as far as "indication of the time coin is locked up" we have a few things for this.. We have a chart showing individual deposits matured value overlaying on top of the projected total matured total.. we have a chart with each deposits as they are made.. and we have all this info in each Tx info page.. Yes, I mean the supply avaible for trade. And, awesome on the plans. I guess I jumped the gun with my suggestion and should wait to see the full picture. |
|
|
|
We have seen a nice steady increase in deposits.. Visualized: 
7 days later If I understand correctly the grey in the left graph is the supply from mining and the grey in the right chart is the float. Is that correct. Edit: I hope this isn't feature creep but may suggest giving an indication of the time coin is locked up? Perhaps the radius of the slice could indicate it in a stepped form, with steps at one month, 3 months and 6 months. I think this would be valuable investor info. |
|
|
|
Anybody help please....I was forced to buy 2 970 gtx gigabyte g1 graphics cards...only wanted one. Newegg took my BTC and never gave it back forcing me to buy 2. Never doing business with them again. So I'm having problems with it.
I noticed on my 1st card installed it read out 3505,1455..so I set the clocks to 3505,1455.
When I installed the second card and looked at the clocks available .. it read out that both cards showed 3505,1519. ? ? ? Should I set them to 3505,1455 to get to the p0 state? Or should I just leave them in the p2 state? Thx
Set the P0 state only for mining ETH. For other algos there is no need to. I usually set the P0 state first and then overclock with the standard procedure. Thx but what upper clock readout do you are anyone here get on that card. I do set them to p0 state for everything ... but I may try p2 state. The one card I just got is giving me problems like I said above even at p2. Anyone have the same clocks?........maybe related to having 2 of the g1 cards I don't know. Runs for awhile then crashes the drivers at any state they are set at... just curious about the clocks. Crashed 50 times today. I don't understand what are You talking about... So one of Yours 970 G1 works like expected and the other one not? What do You mean both cards showed 3505/1519? Are those the default clocks? Stock 1519 is too high for all 970... Are You runnning win10? Windows 8.1 When I had one 970 g1 the clocks were showing 3505,1455.... with 2 cards... both card clocks showed ...default 3505,1519. Wondering if anyone got the same? Now I don't know if I should set them back to.. 3505,1455. They have been running stable now for an hour. I don't see a problem if the first card runs stable at the higher reported clock rate. It should produce a higher hash rate and higher power usage, but it's up to you whether to downclock it. |
|
|
|
I have a GAWminer fury that I had hashing away on a pool just fine. The power supply crapped out on me, I got a replacement (correct voltage and amperage rating) and now it wont connect to the pool anymore. Actually no pool!! Is it possible I fried it? Anyone else had this issue and know a fix? http://imgur.com/TRjwyhqIt really helps if you provide a detailed problem description. I don't know anything about GAWminer, but yes it's possible. Does it power up ok after the PSU was replaced? How far does it get, where do things take a wrong turn? Are there any alarms, lights, funny noises? Can you login? Not connecting to the pool appears to be a networking issue. Did you reconnect everything? do you have network connectivity? |
|
|
|
|
Show Posts
