I also have an issue with ccminer, noescrypt version, on my gaming rig I have 3 cards on is for normal use and gaming the other 2 I mine with, my hashrate drops to 2-4k from 1.5mh when i try paying games, even the power and temps drop to idle speed, 2 cards are in a 16x slot and one other in a 1x slot(riser).
it's not surprising that neoscrypt causes problems but I think it's more the algo than anything. It is the highest memory usage per miner on my pool.... Yeah. I was getting crazy p-state locks requiring me to reboot to get out of P8 state (150Mhz gpu clock and ~800mhz mem clock)... I think neoscrypt is going to be dropped out of my batch even though it pays good and quick. le sigh. More testing once removed and a batch update. Hi JK...all I can say is that I can't put my hi end cards in the p0 state because it will crash more and other people I know that had them in the p0 state reported the same thing...I believe on those algo's . So they went back to the p2 state. But many times on lyra2v2 and neoscrypt is where I have the most crashes. Hope that helps. AMPH was one who had that problem and took her cards back to the p2 state. |
|
|
|
|
And where is that command plz on keeping the rig in the administrative mode on reboot. Thx
|
|
|
|
Thx JK I have done this. Will that keep them in the p0 state on reboot?
EDIT: I'm going to give this a try again asap. thx
No.. this will have to have admin rights first deactivated (check zpool thread for command) then reboot, and it shouldn't need admin rights anymore. then add the path to the NVSMI folder to the system PATH and you can just call it from any old command prompt/provision allotment =) Issue the memory and clock set command every reboot, or better right before the miner app launches. Thx JaredKaragen looking into it. And where is that command plz on keeping the rig in the administrative mode on reboot. Thx |
|
|
|
A note 7-21-2016 My rig mined all day with all cards with MC.  Room temp 92f humidity 35% For the four days before that the rig crashed at only 87f humidity 85%Possibility the humidity played some role in the crashing on with the 970gtx that mines in p2 clocks default 1413 core. Maybe micro dust. This weeks temp are supposed to be record breaking 100f......... humidity.? Slowly one thing at a time to pin down the 3 things contributing to the crashing. Due to heat I will have to shut down the rig for sometime during the day for the next 5 days. EDIT:7-22-16 rig mined all day today with MC room temp max 95f hum 45% the only change I did was turn off oc'ing and set "delay": 15 to "delay": 30. So one problem is heat related cards changing algo's going from the p2 state to p8 state in order to mine or some call it spin down time. The hotter it is the longer it takes for spin down. Interesting observation. I never really considered that it would be more susceptible to crash when switching algos, or that spin down time could mitigate. Good to see you're making progress with your "heat chamber" testing. Thx joblo yes still in a severe heat wave..never seen this before. One day I turned off the miners until the evening. Today same thing I think 100f  EDIT: I do have the temperatures of the cards set at a max.. to not exceed 79c ect. And I use to get this but was going to talk about it later. Going to myr-gr also on neoscrypt so not related to algo but memory or ccminer? Maybe intensity setting.  |
|
|
|
Here's another useful cut and paste. I was able to kick my live mining machine from P2 into P0, no interruptions. I am thinking of building this command into my batch every time it re-launches the miner apps to make sure P-state is zero. Run this in cmd in admin mode:
c:\progra~1\nvidia~1\NVSMI\
nvidia-smi -q -d SUPPORTED_CLOCKS | more
(that's a pipe before more)
Take the top number for memory, something like 3505 (GTX970), and the first number for graphics, something like 1531. Again in admin mode, enter your numbers in this format:
nvidia-smi -ac 3505,1531
You're card's memory will now run in compute mode (P0). nvidia-smi.exe -ac 3505,1443 For my ASUS GTX 980. Ive also noticed X11evo is a power-hungry algo. One machine used to sit at 80-84*C when running only X11EVO. Now Running Lyra2 full-time and it sits @65*C... Thx JK I have done this. Will that keep them in the p0 state on reboot? EDIT: I'm going to give this a try again asap. thx |
|
|
|
Thx JK
If I took out skein algo out of my conf file would I earn more BTC? Thx
I just noticed every time my miner would stay on skien more than other algos, it wouldn't earn near as much during that time. Putting my machine solid on lyra2 for a few weeks has been surprisingly good returns. Yes I noticed that too. And right now their all on that algo...maybe one or two coins in that algo bringing down the profits. Thx |
|
|
|
|
Thx JK
If I took out skein algo out of my conf file would I earn more BTC? Thx
|
|
|
|
Especially with non gpu algo's |
|
|
|
SP you enough money for a miner has collected, pruvot already released his miner, now your turn! Results Tpruvot 1.8 miner 960 OC +200 970 OC +170 Mem -505  Velgelm....I noticed you underclocked your mem does how much does this help plz |
|
|
|
Thx oc going to mine at your pool with my 750ti rig to try out. |
|
|
|
A note 7-21-2016 My rig mined all day with all cards with MC. Room temp 92f humidity 35% For the four days before that the rig crashed at only 87f humidity 85%Possibility the humidity played some role in the crashing on with the 970gtx that mines in p2 clocks default 1413 core. Maybe micro dust. This weeks temp are supposed to be record breaking 100f......... humidity.? Slowly one thing at a time to pin down the 3 things contributing to the crashing. Due to heat I will have to shut down the rig for sometime during the day for the next 5 days. EDIT:7-22-16 rig mined all day today with MC room temp max 95f hum 45% the only change I did was turn off oc'ing and set "delay": 15 to "delay": 30. So one problem is heat related cards changing algo's going from the p2 state to p8 state in order to mine or some call it spin down time. The hotter it is the longer it takes for spin down. |
|
|
|
|
How many coins per block plz? Thx
|
|
|
|
Hi everyone, is there a lbry nvidia miner app yet? thx
Latest tpruvot's, version 1.8. I compiled it from git and it works. Not sure there are binaries out there, though. Thx pallas what would the bat file look like for a 750ti? thx ADDED TO MY MINERCONTROL.CONF-- I compiled it under Lunux/CUDA 7.5 and get about 50MH/s per 750ti. The launch line is "ccminer -a lbry -o stratum+tcp://pooladdress:port -u user -p password". I find that you can use high intensity settings "-i 23.7", but if you go too high, performance declines. A setting of "-i 23.9" worked without crashing, but gave lower hash rates. I had to start it manually with MinerControl, because Zpool has not found a block yet. Zpool might not find a block, only 19 miners last time I looked, about 3.5GH/s pool total hash rate. --scryptr Thx scryptr |
|
|
|
|
Scrypt plz change it to gpu friendly. thx
|
|
|
|
Hi everyone, is there a lbry nvidia miner app yet? thx
Latest tpruvot's, version 1.8. I compiled it from git and it works. Not sure there are binaries out there, though. Thx pallas what would the bat file look like for a 750ti? thx |
|
|
|
|
Hi everyone, is there a lbry nvidia miner app yet? thx
|
|
|
|
Finally I see the error massage .. ccminer has been blocked from accessing the graphics driver.
Any help plz
Sorry Crackfoo for messing up your thread.
Are you running it as administrator? No.... giving that a try. EDIT:Same thing. an app....blocked ... ccminer has been blocked from accessing the graphics driver. How do I find out what app. anyone plz. At lest I found why its crashing. Sorry Crackfoo for messing up your thread. Reinstalling drivers. How do I find out what app. anyone plz. I had to shut that rig down for now. It has nothing to do with the pool, I suggest a seperate thread. It's a problem between ccminer and the GPU, which includes the OS and the drivers. Have you googled the error message for clues as to its meaning? Beyond that have you done any HW troubleshooting? Have you been messing with the clocks or voltage? Can you identify a trigger? Part of the time it was the pool read back me talking to Crackfoo I'm giving.. up the only solution I have is to take out the gigabyte 970. I'm done. 5 months of this problem ..it worked great for 4 days when crackfoo made an adjustment but it is a multiple problem. Putting 2x 970 gigabyte gtx g1 on the shelf. Garbage cards. My apologies for offering to help. Sorry joblo my sincere apologies. I have so many other things hitting me at once..legal matters that I don't know which why is up. I hope you understand. Thank you. As I said 4 days of mining without a problem after crackfoo did a pool adjustment no messing with anything. No problem. I can help when you're ready. I did this for a living and was pretty good at it, but it was a completely different system. Thx |
|
|
|
what algo? were you mining all the time? it's alltime-skein to tty payout not the top class yaamp humor but close  |
|
|
|
Not sure if this will help you at all but I was having a issue similar. I had one 970, two 960 and one 750ti in a rig and I had one card that would always crash while mining certain algos. It was always the same 960 and sometimes a few minutes and sometimes a few hours. I used Nvidia Inspector to determine this as it always showed the same card with the fan down to 0% after the crash. I tried new risers (powered usb) and the same thing. I was starting to think I had a bad card so I switched the 960's only in each riser to narrow it down. Low and behold the card that was having no issues started crashing and the card that was crashing would not anymore. Same thing after switching and same algos. The card that was crashing would not at all any more. I was perplexed. ran out of ideas and I had one last thought. I just switched the riser connector on the mother board that was crashing with my 750ti pci-e slots. I looked in Nvidia Inspector and noticed my 960 that was crashing had switched PCI Interface numbers. Both 960 cards read 3.0@1.1x1 before the switch and after the card that was crashing read 3.0@2.0x1. Now it reads the same as my 750ti. So both 960's read different values and I have not had a single issue since. I am no expert and have no idea why it fixed it but it did. Hope that might help and hope it made sense. Thank you antonio8. Glad you found your problem. I have done the switching but I need to look into it in detail. But I have had 3 970, I think all from the same batch or lot, and all were not mining in the p2 state at 1178 core. They were at about 1423 core clocks. Going to call gigabyte again asap. Will look into switching slots again. It's as if they where oc'd without oc'ing them. Thx |
|
|
|
Still doing great on lyra2v2 stright mining almost 20 hours. Next is to do Minercontrol without the 970 in the confg file. Do to things I must attend to.. I may not be able to post until Thursday. Thx  |
|
|
|
|
Show Posts
