Anybody got X13 (DeepCoin) running in nvoc ? How much mh/s are you getting ?
I get 30 mh/s with 2x 1060 and 1x 1080 ti
Not sure if its worth...
Topic: [ mining os ] nvoc - page 287. (Read 418549 times)
as mentioned above I wish to use an ASROCK z87 killer mobo (7PCIe) slots.
@fullzero says that he doesn't have the "system files for the z87 chipset" so nvOC doesn't contain them. Where would I obtain them and how would I install them?
@fullzero says that he doesn't have the "system files for the z87 chipset" so nvOC doesn't contain them. Where would I obtain them and how would I install them?
Does anyone know if there is a way to set temperature target for card instead of powerlimit? I have couple gtx 1060 cards that won't go below 97W when running in nvOC, which is 80% power limit, same thing is in windows no matter which tool I use, but when I use power target in windows and set it to ie.65C the cards power usage goes down to 80W. Unfortunately I wasn't able to find if there is a way to control temp target in linux. Any help would be greatly appreciated.
If you use v0018 and download the newest 1bash and files / copy them to the home directory replacing the ones that are there / configure the 1bash:
setting:
Code:
Maxximus007_AUTO_TEMPERATURE_CONTROL="YES"
and each individual powerlimit and temperature limit + control settings:
Code:
INDIVIDUAL_POWERLIMIT_0=75
INDIVIDUAL_POWERLIMIT_1=75
INDIVIDUAL_POWERLIMIT_2=75
INDIVIDUAL_POWERLIMIT_3=75
INDIVIDUAL_POWERLIMIT_4=75
INDIVIDUAL_POWERLIMIT_5=75
INDIVIDUAL_POWERLIMIT_6=75
INDIVIDUAL_POWERLIMIT_7=75
INDIVIDUAL_POWERLIMIT_8=75
INDIVIDUAL_POWERLIMIT_9=75
INDIVIDUAL_POWERLIMIT_10=75
INDIVIDUAL_POWERLIMIT_11=75
INDIVIDUAL_POWERLIMIT_12=75
INDIVIDUAL_POWERLIMIT_13=75
# Set the target temperature per card.
# Don't set it too low, if the temperature can't be reached with fan adjustments it will decrease power.
# Recommended ranges: 55 - 70 degrees Celsius
# If actual temp is above the target temp this script will up the fan speed
TARGET_TEMP_0=70
TARGET_TEMP_1=70
TARGET_TEMP_2=70
TARGET_TEMP_3=70
TARGET_TEMP_4=70
TARGET_TEMP_5=70
TARGET_TEMP_6=70
TARGET_TEMP_7=70
TARGET_TEMP_8=70
TARGET_TEMP_9=70
TARGET_TEMP_10=70
TARGET_TEMP_11=70
TARGET_TEMP_12=70
TARGET_TEMP_13=70
# If actual temp is above value set above and fan speed is 100,
# the script will lower the power limit
# SET INDIVIDUAL POWERLIMITS ABOVE
# Adjustment size (FAN in percent, POWER in Watts)
__FAN_ADJUST=5
POWER_ADJUST=5
# Difference in actual temperature allowed before action.
#Works only if current is BELOW target temp
ALLOWED_TEMP_DIFF=3
# Restore original power limit if fan speed is lower than this percentage
RESTORE_POWER_LIMIT=90
# lowest fan speed that will be used
MINIMAL_FAN_SPEED=50
This won't work as the script controls temperature with fan speed and power limit and for my cards power limit won't work.
I am seeing a new error i have not seen before.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
Yes, same problem.
I am seeing a new error i have not seen before.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
Could it have something to do with a high resolution screen being present?
I have tried another image and the same thing occurred.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
Could it have something to do with a high resolution screen being present?
I have tried another image and the same thing occurred.
go to the quake terminal window and type "screen -r miner" and you should see your miner running
Have you set:
Code:
LOCALorREMOTE="REMOTE"
if so then this is expected
as newmz indicated:
open a terminal and enter
Code:
screen -r miner
to attach the mining process
The code is LOCAL. I have not adjusted the default.
If this is occurring it is because there is already a mining process going on before 1bash has been launched. Thus when the code attempts to attach the new process to the gnome-terminal it finds multiple screens; and cannot attach without you specifying which (which is not done by the code in 1bash).
The bugfix files + newest 1bash should prevent this from happening. I highly suspect many members are using the newest 1bash without updating the other files or using the new files without updating their 1bash. The next version will incorporate a method that should do away with this kind of problem.
I realize all of these changes are a pain to deal with; and it doesn't help that v0018 wasn't properly tested beforehand. I think I have a solution to accommodate users who prefer a known stable build and users who want the newest unverified beta; I will implement this in v0019 as well.
If you are using the newest 1bash and newest files and this problem is still occurring; I would reboot and not change any settings on startup. The initial boot should attach the mining process to a screen in the gnome-terminal.
I got this message sometime to, but only when i try some OC setting and the miner crash chain ... I simply hard reset and work again.
I am seeing a new error i have not seen before.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
Yes, same problem.
I am seeing a new error i have not seen before.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
Could it have something to do with a high resolution screen being present?
I have tried another image and the same thing occurred.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
Could it have something to do with a high resolution screen being present?
I have tried another image and the same thing occurred.
go to the quake terminal window and type "screen -r miner" and you should see your miner running
Have you set:
Code:
LOCALorREMOTE="REMOTE"
if so then this is expected
as newmz indicated:
open a terminal and enter
Code:
screen -r miner
to attach the mining process
The code is LOCAL. I have not adjusted the default.
How about the option to set auto shutdown when the power button is pressed? I often need to move rigs and want to shut them down without plugging in or remoting in.
I have been running the following:
gsettings set org.gnome.settings-daemon.plugins.power button-power 'shutdown'
cheers
I have been running the following:
gsettings set org.gnome.settings-daemon.plugins.power button-power 'shutdown'
cheers
If you hold down the power button for ( I believe it is 5 seconds it should shutdown) . Is this shutdown different other than it acting immediately?
My understanding, and I may be completely wrong. Is that holding the power button is the same as turning off the power.
I am seeing a new error i have not seen before.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
Could it have something to do with a high resolution screen being present?
I have tried another image and the same thing occurred.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
Could it have something to do with a high resolution screen being present?
I have tried another image and the same thing occurred.
go to the quake terminal window and type "screen -r miner" and you should see your miner running
So it's by design then?
Would it be possible/easy to please add/explain how I can add a Genoil switch for EXP? It seems to default to claymore...
Thanks!
Thanks!
Hi Guys,
There appears to be a bug with the Maxximus007_AUTO_TEMPERATURE_CONTROL. I verified in the nvoc0018 version and also in the updated patch to nv0018. I wanted to make sure the bug was still in the patched version before saying anything but now I have verified it is still there.
SO the bug is that whatever your individual power limit (MAIN ONE) is set to, is used only right in the beginning when the rig starts up. After the Maxximus007_AUTO_TEMPERATURE_CONTROL takes over it starts using whatever power limits are set in the INDIVIDUAL section.
The only way to fix this right now is set each individual power limit to whatever you want.
Obviously you have to restart 1bash for the new changes to take effect or reboot the rig.
There appears to be a bug with the Maxximus007_AUTO_TEMPERATURE_CONTROL. I verified in the nvoc0018 version and also in the updated patch to nv0018. I wanted to make sure the bug was still in the patched version before saying anything but now I have verified it is still there.
SO the bug is that whatever your individual power limit (MAIN ONE) is set to, is used only right in the beginning when the rig starts up. After the Maxximus007_AUTO_TEMPERATURE_CONTROL takes over it starts using whatever power limits are set in the INDIVIDUAL section.
The only way to fix this right now is set each individual power limit to whatever you want.
Obviously you have to restart 1bash for the new changes to take effect or reboot the rig.
Why did my hash rate mining ETH on Claymore 9.7 go from 23.5 on Windows 7 down to 18.9 on nvOC? I have the power set to 94 and the mc set to 825. Is the latest driver that bad for 1060 cards? I am pretty sure I have the latest driver on Windows.
The OC curve for Linux is different than Windows. You need to set a higher OC to get the same results in linux. Also in Windows power limit is in % TDP; in linux it is in watts.
Try a mc of 1000, then keep bumping it up until you see a soft crash.
If your 1060s have the standard TDP of 125: to set an equalivent power limit you need to use 0.87 * 125 (or whatever the exact TDP of your model is) = 109 watts
I have 2 1070s and 3 1060s. When mining eth, I set core overclock to -200 and memory overclock to 1300. I get approx 135mh/s whereas stock it's somewhere in the region of 95mh/s.
I am seeing a new error i have not seen before.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
Could it have something to do with a high resolution screen being present?
I have tried another image and the same thing occurred.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
Could it have something to do with a high resolution screen being present?
I have tried another image and the same thing occurred.
go to the quake terminal window and type "screen -r miner" and you should see your miner running
Hello, is anyone successfully using the Asrock Z87-Killer Socket 1150 motherboard with nvOC?
It has 7 PCIe sockets so I bought one hoping I could expand my 5 GPU rig to a 7 (Nvidia) GPU rig and get rid of some of my power hungry AMD R9 290s.
Any reason why it wont work?
It has 7 PCIe sockets so I bought one hoping I could expand my 5 GPU rig to a 7 (Nvidia) GPU rig and get rid of some of my power hungry AMD R9 290s.
Any reason why it wont work?
I am seeing a new error i have not seen before.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
Yes, same problem.
I am seeing a new error i have not seen before.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
Could it have something to do with a high resolution screen being present?
I have tried another image and the same thing occurred.
There is no screen to be resumed matching miner.
In the terminal window right before the miner of choice starts. And the mining still does seem to start in the background.
Could it have something to do with a high resolution screen being present?
I have tried another image and the same thing occurred.
fullzero,
After testing this week it seems the problems were the flash drive nothing more.
It must have been getting write errors for quite some time that finally it just died causing the rig instability.
I appreciate all the hard work!
After testing this week it seems the problems were the flash drive nothing more.
It must have been getting write errors for quite some time that finally it just died causing the rig instability.
I appreciate all the hard work!
How about the option to set auto shutdown when the power button is pressed? I often need to move rigs and want to shut them down without plugging in or remoting in.
I have been running the following:
gsettings set org.gnome.settings-daemon.plugins.power button-power 'shutdown'
cheers
I have been running the following:
gsettings set org.gnome.settings-daemon.plugins.power button-power 'shutdown'
cheers
I am experiencing the exact same problems almost verbatim as the poster above. I was thinking it is related to a bad flash drive possibly. I am trying a different one. Also version 14 and 15 seem to work better than 17 and 18. I am getting lag and freezes and random reboots just trying to use you ubuntu with no mining software running.
I would change
to
But your ZEC config looks like it should work with DwarfPool.
It is also worth trying removing the workername:
to
With:
Also I have the error "Utilization is too low: restart 1bash" and multiple "Maxximus007_AUTO_TEMPERATURE_CONTROL" tabs. What it's mean? Maybe this is a reason of problem?
Due to some changes I made in the last 1bash; currently when in LOCAL mode: each restart of 1bash will kill the existing Maxximus007_AUTO_TEMPERATURE_CONTROL process, but not kill the tab containing it; then a new Maxximus007_AUTO_TEMPERATURE_CONTROL tab will be created with a new process inside.
The problem is likely that you are not connecting to the pool for some reason; when this happens the watchdog will detect low utilization and restart 1bash.
You can see if you can reach the pool by opening a new guake tab and entering the following cmd:
I would try to use a different pool and see if you can connect. For now while troubleshooting; I would set :
Code:
ZEC_PORT="3337"
to
Code:
ZEC_PORT="3333"
But your ZEC config looks like it should work with DwarfPool.
It is also worth trying removing the workername:
Code:
ZEC_WORKER="nv$IP_AS_WORKER"
to
Code:
ZEC_WORKER=""
With:
Also I have the error "Utilization is too low: restart 1bash" and multiple "Maxximus007_AUTO_TEMPERATURE_CONTROL" tabs. What it's mean? Maybe this is a reason of problem?
Due to some changes I made in the last 1bash; currently when in LOCAL mode: each restart of 1bash will kill the existing Maxximus007_AUTO_TEMPERATURE_CONTROL process, but not kill the tab containing it; then a new Maxximus007_AUTO_TEMPERATURE_CONTROL tab will be created with a new process inside.
The problem is likely that you are not connecting to the pool for some reason; when this happens the watchdog will detect low utilization and restart 1bash.
You can see if you can reach the pool by opening a new guake tab and entering the following cmd:
Code:
ping zec-ru1.dwarfpool.com
I would try to use a different pool and see if you can connect. For now while troubleshooting; I would set :
Code:
IAmNotAJeep_and_Maxximus007_WATCHDOG="NO"
fullzero, thank you for your reply. I'm sure that is no problem with connection to the pool, also ping is ok. I think it's a some problem with powerlimit, because when I disabled watchdog and trying to change some parameters, include powerlimit, my hashrate is growing to 200 Sol/s, also when I changed some parameters I seen my hashrate grow to 400 Sol/s, but I don't remember parameters what I changed. So at this moment I have hashrate 200 Sol/s with powerlimit 200, when I trying to change it to 250 I have lower hashrate. Cc 150, mc 900 as you wrote in the first message here. Also console showed power consumption lower than I set powerlimit. Any idea?
I made an updated 1bash which should resolve these powerlimit / remote issues. With the powerlimits the autotemp was not reinitializing unless explicitly killed or the rig was logged out or rebooted. This had the effect of not allowing changes to the individual powerlimits until such killing or logout / reboot.
In your picture I can see another problem which is most likely what has been killing your 1bash prematurely.
By removing the unused individual powerlimit variables you have created a situation where later in 1bash those variables are undefined.
For now; don't delete unused variables.
I can add logic to check or otherwise avoid this type of problem in the future; but it is simple enough to leave the extra variables for now.
That seems to have resolved the issue.. thanks.
Jump to: