Stubo
Member
Offline
Activity: 224
Merit: 13
|
|
November 28, 2017, 05:58:34 PM |
|
Completely disagree. This is dangerous way to overclock and could lead to catastrophic failure of your rig if a card dies on its own.. and they do. Its discussed on the nvidia dev form with some python code that could be adopted to nvOC if anyone is interested: https://devtalk.nvidia.com/default/topic/769851/multi-nvidia-gpus-and-xorg-conf-how-to-account-for-pci-bus-busid-change-/Hi Guys,
I discovered a serious and potentially dangerous flaw in the way nvOC handles overclocking and would like to make a suggestion for an improvement.
We really need overclocking tied to the specific pcie slot (bus id) not an index that changes every time your hardware changes.
For example, if you have a gtx1080ti in slot 2, and a gtx1060 in slot 3, and your 1080ti goes offline for some reason or you remove it, the 1080ti overclock is now applied to what it thinks is the next card in the dumb index, and applies it to your gtx1060 potentially going POOF.
We need to apply overclocking to BUS ID: | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 GeForce GTX 1070 Off | 00000000:02:00.0 Off | N/A | | 70% 56C P2 152W / 151W | 652MiB / 8112MiB | 99% Default | +-------------------------------+----------------------+----------------------+ | 1 GeForce GTX 106... Off | 00000000:04:00.0 Off | N/A | | 70% 61C P2 120W / 120W | 592MiB / 6072MiB | 99% Default | +-------------------------------+----------------------+----------------------+ | 2 GeForce GTX 1070 Off | 00000000:05:00.0 Off | N/A | | 70% 52C P2 118W / 120W | 614MiB / 8113MiB | 99% Default | +-------------------------------+----------------------+----------------------+
Nothing to fix at all oO ... You modified your RIG, you have to modify setting ... How is OC by slot going to fix the scenario where a person just moves cards around in a rig as opposed to just removing one? Both scenarios are hardware changes and common sense dictates that the user be aware of this potential because they went down the path of path of individual OC in the first place. It is not like they went there by mistake, right?
|
|
|
|
Reinars
Newbie
Offline
Activity: 13
Merit: 0
|
|
November 28, 2017, 07:03:31 PM |
|
Hey guys. Srsly nvOc Is amazing!!! All rigs goin like monsters over here. Just one question. One Rig does not want to launch any kind of miners. Whenever I put "ETH" with my address and all it shows something about stratum. Whenever I try to mine ZEC ( which is my main coin ) There is simply Nothing I Can do, it shows "there is no screen to be attached matching miner" I double checked and still - there is no mining coming out from the rig. Anyone had this problem before?
|
|
|
|
papampi
Full Member
Offline
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
|
|
November 28, 2017, 07:36:17 PM |
|
Hey guys. Srsly nvOc Is amazing!!! All rigs goin like monsters over here. Just one question. One Rig does not want to launch any kind of miners. Whenever I put "ETH" with my address and all it shows something about stratum. Whenever I try to mine ZEC ( which is my main coin ) There is simply Nothing I Can do, it shows "there is no screen to be attached matching miner" I double checked and still - there is no mining coming out from the rig. Anyone had this problem before?
Check your network connectivity can you ping google.com ?
|
|
|
|
leenoox
|
|
November 28, 2017, 09:06:31 PM |
|
There are moments that only 1 GPU wont get fully utilize and keep on going like that, problem with the current wdog on multiple GPUs is that it takes so long for wdog to restart 3 main if only one gpu fails, so on a 12 card rig it takes 72 times and while it checks every 10 seconds it will take more than 10 minutes for it to restart 3main
Any idea how to correct this?
Oh believe me, I have thought about this one, too, and have yet to arrive and what I feel is a good solution. Having the reboot time grow proportionally to #GPU is not ideal, IMO. I am all ears if somebody wants to chime in. The best that I can come up with is an upper limit on count instead of just 6xGPU. There has to be a better way. The watchdog needs complete overhaul, some of its logic has no logic at all I had cases when one GPU would hang and pretty much brings the whole rig to a crawl. Its 6x logic (x 13 GPU's for me) caused 3-4 hours of slow ~10% performance before it realized its time to reboot. Quick solution for me was to scratch its logic and change the code to reboot on any detected problem... I'd rather lose 1 minute rebooting than 4 hours of mining at 10% I will revisit the watchdog soon, see if i can come up with some new logic for it
|
|
|
|
Stubo
Member
Offline
Activity: 224
Merit: 13
|
|
November 28, 2017, 10:20:40 PM |
|
There are moments that only 1 GPU wont get fully utilize and keep on going like that, problem with the current wdog on multiple GPUs is that it takes so long for wdog to restart 3 main if only one gpu fails, so on a 12 card rig it takes 72 times and while it checks every 10 seconds it will take more than 10 minutes for it to restart 3main
Any idea how to correct this?
Oh believe me, I have thought about this one, too, and have yet to arrive and what I feel is a good solution. Having the reboot time grow proportionally to #GPU is not ideal, IMO. I am all ears if somebody wants to chime in. The best that I can come up with is an upper limit on count instead of just 6xGPU. There has to be a better way. The watchdog needs complete overhaul, some of its logic has no logic at all I had cases when one GPU would hang and pretty much brings the whole rig to a crawl. Its 6x logic (x 13 GPU's for me) caused 3-4 hours of slow ~10% performance before it realized its time to reboot. Quick solution for me was to scratch its logic and change the code to reboot on any detected problem... I'd rather lose 1 minute rebooting than 4 hours of mining at 10% I will revisit the watchdog soon, see if i can come up with some new logic for it I was thinking of detecting similar situations by looking for the top process and looking at CPU utilization. However, there is the option of "plusCPU" where the CPU is mining XMR and it is pegged so that must be accounted for. In the scenario you describe above, is there any chance you saw error from the miner - "[Unknown Error]"? I have found that to be the one that turns 10 seconds into 1 minute on one of my rigs while mining with the DSTM ZM miner.
|
|
|
|
leenoox
|
|
November 29, 2017, 04:54:46 AM |
|
There are moments that only 1 GPU wont get fully utilize and keep on going like that, problem with the current wdog on multiple GPUs is that it takes so long for wdog to restart 3 main if only one gpu fails, so on a 12 card rig it takes 72 times and while it checks every 10 seconds it will take more than 10 minutes for it to restart 3main
Any idea how to correct this?
Oh believe me, I have thought about this one, too, and have yet to arrive and what I feel is a good solution. Having the reboot time grow proportionally to #GPU is not ideal, IMO. I am all ears if somebody wants to chime in. The best that I can come up with is an upper limit on count instead of just 6xGPU. There has to be a better way. The watchdog needs complete overhaul, some of its logic has no logic at all I had cases when one GPU would hang and pretty much brings the whole rig to a crawl. Its 6x logic (x 13 GPU's for me) caused 3-4 hours of slow ~10% performance before it realized its time to reboot. Quick solution for me was to scratch its logic and change the code to reboot on any detected problem... I'd rather lose 1 minute rebooting than 4 hours of mining at 10% I will revisit the watchdog soon, see if i can come up with some new logic for it I was thinking of detecting similar situations by looking for the top process and looking at CPU utilization. However, there is the option of "plusCPU" where the CPU is mining XMR and it is pegged so that must be accounted for. In the scenario you describe above, is there any chance you saw error from the miner - "[Unknown Error]"? I have found that to be the one that turns 10 seconds into 1 minute on one of my rigs while mining with the DSTM ZM miner. yup, it was "Unknown Error" when some GPU hangs, for me it was turning the 10 second cycle into about 5 minutes Confirmed by adding debug logging option... lowering the OC reduced those hangs, it still happens once in a while but adding reboot into the loop took care of it (dirty fix)
|
|
|
|
Temporel
|
|
November 29, 2017, 12:03:54 PM |
|
Completely disagree. This is dangerous way to overclock and could lead to catastrophic failure of your rig if a card dies on its own.. and they do. Its discussed on the nvidia dev form with some python code that could be adopted to nvOC if anyone is interested: https://devtalk.nvidia.com/default/topic/769851/multi-nvidia-gpus-and-xorg-conf-how-to-account-for-pci-bus-busid-change-/Hi Guys,
I discovered a serious and potentially dangerous flaw in the way nvOC handles overclocking and would like to make a suggestion for an improvement.
We really need overclocking tied to the specific pcie slot (bus id) not an index that changes every time your hardware changes.
For example, if you have a gtx1080ti in slot 2, and a gtx1060 in slot 3, and your 1080ti goes offline for some reason or you remove it, the 1080ti overclock is now applied to what it thinks is the next card in the dumb index, and applies it to your gtx1060 potentially going POOF.
Nothing to fix at all oO ... You modified your RIG, you have to modify setting ... top posting is disrespectful, wake up kiddo.
|
|
|
|
papampi
Full Member
Offline
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
|
|
November 29, 2017, 01:19:50 PM |
|
Completely disagree. This is dangerous way to overclock and could lead to catastrophic failure of your rig if a card dies on its own.. and they do. Its discussed on the nvidia dev form with some python code that could be adopted to nvOC if anyone is interested: https://devtalk.nvidia.com/default/topic/769851/multi-nvidia-gpus-and-xorg-conf-how-to-account-for-pci-bus-busid-change-/Hi Guys,
I discovered a serious and potentially dangerous flaw in the way nvOC handles overclocking and would like to make a suggestion for an improvement.
We really need overclocking tied to the specific pcie slot (bus id) not an index that changes every time your hardware changes.
For example, if you have a gtx1080ti in slot 2, and a gtx1060 in slot 3, and your 1080ti goes offline for some reason or you remove it, the 1080ti overclock is now applied to what it thinks is the next card in the dumb index, and applies it to your gtx1060 potentially going POOF.
Nothing to fix at all oO ... You modified your RIG, you have to modify setting ... top posting is disrespectful, wake up kiddo. 👍👍👍👍
|
|
|
|
poisonxa
|
|
November 30, 2017, 05:10:47 AM |
|
Guys if you need faster Help getting your Rig up and running Visit us at our Discord Channel : https://discord.gg/8YDFEvY You will get faster response so less downtime on your miner
|
|
|
|
leenoox
|
|
November 30, 2017, 06:46:54 AM |
|
Claymore released version 10.2 for eth/dual miner. TODO: update miner in next nvOC release
if you want to update to it do a quick search in this thread, it's been posted few times how to update it
|
|
|
|
papampi
Full Member
Offline
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
|
|
November 30, 2017, 07:46:52 AM Last edit: November 30, 2017, 03:42:02 PM by papampi |
|
Claymore released version 10.2 for eth/dual miner. TODO: update miner in next nvOC release
if you want to update to it do a quick search in this thread, it's been posted few times how to update it
Thanks mate, Added to unofficial 19-2 update
|
|
|
|
damNmad
Full Member
Offline
Activity: 378
Merit: 104
nvOC forever
|
|
November 30, 2017, 01:58:26 PM |
|
Claymore released version 10.2 for eth/dual miner. TODO: update miner in next nvOC release
if you want to update to it do a quick search in this thread, it's been posted few times how to update it
Thanks mate, Will add to unofficial 19-2 update I think adding new claymore is even more simpler from 1_4 version, we just download the latest version, rename the main folder to 10_2 and add that selection in 1bash CLAYMORE_VERSION="10_2" # choose 10_2 or 10_0 or 9_8 or 9_7 or 9_5 or 9_4 or 8_0 this should do i think!
|
|
|
|
DangerD
Newbie
Offline
Activity: 24
Merit: 0
|
|
November 30, 2017, 02:51:33 PM |
|
Can somebody please compile ccminer2.2.2 ? ( https://github.com/tpruvot/ccminer ) I need compiled binary... Can't do it because i don't have free space on flash stick...
|
|
|
|
Alienbert
Newbie
Offline
Activity: 26
Merit: 0
|
|
November 30, 2017, 03:10:02 PM |
|
Hi. Simple question for you I want to mine ZEC to a closed pool with PW. Is this the correct way?: Miner name set CUSTOM than Username.worker:PW ZEC_WORKER="$WORKERNAME" # replace_with_your_ZEC_address ZEC_ADDRESS="" ZEC_POOL="coinotron.com" ZEC_PORT="3346" Do i need zec adress, because the adress is saved on pool. Is this right? Thanks
|
|
|
|
damNmad
Full Member
Offline
Activity: 378
Merit: 104
nvOC forever
|
|
November 30, 2017, 03:12:06 PM |
|
I think i have compiled it very recently, will try to update it to my drive and share.
|
|
|
|
damNmad
Full Member
Offline
Activity: 378
Merit: 104
nvOC forever
|
|
November 30, 2017, 03:17:30 PM |
|
Hi. Simple question for you I want to mine ZEC to a closed pool with PW. Is this the correct way?: Miner name set CUSTOM than Username.worker:PW ZEC_WORKER="$WORKERNAME" # replace_with_your_ZEC_address ZEC_ADDRESS="" ZEC_POOL="coinotron.com" ZEC_PORT="3346" Do i need zec adress, because the adress is saved on pool. Is this right? Thanks I think coinotron is like suprnova or miningpoolhub. you need to have an account with them, have a worker on their dashboard and make sure you set password 'z' for that worker! (never used that pool, please correct me if i am wrong). ZEC_WORKER="yourCointronWorkerName" ZEC_ADDRESS="cointronLoginName" I have checked their help page, if you follow the above, it should work.
|
|
|
|
Alienbert
Newbie
Offline
Activity: 26
Merit: 0
|
|
November 30, 2017, 03:35:50 PM |
|
Hi. Simple question for you I want to mine ZEC to a closed pool with PW. Is this the correct way?: Miner name set CUSTOM than Username.worker:PW ZEC_WORKER="$WORKERNAME" # replace_with_your_ZEC_address ZEC_ADDRESS="" ZEC_POOL="coinotron.com" ZEC_PORT="3346" Do i need zec adress, because the adress is saved on pool. Is this right? Thanks I think coinotron is like suprnova or miningpoolhub. you need to have an account with them, have a worker on their dashboard and make sure you set password 'z' for that worker! (never used that pool, please correct me if i am wrong). ZEC_WORKER="yourCointronWorkerName" ZEC_ADDRESS="cointronLoginName" I have checked their help page, if you follow the above, it should work. Thanks! I want to try it now! Yes you right. You must have an account. Why should the PW "z"? I write again if work or not UPDATE: WORKS GREAT. THANKS FOR THE HELP
|
|
|
|
damNmad
Full Member
Offline
Activity: 378
Merit: 104
nvOC forever
|
|
November 30, 2017, 04:07:36 PM |
|
Hi. Simple question for you I want to mine ZEC to a closed pool with PW. Is this the correct way?: Miner name set CUSTOM than Username.worker:PW ZEC_WORKER="$WORKERNAME" # replace_with_your_ZEC_address ZEC_ADDRESS="" ZEC_POOL="coinotron.com" ZEC_PORT="3346" Do i need zec adress, because the adress is saved on pool. Is this right? Thanks I think coinotron is like suprnova or miningpoolhub. you need to have an account with them, have a worker on their dashboard and make sure you set password 'z' for that worker! (never used that pool, please correct me if i am wrong). ZEC_WORKER="yourCointronWorkerName" ZEC_ADDRESS="cointronLoginName" I have checked their help page, if you follow the above, it should work. Thanks! I want to try it now! Yes you right. You must have an account. Why should the PW "z"? I write again if work or not UPDATE: WORKS GREAT. THANKS FOR THE HELP Well, that password is not that important, you can put anything, its just a worker password, people can't move fund with that password. I asked you to set it to 'z' because it has been configured as 'z' in 3main or nvOC. You can try with other passwords and test it.
|
|
|
|
|
damNmad
Full Member
Offline
Activity: 378
Merit: 104
nvOC forever
|
|
November 30, 2017, 04:47:52 PM |
|
Great collection Stubo
|
|
|
|
|