) 
Topic: [ mining os ] nvoc - page 302. (Read 418549 times)
I just copied the content of the claymore 9.7 into 9.5 folder and run the miner. So far I'm getting 190mh/s mining eth from 6 nvidia gtx 1070 as for the 9.5 - the version on the 0017 onebash I was getting 183mh/s. Thinking this is a must to be implemented as soon as possible. PS- sry for my english )
)
Claymore 9.7 is out and on my Windows10 machine I went from Dual Mining ETH: 94.5 MH/s and SC: 945 MH/s increased to ETH: 99 MH/s and SC: 990 MH/s. No other changes and exactly the same OC. We will see if it stays stable. Possible addition to v18?
I am just unable to keep my nvOC stable. It keeps hanging and locking up the OS. I am currently loading Windows 10 on my rig just to see if I have a hardware issue that I can't figure out. If Windows 10 stays stable I don't know what I will do. I REALLY like nvOC. If I had another stick of ram laying around I would stick it in. I will order one if I have to.
I am just unable to keep my nvOC stable. It keeps hanging and locking up the OS. I am currently loading Windows 10 on my rig just to see if I have a hardware issue that I can't figure out. If Windows 10 stays stable I don't know what I will do. I REALLY like nvOC. If I had another stick of ram laying around I would stick it in. I will order one if I have to.
Got my second right up and running, currently tuning the 1060's with Ethminer, genoil fork on VER0017 nvOC.
So far getting around 149MH/s total on 6 cards with these settings. Short term stability is their, long term us currently unknown.
Getting about 24.83MH/s on each.
5 cards:
PL: 125
Core: -100
Mem: 1700
1 card:
PL: 125
Core: -100
Mem: 1700
Anybody else have settings for their 1060s as I am curious to what others have gotten so far.
Besides stability for the OC, going to be stepping down the power to optimize it.
Depending on the mobo I can get 25/26 MHs per 1060 under genoil with the watchdog script with -75 and +1450 with power limit at 82W.So far getting around 149MH/s total on 6 cards with these settings. Short term stability is their, long term us currently unknown.
Getting about 24.83MH/s on each.
5 cards:
PL: 125
Core: -100
Mem: 1700
1 card:
PL: 125
Core: -100
Mem: 1700
Anybody else have settings for their 1060s as I am curious to what others have gotten so far.
Besides stability for the OC, going to be stepping down the power to optimize it.
With Claymore I was able to crank it up to 170/1700/82 and get another 1-2 MHs per card and it was relatively stable but when it did crash it did not recover without intervention so for now I'm going with Genoil and finding different ways to deal with the remaining instability (which to me means a reboot ever 1-2 days at the moment).
That is awesome to hear! I am right below the 25MH/s. With your powerlimit you suggested, I haven't gotten to but it gave me a good baseline. I was not aware the 1060's are that power efficient even under a heavy OC. My 1070s I could barely go below 115 with such heavy OC on it.
Biggest reason I want Genoil is the no fee attached to the miner compared to claymore.
What watchdog script you talking about? Or did you make it?
Got my second right up and running, currently tuning the 1060's with Ethminer, genoil fork on VER0017 nvOC.
So far getting around 149MH/s total on 6 cards with these settings. Short term stability is their, long term us currently unknown.
Getting about 24.83MH/s on each.
5 cards:
PL: 125
Core: -100
Mem: 1700
1 card:
PL: 125
Core: -100
Mem: 1700
Anybody else have settings for their 1060s as I am curious to what others have gotten so far.
Besides stability for the OC, going to be stepping down the power to optimize it.
Depending on the mobo I can get 25/26 MHs per 1060 under genoil with the watchdog script with -75 and +1450 with power limit at 82W.So far getting around 149MH/s total on 6 cards with these settings. Short term stability is their, long term us currently unknown.
Getting about 24.83MH/s on each.
5 cards:
PL: 125
Core: -100
Mem: 1700
1 card:
PL: 125
Core: -100
Mem: 1700
Anybody else have settings for their 1060s as I am curious to what others have gotten so far.
Besides stability for the OC, going to be stepping down the power to optimize it.
With Claymore I was able to crank it up to 170/1700/82 and get another 1-2 MHs per card and it was relatively stable but when it did crash it did not recover without intervention so for now I'm going with Genoil and finding different ways to deal with the remaining instability (which to me means a reboot ever 1-2 days at the moment).
Got my second right up and running, currently tuning the 1060's with Ethminer, genoil fork on VER0017 nvOC.
So far getting around 149MH/s total on 6 cards with these settings. Short term stability is their, long term us currently unknown.
Getting about 24.83MH/s on each.
5 cards:
PL: 125
Core: -100
Mem: 1700
1 card:
PL: 125
Core: -100
Mem: 1700
Anybody else have settings for their 1060s as I am curious to what others have gotten so far.
Besides stability for the OC, going to be stepping down the power to optimize it.
So far getting around 149MH/s total on 6 cards with these settings. Short term stability is their, long term us currently unknown.
Getting about 24.83MH/s on each.
5 cards:
PL: 125
Core: -100
Mem: 1700
1 card:
PL: 125
Core: -100
Mem: 1700
Anybody else have settings for their 1060s as I am curious to what others have gotten so far.
Besides stability for the OC, going to be stepping down the power to optimize it.
i'm actually dreading the 0018 release... i've made so many changes to the 0017 oneBash and nvOC in general that moving them to the new version is gonna take forever.. currently working on automatic rig reboot in the event of a system freeze from the miner crashing.
@ tempgoga - I'm curious on your approach, [... snip]
Sorry for the late response, right now i'm trying to initiate a system reboot in the event that Xorg service takes up 98% or more cpu for for 10 seconds or longer, which happens every time any miner crashes, Xorg always shoots up to 99-100% cpu and stays there, trying to use monit for this, will update if it works.
i like your port-knocking idea.
Hey monit looks nice, I'm about half way there to taking the output of genoil and turing it into a hearbeat, then to remotely cycle the server, the hard part is how to define the conditions of when to trigger that event.
i'm actually dreading the 0018 release... i've made so many changes to the 0017 oneBash and nvOC in general that moving them to the new version is gonna take forever.. currently working on automatic rig reboot in the event of a system freeze from the miner crashing.
@ tempgoga - I'm curious on your approach, this is next on my plate (without a remote power switch) the easiest - that seems applicable to my setup - is to filter the Genoil watchdog script for a reduced hash rate threshold instead of just 'error' since that script filters stdout from Genoil so technically the info is there to capture already.
I haven't gotten around to this yet but I'm hoping this weekend.
Another idea that I'm thinking of is some sort of port-knocking from a remote machine - it could be enough since the rigs usually are responsive to ssh or local scripts after they "soft crash" with the video cards - but this won't help in case of a complete freeze.
Then you need a remote power cycle ability which is a whole different level of infra.
Cheers!
Sorry for the late response, right now i'm trying to initiate a system reboot in the event that Xorg service takes up 98% or more cpu for for 10 seconds or longer, which happens every time any miner crashes, Xorg always shoots up to 99-100% cpu and stays there, trying to use monit for this, will update if it works.
i like your port-knocking idea.
I finally got my system stable with 6x 1070's after swapping mobos to an asrock z270 (the ga-z170x-ud5 th mobo i had the cards on seemed stable, but froze up and then went back to the old bootloop scenario again) - I just have one glitch that keeps creeping up. 1 gpu is only being utilized at about 66% consistently, where the rest are at 99% - overall it drops my hashrate 100 sol/s. Any clue what might cause that to happen? I'm running v. 0017.
I have had a lot of requests for this; so here is a new oneBash and modded switch file which implement full integration of SALFTER_NICEHASH_PROFIT_SWITCHING
see the OP for links:
Replace your current oneBash with the new one.
extract switch and move it to the:
directory
(the one which opens when you click the Files icon on the left)
configure the following in oneBash
remember to thank salfter if you use this
see the OP for links:
Replace your current oneBash with the new one.
extract switch and move it to the:
Code:
/home/m1
directory
(the one which opens when you click the Files icon on the left)
configure the following in oneBash
Code:
SALFTER_NICEHASH_PROFIT_SWITCHING="YES"
# LOCAL will attach the mining process to the guake terminal
# REMOTE will leave it unattached / ready for SSH
LOCALorREMOTE="LOCAL" # LOCAL or REMOTE
CURRENCY=USD
POWER_COST=0.10
MINIMUM_PROFIT=0.0
# this is salfters BTC address:
PAYMENT_ADDRESS=1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2
WORKER_NAME=nv$IP_AS_WORKER
daggerhashimoto_POWERLIMIT_WATTS=125
__daggerhashimoto_CORE_OVERCLOCK=100
daggerhashimoto_MEMORY_OVERCLOCK=100
_______daggerhashimoto_FAN_SPEED=75
equihash_POWERLIMIT_WATTS=125
__equihash_CORE_OVERCLOCK=100
equihash_MEMORY_OVERCLOCK=100
_______equihash_FAN_SPEED=75
neoscrypt_POWERLIMIT_WATTS=125
__neoscrypt_CORE_OVERCLOCK=100
neoscrypt_MEMORY_OVERCLOCK=100
_______neoscrypt_FAN_SPEED=75
lyra2rev2_POWERLIMIT_WATTS=125
__lyra2rev2_CORE_OVERCLOCK=100
lyra2rev2_MEMORY_OVERCLOCK=100
_______lyra2rev2_FAN_SPEED=75
lbry_POWERLIMIT_WATTS=125
__lbry_CORE_OVERCLOCK=100
lbry_MEMORY_OVERCLOCK=100
_______lbry_FAN_SPEED=75
pascal_POWERLIMIT_WATTS=125
__pascal_CORE_OVERCLOCK=100
pascal_MEMORY_OVERCLOCK=100
_______pascal_FAN_SPEED=75
# LOCAL will attach the mining process to the guake terminal
# REMOTE will leave it unattached / ready for SSH
LOCALorREMOTE="LOCAL" # LOCAL or REMOTE
CURRENCY=USD
POWER_COST=0.10
MINIMUM_PROFIT=0.0
# this is salfters BTC address:
PAYMENT_ADDRESS=1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2
WORKER_NAME=nv$IP_AS_WORKER
daggerhashimoto_POWERLIMIT_WATTS=125
__daggerhashimoto_CORE_OVERCLOCK=100
daggerhashimoto_MEMORY_OVERCLOCK=100
_______daggerhashimoto_FAN_SPEED=75
equihash_POWERLIMIT_WATTS=125
__equihash_CORE_OVERCLOCK=100
equihash_MEMORY_OVERCLOCK=100
_______equihash_FAN_SPEED=75
neoscrypt_POWERLIMIT_WATTS=125
__neoscrypt_CORE_OVERCLOCK=100
neoscrypt_MEMORY_OVERCLOCK=100
_______neoscrypt_FAN_SPEED=75
lyra2rev2_POWERLIMIT_WATTS=125
__lyra2rev2_CORE_OVERCLOCK=100
lyra2rev2_MEMORY_OVERCLOCK=100
_______lyra2rev2_FAN_SPEED=75
lbry_POWERLIMIT_WATTS=125
__lbry_CORE_OVERCLOCK=100
lbry_MEMORY_OVERCLOCK=100
_______lbry_FAN_SPEED=75
pascal_POWERLIMIT_WATTS=125
__pascal_CORE_OVERCLOCK=100
pascal_MEMORY_OVERCLOCK=100
_______pascal_FAN_SPEED=75
remember to thank salfter if you use this
Thanks for implementing this, but for some odd reason I keep getting two instances of the miner screen running which causes the system to crash, I will do some more testing to try and figure out what is going on.
EDIT: Actually the kill code does not seem to work causing multiple miner screens, this is how the system is crashing.
Powerstates are weird in Linux; usually don't change if you issue the command to change them. I suspect this particular driver disallows nvidia-settings control over them.
Also you will need to use a higher OC offset to match the results from windows; as the OC curve is different in linux.
It seems like the power state will not change if the miner is running since the value is locked while in use by the miner, probably because the xserver p-state setting is initialized when linux loads but the miner changes the p-state settings after that which resets the values overriding the o/s default settings. Once that's done, you have to stop the miner, reset the p-state in nvidia config panel and then run the miner again... but the problem is that oneBash changes the setting back when it loads. I've tested setting the cards individually to 'prefer max performance' in nvidia's control panel while miner is running. P-state doesn't change. As soon as the miner, is closed the p-state will go up to max settings as you'd expect.
One way I think you could avoid this is by not setting power states in oneBash, but rather set them manually in the nvidia xserver settings so they are in place before oneBash runs. I'm sure there's a way to automate the P-state through nvidia xserver config file, but I'd have to dig around to find out how precisely to do it. That also means you'd have to remove the p-state config from the oneBash options to avoid it being changed back by the miner script.
In my tests different GPUs had different levels of responsiveness to the power state cmds. Maybe the new driver will work better overall.
There is no explict power state implementation in oneBash; if it is changed it is due to internal workings of the nvidia api when either OC or powerlimit is applied. It is possible that adding power state cmds before the launching of the mining client, but after the powerlimit and OC will work.
How tricky would it be to use the nvidia-settings commands from within oneBash to run the following command recursively for each card that's detected when it runs, rather than setting a specific power limit or clock offset?
Enable PowerMizer (Prefer Maximum Performance)
nvidia-settings -a '[gpu:0]/GPUPowerMizerMode=1'
essentially this, but with more efficient code because I never was good at foreach loops and such...
if [ $POWERLIMIT == "NO" ]
then
sudo nvidia-settings -a '[gpu:0]/GPUPowerMizerMode=1'
sudo nvidia-settings -a '[gpu:1]/GPUPowerMizerMode=1'
sudo nvidia-settings -a '[gpu:2]/GPUPowerMizerMode=1'
sudo nvidia-settings -a '[gpu:3]/GPUPowerMizerMode=1'
sudo nvidia-settings -a '[gpu:4]/GPUPowerMizerMode=1'
sudo nvidia-settings -a '[gpu:5]/GPUPowerMizerMode=1'
fi
On a side note, I updated to the most recent nvidia open source drivers (v. 381) and now my 1080 ti is recognized, so that's a plus. Before it just listed as 'graphical device'
your xorg.conf is most likely the problem
I would try re imaging a USB; although depending on your version you might not need to: what version are you using?
Also I don't recommend using dd to image USBs or SSDs; use etcher for linux instead.
I would try re imaging a USB; although depending on your version you might not need to: what version are you using?
Also I don't recommend using dd to image USBs or SSDs; use etcher for linux instead.
Tried using hdd raw copy on win machine and etcher - same issue.
Tried burning the image on SSD and USB - same.
Using v0017 and latest oneBash
Could anyone provide me their xorg.conf which works with fan speed changing?
Thanks
Powerstates are weird in Linux; usually don't change if you issue the command to change them. I suspect this particular driver disallows nvidia-settings control over them.
Also you will need to use a higher OC offset to match the results from windows; as the OC curve is different in linux.
It seems like the power state will not change if the miner is running since the value is locked while in use by the miner, probably because the xserver p-state setting is initialized when linux loads but the miner changes the p-state settings after that which resets the values overriding the o/s default settings. Once that's done, you have to stop the miner, reset the p-state in nvidia config panel and then run the miner again... but the problem is that oneBash changes the setting back when it loads. I've tested setting the cards individually to 'prefer max performance' in nvidia's control panel while miner is running. P-state doesn't change. As soon as the miner, is closed the p-state will go up to max settings as you'd expect.
One way I think you could avoid this is by not setting power states in oneBash, but rather set them manually in the nvidia xserver settings so they are in place before oneBash runs. I'm sure there's a way to automate the P-state through nvidia xserver config file, but I'd have to dig around to find out how precisely to do it. That also means you'd have to remove the p-state config from the oneBash options to avoid it being changed back by the miner script.
I can't even get the bios to post. I swapped all the parts minus the mobo from bad rig to good rig, and they worked fine. so i'm guessing I have my answer
This may have been suggested before, but I'm lazy and don't like to read so I'll just toss this out there and take the heat later.
Have you tried adding power to an ATX4P connection on the motherboard (or molex 4 pin connector if it has one) to supply additional power to the PCIe connections? Even if the risers are separately powered, sometimes the board can't produce enough juice to the PCIe slots to support GPUs in all 6 positions.
I have a Gigabyte Z170x-UD5 TH mobo that had that bootloop issue that drove me nuts for a few days straight. It wouldn't run more than 5 cards when there are 6 slots (that was with all gtx 1070s) so I finally discovered the purpose of the ATX4P connector and added a SATA power cable to the board and now it boots fine with 5 1070s on risers and a 1080ti in the last onboard slot.
Sorry if this is redundant info.
I'm only running 3 cards so idk if that is super applicable but if nothing else works I'll see if that helps. Thanks for the suggestion
I can't even get the bios to post. I swapped all the parts minus the mobo from bad rig to good rig, and they worked fine. so i'm guessing I have my answer
This may have been suggested before, but I'm lazy and don't like to read so I'll just toss this out there and take the heat later.
Have you tried adding power to an ATX4P connection on the motherboard (or molex 4 pin connector if it has one) to supply additional power to the PCIe connections? Even if the risers are separately powered, sometimes the board can't produce enough juice to the PCIe slots to support GPUs in all 6 positions.
I have a Gigabyte Z170x-UD5 TH mobo that had that bootloop issue that drove me nuts for a few days straight. It wouldn't run more than 5 cards when there are 6 slots (that was with all gtx 1070s) so I finally discovered the purpose of the ATX4P connector and added a SATA power cable to the board and now it boots fine with 5 1070s on risers and a 1080ti in the last onboard slot.
Sorry if this is redundant info.
So new build, similar problem to the first rig I built myself. Getting the never ending "bootloop" when I fire up my mobo with everything plugged in. I know everyone says to unplug everything and try it one part at a time, which i will indeed do, but I was wondering if anyone else had this issue and found a more uniform way to fix it? Last time it was because my RAM was loose. This time my connections are all secure.
Background: building a trio rig with 2 1080ti and a 1080 mini using a 270 mobo with 850w psu. First mobo I used for this build didn't work at all. This one fires up but then goes into the endless loop. I have tried a different psu and a different RAM as well as different GPU. Leaning towards it being a faulty cpu but curious to see if anyone else has any other suggestions before I dismantle everything.
Background: building a trio rig with 2 1080ti and a 1080 mini using a 270 mobo with 850w psu. First mobo I used for this build didn't work at all. This one fires up but then goes into the endless loop. I have tried a different psu and a different RAM as well as different GPU. Leaning towards it being a faulty cpu but curious to see if anyone else has any other suggestions before I dismantle everything.
CPUs are almost never bad; sometimes you can have a bent mobo pin that causes CPU related problems. However, I don't think that is the case here.
Maybe this will work:
Ensure the monitor is connected to the primary GPU ( the one in the 16x slot closest to the CPU )
Disconnect the USB or SSD/HHD from the rig.
Fully power off everything: including the PSU.
Press the power button several times to clear any remaining power in the mobo.
Turn the PSU powerswitch back to | "on".
power on (without the USB attached)
See if the bios posts; if you get nothing in 20 seconds; press ctrl + alt + del repeatedly until the system reboots.
Wait and see if the bios posts.
If the bios posts attach the USB key and press ctrl + alt + delete.
Let me know if this works.
Thanks a ton, will give it a shot. And if this doesn't work? Just break everything?
If this doesn't work I would try reimaging the USB key. (first ensure your downloaded zip produces the correct hash)
What kind of USB key are you using btw?
I've tried using the one that is on my working rig (same exact setup) and it didn't make a difference. Both USBs are Lexar JumpDrive S75 32GB
I would try swapping out the risers first; if you are using risers. If you have an identical setup that works with the same USB; then it is almost for sure a hardware problem.
Are the bios settings and version the same on the working and trouble rig?
I can't even get the bios to post. I swapped all the parts minus the mobo from bad rig to good rig, and they worked fine. so i'm guessing I have my answer
So new build, similar problem to the first rig I built myself. Getting the never ending "bootloop" when I fire up my mobo with everything plugged in. I know everyone says to unplug everything and try it one part at a time, which i will indeed do, but I was wondering if anyone else had this issue and found a more uniform way to fix it? Last time it was because my RAM was loose. This time my connections are all secure.
Background: building a trio rig with 2 1080ti and a 1080 mini using a 270 mobo with 850w psu. First mobo I used for this build didn't work at all. This one fires up but then goes into the endless loop. I have tried a different psu and a different RAM as well as different GPU. Leaning towards it being a faulty cpu but curious to see if anyone else has any other suggestions before I dismantle everything.
Background: building a trio rig with 2 1080ti and a 1080 mini using a 270 mobo with 850w psu. First mobo I used for this build didn't work at all. This one fires up but then goes into the endless loop. I have tried a different psu and a different RAM as well as different GPU. Leaning towards it being a faulty cpu but curious to see if anyone else has any other suggestions before I dismantle everything.
CPUs are almost never bad; sometimes you can have a bent mobo pin that causes CPU related problems. However, I don't think that is the case here.
Maybe this will work:
Ensure the monitor is connected to the primary GPU ( the one in the 16x slot closest to the CPU )
Disconnect the USB or SSD/HHD from the rig.
Fully power off everything: including the PSU.
Press the power button several times to clear any remaining power in the mobo.
Turn the PSU powerswitch back to | "on".
power on (without the USB attached)
See if the bios posts; if you get nothing in 20 seconds; press ctrl + alt + del repeatedly until the system reboots.
Wait and see if the bios posts.
If the bios posts attach the USB key and press ctrl + alt + delete.
Let me know if this works.
Thanks a ton, will give it a shot. And if this doesn't work? Just break everything?
If this doesn't work I would try reimaging the USB key. (first ensure your downloaded zip produces the correct hash)
What kind of USB key are you using btw?
I've tried using the one that is on my working rig (same exact setup) and it didn't make a difference. Both USBs are Lexar JumpDrive S75 32GB
i'm actually dreading the 0018 release... i've made so many changes to the 0017 oneBash and nvOC in general that moving them to the new version is gonna take forever.. currently working on automatic rig reboot in the event of a system freeze from the miner crashing.
@ tempgoga - I'm curious on your approach, this is next on my plate (without a remote power switch) the easiest - that seems applicable to my setup - is to filter the Genoil watchdog script for a reduced hash rate threshold instead of just 'error' since that script filters stdout from Genoil so technically the info is there to capture already.
I haven't gotten around to this yet but I'm hoping this weekend.
Another idea that I'm thinking of is some sort of port-knocking from a remote machine - it could be enough since the rigs usually are responsive to ssh or local scripts after they "soft crash" with the video cards - but this won't help in case of a complete freeze.
Then you need a remote power cycle ability which is a whole different level of infra.
Cheers!
Hi. I cannot get Genoil to work on NiceHash.
Been trying for about an hour and finally gave up
After Genoil starts I immediately get an error about invalid argument and then it shows my BTC address.
I made a million changes to the oneBash line concerning NICE_ETHASH. Here is my latest (NOT WORKING)
My assumption is that this version of Genoil is not compatible with NH (I read somewhere NH made their own fork)
If I am wrong (hope so) please assist
Thanks
# NICE autoconverts to BTC: ensure you update BTC_ADDRESS if you use NICE
NICE_ETHASH_WORKER="nv$IP_AS_WORKER"
NICE_POOL="stratum+tcp://daggerhashimoto.usa.nicehash.com:3353"
GENOIL_NICE_POOL="daggerhashimoto.usa.nicehash.com:3353"
NICE_EXTENTION_ARGUMENTS=""
if [ $COIN == "NICE_ETHASH" ]
then
if [ $GENOILorCLAYMORE == "GENOIL" ]
then
HCD='/home/m1/eth/Genoil-U/ethminer'
NICEADDR="$BTC_ADDRESS"
WORKER="$NICE_ETHASH_WORKER"
until $HCD -SP 2 -U -S $GENOIL_NICE_ETHASH_POOL -O $NICEADDR.$WORKER:x
do
echo "FAILURE; reinit in 5" >&2
sleep 5
done
fi
Been trying for about an hour and finally gave up
After Genoil starts I immediately get an error about invalid argument and then it shows my BTC address.
I made a million changes to the oneBash line concerning NICE_ETHASH. Here is my latest (NOT WORKING)
My assumption is that this version of Genoil is not compatible with NH (I read somewhere NH made their own fork)
If I am wrong (hope so) please assist
Thanks
# NICE autoconverts to BTC: ensure you update BTC_ADDRESS if you use NICE
NICE_ETHASH_WORKER="nv$IP_AS_WORKER"
NICE_POOL="stratum+tcp://daggerhashimoto.usa.nicehash.com:3353"
GENOIL_NICE_POOL="daggerhashimoto.usa.nicehash.com:3353"
NICE_EXTENTION_ARGUMENTS=""
if [ $COIN == "NICE_ETHASH" ]
then
if [ $GENOILorCLAYMORE == "GENOIL" ]
then
HCD='/home/m1/eth/Genoil-U/ethminer'
NICEADDR="$BTC_ADDRESS"
WORKER="$NICE_ETHASH_WORKER"
until $HCD -SP 2 -U -S $GENOIL_NICE_ETHASH_POOL -O $NICEADDR.$WORKER:x
do
echo "FAILURE; reinit in 5" >&2
sleep 5
done
fi
Really looking forward to all the new features slated for nvOC 0018. I tried implementing the nicehash profit switching from @salfter but it was a little beyond my Linux skills.
Any idea when we might see it released?
Any idea when we might see it released?
i'm actually dreading the 0018 release... i've made so many changes to the 0017 oneBash and nvOC in general that moving them to the new version is gonna take forever.. currently working on automatic rig reboot in the event of a system freeze from the miner crashing.
Really looking forward to all the new features slated for nvOC 0018. I tried implementing the nicehash profit switching from @salfter but it was a little beyond my Linux skills.
Any idea when we might see it released?
Any idea when we might see it released?
Jump to: