leenoox
|
|
December 11, 2017, 08:19:49 PM |
|
Can you try REMOTE again with the watchdog turned off? MINER_WATCHDOG="NO" # YES or NO # Monitors the rig and automatically corrects the detected problems. Highly recommended to use this!
This will help determine if the watchdog is somehow killing plusCPU. Switch back to REMOTE and set WATCHDOG = "NO". Here are the events upon a reboot: Last login: Mon Dec 11 14:09:26 2017 from 10.0.1.212 m1@miner06:~$ screen -ls There is a screen on: 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2076.temp (12/11/2017 03:12:07 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2076.temp (12/11/2017 03:12:06 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:09 PM) (Detached) 2076.temp (12/11/2017 03:12:06 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:10 PM) (Detached) 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:10 PM) (Detached) 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:10 PM) (Detached) 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:09 PM) (Detached) 2076.temp (12/11/2017 03:12:06 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$
So it appears that watchdog is NOT what kills the plusCPU miner. I'll fix this later...still at work... at a quick look it seems like the command to execute miner for REMOTE has some extra arguments... pap if you have time you can check this... if not i'll check it tonight
|
|
|
|
papampi
Full Member
Offline
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
|
|
December 11, 2017, 08:37:17 PM |
|
Can you try REMOTE again with the watchdog turned off? MINER_WATCHDOG="NO" # YES or NO # Monitors the rig and automatically corrects the detected problems. Highly recommended to use this!
This will help determine if the watchdog is somehow killing plusCPU. Switch back to REMOTE and set WATCHDOG = "NO". Here are the events upon a reboot: Last login: Mon Dec 11 14:09:26 2017 from 10.0.1.212 m1@miner06:~$ screen -ls There is a screen on: 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2076.temp (12/11/2017 03:12:07 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2076.temp (12/11/2017 03:12:06 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:09 PM) (Detached) 2076.temp (12/11/2017 03:12:06 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:10 PM) (Detached) 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:10 PM) (Detached) 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:10 PM) (Detached) 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:09 PM) (Detached) 2076.temp (12/11/2017 03:12:06 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$
So it appears that watchdog is NOT what kills the plusCPU miner. I'll fix this later...still at work... at a quick look it seems like the command to execute miner for REMOTE has some extra arguments... pap if you have time you can check this... if not i'll check it tonight I dont see any extra .. do you ? if [ $LOCALorREMOTE == "LOCAL" ] then guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT" else screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT fi
|
|
|
|
Stubo
Member
Offline
Activity: 224
Merit: 13
|
|
December 11, 2017, 08:44:20 PM |
|
Can you try REMOTE again with the watchdog turned off? MINER_WATCHDOG="NO" # YES or NO # Monitors the rig and automatically corrects the detected problems. Highly recommended to use this!
This will help determine if the watchdog is somehow killing plusCPU. Switch back to REMOTE and set WATCHDOG = "NO". Here are the events upon a reboot: Last login: Mon Dec 11 14:09:26 2017 from 10.0.1.212 m1@miner06:~$ screen -ls There is a screen on: 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2076.temp (12/11/2017 03:12:07 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2076.temp (12/11/2017 03:12:06 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:09 PM) (Detached) 2076.temp (12/11/2017 03:12:06 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:10 PM) (Detached) 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:10 PM) (Detached) 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:10 PM) (Detached) 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:09 PM) (Detached) 2076.temp (12/11/2017 03:12:06 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$
So it appears that watchdog is NOT what kills the plusCPU miner. I'll fix this later...still at work... at a quick look it seems like the command to execute miner for REMOTE has some extra arguments... pap if you have time you can check this... if not i'll check it tonight I think I may have found another problem we haven't even seen yet because of the existing one. In 3main, there is this if statement that determines if 0main is to be executed: running=$(ps ax | grep -i screen | grep miner | awk '"miner" {print $1}') if [ "$running" == "" ] then if [ $LOCALorREMOTE == "REMOTE" ] then bash /home/m1/0miner
So if plusCPU was running when it gets to this point in the code [that launches 0miner], $running would be set to the PID of the plusCPU miner (cpuminer) and if we are REMOTE (grep -i screen). The IF following that code would not launch 0miner. Eventually, if the watchdog was running, it would see low GPU utilization and attempt to launch 3main again, and again. So I think that running line should exclude cpuminer. Something like this: running=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}')
|
|
|
|
papampi
Full Member
Offline
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
|
|
December 11, 2017, 09:07:57 PM |
|
Can you try REMOTE again with the watchdog turned off? MINER_WATCHDOG="NO" # YES or NO # Monitors the rig and automatically corrects the detected problems. Highly recommended to use this!
This will help determine if the watchdog is somehow killing plusCPU. Switched back to REMOTE and set WATCHDOG = "NO". Here are the events upon a reboot: Last login: Mon Dec 11 14:09:26 2017 from 10.0.1.212 m1@miner06:~$ screen -ls There is a screen on: 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2044.plusCPU (12/11/2017 03:12:03 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2076.temp (12/11/2017 03:12:07 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There is a screen on: 2076.temp (12/11/2017 03:12:06 PM) (Detached) 1 Socket in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:09 PM) (Detached) 2076.temp (12/11/2017 03:12:06 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:10 PM) (Detached) 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:10 PM) (Detached) 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:10 PM) (Detached) 2076.temp (12/11/2017 03:12:07 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$ screen -ls There are screens on: 2186.miner (12/11/2017 03:12:09 PM) (Detached) 2076.temp (12/11/2017 03:12:06 PM) (Detached) 2 Sockets in /var/run/screen/S-m1. m1@miner06:~$
So it appears that watchdog is NOT what kills the plusCPU miner. Replace the complete XMR part in 3main with this and test : if [ $plusCPU == "YES" ] && [ $AUTO_START_MINER == "YES" ] then HCD='/home/m1/cpuOPT/cpuminer' XMRADDR="$XMR_ADDRESS.$XMR_WORKER" running=$(ps -ef | awk '$NF~"cpuminer" {print $2}') echo "" echo "" echo "LAUNCHING: plusCPU" if [ "$running" == "" ] then guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT" echo "" echo "plusCPU process in guake terminal Tab (f12)" echo "" running="" fi fi
|
|
|
|
Stubo
Member
Offline
Activity: 224
Merit: 13
|
|
December 11, 2017, 09:08:04 PM |
|
I should have read up just a tick. There is another $running and the kill that is killing the plusCPU miner: reup=0 # running=$(ps ax | grep -i screen | grep miner | awk '"miner" {print $1}') running=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}')
if [ "$running" != "" ] then # target=$(ps ax | grep -i screen | grep miner | awk '"miner" {print $1}') target=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}') kill $target reup=1 fi sleep 2 echo "" echo "LAUNCHING: MINER" echo " " # running=$(ps ax | grep -i screen | grep miner | awk '"miner" {print $1}') running=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}') if [ "$running" == "" ] then if [ $LOCALorREMOTE == "REMOTE" ]
I commented out the originals and put in modified ones below them.
|
|
|
|
hash3r
Newbie
Offline
Activity: 10
Merit: 0
|
|
December 11, 2017, 09:24:05 PM |
|
insert in 1bash before TEAMVIEWER="NO" # YES NO this: xrandr --fb 1024x768 (or whatever resolution do you need)
works for both Teamviwer and VNC
perfect! you can also just run the command from guake to change on the fly. Working great with VNC, any way we can get this implemented in the next update?
|
|
|
|
Zotix
Newbie
Offline
Activity: 1
Merit: 0
|
|
December 11, 2017, 09:30:51 PM |
|
Hello all,
I am trying to duel mine ethereum and pascal on nanopool with the email setting. I have a few machines and the email setting works fine for solo mining Ethereum and it even works with fine for duel mining on the ethereum pool, but when I try to use the email to change payout or provide public key for the pascal pool, it does not work. I have a feeling it has to do with the way pascal uses a "." in the address line, or possible the fact that I'm mining to a Poloniex account. Is there any way that I can get the pascal pool to read the email so I can make changes to payout and public key?
Here are my 1bash settings for pascal (edited for privacy):
PASC_WORKER="Workername/myemail@mail.com" PASC_ADDRESS="1235-12.123456abvd" PASC_POOL="pasc-us-wast1.nanopool.org:15555"
|
|
|
|
crazydane
|
|
December 11, 2017, 09:32:36 PM |
|
I should have read up just a tick. There is another $running and the kill that is killing the plusCPU miner: reup=0 # running=$(ps ax | grep -i screen | grep miner | awk '"miner" {print $1}') running=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}')
if [ "$running" != "" ] then # target=$(ps ax | grep -i screen | grep miner | awk '"miner" {print $1}') target=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}') kill $target reup=1 fi sleep 2 echo "" echo "LAUNCHING: MINER" echo " " # running=$(ps ax | grep -i screen | grep miner | awk '"miner" {print $1}') running=$(ps ax | grep -v cpuminer | grep -i screen | grep miner | awk '"miner" {print $1}') if [ "$running" == "" ] then if [ $LOCALorREMOTE == "REMOTE" ]
I commented out the originals and put in modified ones below them. That did the trick! I'm back to REMOTE and plusCPU starts, followed by the GPU miner and both are running happily now.
|
|
|
|
crazydane
|
|
December 11, 2017, 09:34:21 PM |
|
Replace the complete XMR part in 3main with this and test :
I tried Stubo's fix first and that took care of it. If you still want to be to test the new XMR section, let me know.
|
|
|
|
CryptAtomeTrader44
Full Member
Offline
Activity: 340
Merit: 103
It is easier to break an atom than partialities AE
|
|
December 12, 2017, 12:12:46 AM |
|
News from nicehash : "Q: What’s the likelihood of the company covering more than $60m in losses? Are you able to compensate users? A: We fully intend to make this right. It’s a matter of deep concern to us and we’re working hard to rectify the matter in the coming days. We’re working on a solution to ensure that all users are reimbursed. These things are delicate matters, and take time, so we would ask our community to be patient while we get this fixed and fully investigated. As soon as we have a full plan in place we will communicate it to our users and all those affected." https://www.wikitribune.com/story/2017/12/11/technology/nicehash-ceo-speaks-out-after-60m-cryptocurrency-hack/27212/Don't want to make their communication, but we'll see... Wait&See
|
|
|
|
Neiheisel
Newbie
Offline
Activity: 5
Merit: 0
|
|
December 12, 2017, 01:09:13 AM |
|
Anyone tried updating to the new version of xmr-stak with nvOC?
|
|
|
|
leenoox
|
|
December 12, 2017, 01:45:20 AM |
|
Hello all,
I am trying to duel mine ethereum and pascal on nanopool with the email setting. I have a few machines and the email setting works fine for solo mining Ethereum and it even works with fine for duel mining on the ethereum pool, but when I try to use the email to change payout or provide public key for the pascal pool, it does not work. I have a feeling it has to do with the way pascal uses a "." in the address line, or possible the fact that I'm mining to a Poloniex account. Is there any way that I can get the pascal pool to read the email so I can make changes to payout and public key?
Here are my 1bash settings for pascal (edited for privacy):
PASC_WORKER="Workername/myemail@mail.com" PASC_ADDRESS="1235-12.123456abvd" PASC_POOL="pasc-us-wast1.nanopool.org:15555"
Not sure about the email settings, maybe someone that has done this can help you but I noticed you have typo in the pool address, wast1 should be west1
|
|
|
|
wi$em@n
Newbie
Offline
Activity: 46
Merit: 0
|
|
December 12, 2017, 02:53:33 AM |
|
on 1.4 everything worked OK. after update I have:
1. current version: ########################################################################## ########################################################################## ################# nvOC v0019-2.0 - Community Release ################# ############## by papampi, Stubo and leenoox ############## ########## Based on the original nvOC v0019-1.4 by fullzero ########## ########################################################################## ##########################################################################
nvOC_1bash_ver="v0019-2.0.001" # Do not edit this
2. Auto temp is OFF, because it reboots rig immediately
3. Wdog starts, but have to ctrl+c, otherwise it restarts miner and after that restarts rig:
Mon Dec 11 19:35:50 MST 2017 - Watchdog is starting
Mon Dec 11 19:35:52 MST 2017 - Miner is running, waiting 70 seconds before going 'on watch'
GPU UTILIZATION: 100 100 100 100 100 100
GPU_COUNT: 6
Mon Dec 11 19:37:02 MST 2017 - Lost GPU so restarting system. Found GPU's:
pci.bus_id
00000000:01:00.0
00000000:02:00.0
00000000:03:00.0
00000000:04:00.0
00000000:05:00.0
00000000:06:00.0
Mon Dec 11 19:37:02 MST 2017 - reboot in 10 seconds
4. If I ctrl+c wdog, than miner continues working as if nothing happened:
2017-12-11 07:35:51 PM|# zm 0.5.6
2017-12-11 07:35:51 PM|# GPU0 + GeForce GTX 1050 Ti MB: 4037 PCI: 1:0
2017-12-11 07:35:51 PM|# GPU1 + GeForce GTX 1050 Ti MB: 4038 PCI: 2:0
2017-12-11 07:35:51 PM|# GPU2 + GeForce GTX 1050 Ti MB: 4038 PCI: 3:0
2017-12-11 07:35:51 PM|# GPU3 + GeForce GTX 1050 Ti MB: 4038 PCI: 4:0
2017-12-11 07:35:51 PM|# GPU4 + GeForce GTX 1050 Ti MB: 4038 PCI: 5:0
2017-12-11 07:35:51 PM|# GPU5 + GeForce GTX 1050 Ti MB: 4038 PCI: 6:0
2017-12-11 07:35:51 PM|
2017-12-11 07:35:51 PM|# GPU0 connected to: btg.suprnova.cc:8816
2017-12-11 07:35:53 PM|# GPU1 connected to: btg.suprnova.cc:8816
2017-12-11 07:35:55 PM|# GPU2 connected to: btg.suprnova.cc:8816
2017-12-11 07:35:57 PM|# GPU3 connected to: btg.suprnova.cc:8816
2017-12-11 07:35:59 PM|# GPU4 connected to: btg.suprnova.cc:8816
2017-12-11 07:36:01 PM|# GPU5 connected to: btg.suprnova.cc:8816
2017-12-11 07:36:03 PM|# GPU0 server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-11 07:36:05 PM|# GPU1 server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-11 07:36:07 PM|# GPU2 server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-11 07:36:09 PM|# GPU3 server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-11 07:36:11 PM|# GPU4 server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-11 07:36:13 PM|# GPU5 server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-11 07:36:27 PM|> GPU1 47C Sol/s: 190.3 Sol/W: inf Avg: 190.3 I/s: 103.0 Sh: 2.97 1.00 115 +
2017-12-11 07:36:27 PM|> GPU0 49C Sol/s: 191.6 Sol/W: inf Avg: 191.6 I/s: 100.8 Sh: 5.90 1.00 123 ++
2017-12-11 07:36:28 PM|> GPU2 46C Sol/s: 192.9 Sol/W: inf Avg: 192.9 I/s: 102.0 Sh: 2.99 1.00 112 +
2017-12-11 07:36:30 PM|> GPU3 53C Sol/s: 189.2 Sol/W: inf Avg: 189.2 I/s: 102.6 Sh: 0.00 . .
2017-12-11 07:36:32 PM|> GPU4 52C Sol/s: 188.7 Sol/W: inf Avg: 188.7 I/s: 102.2 Sh: 0.00 . .
2017-12-11 07:36:34 PM|> GPU5 53C Sol/s: 196.6 Sol/W: inf Avg: 196.6 I/s: 102.7 Sh: 0.00 . .
2017-12-11 07:36:34 PM| ========== Sol/s: 1149.5 Sol/W: inf Avg: 1149.5 I/s: 613.3 Sh: 11.86 1.00 116
2017-12-11 07:36:48 PM|> GPU1 52C Sol/s: 184.6 Sol/W: inf Avg: 187.5 I/s: 101.1 Sh: 2.97 1.00 117 +
2017-12-11 07:36:48 PM|> GPU0 54C Sol/s: 186.8 Sol/W: inf Avg: 189.2 I/s: 100.0 Sh: 4.44 1.00 124 +
2017-12-11 07:36:48 PM|> GPU2 52C Sol/s: 182.0 Sol/W: inf Avg: 187.4 I/s: 100.3 Sh: 4.43 1.00 109 ++
2017-12-11 07:36:50 PM|> GPU3 57C Sol/s: 195.3 Sol/W: inf Avg: 192.3 I/s: 100.8 Sh: 0.00 . .
2017-12-11 07:36:52 PM|> GPU4 57C Sol/s: 187.0 Sol/W: inf Avg: 187.8 I/s: 100.6 Sh: 1.47 1.00 109 +
2017-12-11 07:36:54 PM|> GPU5 59C Sol/s: 192.0 Sol/W: inf Avg: 194.3 I/s: 101.0 Sh: 5.92 1.00 125 ++++
2017-12-11 07:36:54 PM| ========== Sol/s: 1127.7 Sol/W: inf Avg: 1138.6 I/s: 603.8 Sh: 19.23 1.00 116
and so on...
|
|
|
|
mikespax
|
|
December 12, 2017, 02:55:59 AM |
|
Hi, I'm here shilling for the Discord server that essentially has their own fork of nvOC separate from what's going on in this thread. https://discord.gg/A22B5MbDude says he's going to get 19 cards working on NeoScrypt, so that's what I'm here for.
|
Bitrated user: mikespax.
|
|
|
papampi
Full Member
Offline
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
|
|
December 12, 2017, 08:15:14 AM |
|
on 1.4 everything worked OK. after update I have:
1. current version: ########################################################################## ########################################################################## ################# nvOC v0019-2.0 - Community Release ################# ############## by papampi, Stubo and leenoox ############## ########## Based on the original nvOC v0019-1.4 by fullzero ########## ########################################################################## ##########################################################################
nvOC_1bash_ver="v0019-2.0.001" # Do not edit this
2. Auto temp is OFF, because it reboots rig immediately
3. Wdog starts, but have to ctrl+c, otherwise it restarts miner and after that restarts rig:
Mon Dec 11 19:35:50 MST 2017 - Watchdog is starting
Mon Dec 11 19:35:52 MST 2017 - Miner is running, waiting 70 seconds before going 'on watch'
GPU UTILIZATION: 100 100 100 100 100 100
GPU_COUNT: 6
Mon Dec 11 19:37:02 MST 2017 - Lost GPU so restarting system. Found GPU's:
pci.bus_id
00000000:01:00.0
00000000:02:00.0
00000000:03:00.0
00000000:04:00.0
00000000:05:00.0
00000000:06:00.0
Mon Dec 11 19:37:02 MST 2017 - reboot in 10 seconds
4. If I ctrl+c wdog, than miner continues working as if nothing happened:
2017-12-11 07:35:51 PM|# zm 0.5.6
2017-12-11 07:35:51 PM|# GPU0 + GeForce GTX 1050 Ti MB: 4037 PCI: 1:0
2017-12-11 07:35:51 PM|# GPU1 + GeForce GTX 1050 Ti MB: 4038 PCI: 2:0
2017-12-11 07:35:51 PM|# GPU2 + GeForce GTX 1050 Ti MB: 4038 PCI: 3:0
2017-12-11 07:35:51 PM|# GPU3 + GeForce GTX 1050 Ti MB: 4038 PCI: 4:0
2017-12-11 07:35:51 PM|# GPU4 + GeForce GTX 1050 Ti MB: 4038 PCI: 5:0
2017-12-11 07:35:51 PM|# GPU5 + GeForce GTX 1050 Ti MB: 4038 PCI: 6:0
2017-12-11 07:35:51 PM|
2017-12-11 07:35:51 PM|# GPU0 connected to: btg.suprnova.cc:8816
2017-12-11 07:35:53 PM|# GPU1 connected to: btg.suprnova.cc:8816
2017-12-11 07:35:55 PM|# GPU2 connected to: btg.suprnova.cc:8816
2017-12-11 07:35:57 PM|# GPU3 connected to: btg.suprnova.cc:8816
2017-12-11 07:35:59 PM|# GPU4 connected to: btg.suprnova.cc:8816
2017-12-11 07:36:01 PM|# GPU5 connected to: btg.suprnova.cc:8816
2017-12-11 07:36:03 PM|# GPU0 server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-11 07:36:05 PM|# GPU1 server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-11 07:36:07 PM|# GPU2 server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-11 07:36:09 PM|# GPU3 server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-11 07:36:11 PM|# GPU4 server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-11 07:36:13 PM|# GPU5 server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2017-12-11 07:36:27 PM|> GPU1 47C Sol/s: 190.3 Sol/W: inf Avg: 190.3 I/s: 103.0 Sh: 2.97 1.00 115 +
2017-12-11 07:36:27 PM|> GPU0 49C Sol/s: 191.6 Sol/W: inf Avg: 191.6 I/s: 100.8 Sh: 5.90 1.00 123 ++
2017-12-11 07:36:28 PM|> GPU2 46C Sol/s: 192.9 Sol/W: inf Avg: 192.9 I/s: 102.0 Sh: 2.99 1.00 112 +
2017-12-11 07:36:30 PM|> GPU3 53C Sol/s: 189.2 Sol/W: inf Avg: 189.2 I/s: 102.6 Sh: 0.00 . .
2017-12-11 07:36:32 PM|> GPU4 52C Sol/s: 188.7 Sol/W: inf Avg: 188.7 I/s: 102.2 Sh: 0.00 . .
2017-12-11 07:36:34 PM|> GPU5 53C Sol/s: 196.6 Sol/W: inf Avg: 196.6 I/s: 102.7 Sh: 0.00 . .
2017-12-11 07:36:34 PM| ========== Sol/s: 1149.5 Sol/W: inf Avg: 1149.5 I/s: 613.3 Sh: 11.86 1.00 116
2017-12-11 07:36:48 PM|> GPU1 52C Sol/s: 184.6 Sol/W: inf Avg: 187.5 I/s: 101.1 Sh: 2.97 1.00 117 +
2017-12-11 07:36:48 PM|> GPU0 54C Sol/s: 186.8 Sol/W: inf Avg: 189.2 I/s: 100.0 Sh: 4.44 1.00 124 +
2017-12-11 07:36:48 PM|> GPU2 52C Sol/s: 182.0 Sol/W: inf Avg: 187.4 I/s: 100.3 Sh: 4.43 1.00 109 ++
2017-12-11 07:36:50 PM|> GPU3 57C Sol/s: 195.3 Sol/W: inf Avg: 192.3 I/s: 100.8 Sh: 0.00 . .
2017-12-11 07:36:52 PM|> GPU4 57C Sol/s: 187.0 Sol/W: inf Avg: 187.8 I/s: 100.6 Sh: 1.47 1.00 109 +
2017-12-11 07:36:54 PM|> GPU5 59C Sol/s: 192.0 Sol/W: inf Avg: 194.3 I/s: 101.0 Sh: 5.92 1.00 125 ++++
2017-12-11 07:36:54 PM| ========== Sol/s: 1127.7 Sol/W: inf Avg: 1138.6 I/s: 603.8 Sh: 19.23 1.00 116
and so on...
I think leenoox solved 1050 ti Open 5watchdog and check if you have v0009 # v=0009 : leenoox: Workaround for some 1050's reporting "Unknown" or "ERR" when power.draw is queried from nvidi-smi if not update to latest by running the latest update script again
|
|
|
|
leenoox
|
|
December 12, 2017, 09:05:47 AM |
|
Hi, I'm here shilling for the Discord server that essentially has their own fork of nvOC separate from what's going on in this thread. https://discord.gg/A22B5MbDude says he's going to get 19 cards working on NeoScrypt, so that's what I'm here for. Which coin and which miner are you using? Does the, whatever miner you are using, actually support 19 cards? If you have seen reports somewhere on the web that xxx miner works with 19 cards we can definetely make it work in nvOC. LMK
|
|
|
|
leenoox
|
|
December 12, 2017, 09:14:59 AM |
|
on 1.4 everything worked OK. after update I have:
1. current version:
nvOC_1bash_ver="v0019-2.0.001" # Do not edit this
2. Auto temp is OFF, because it reboots rig immediately
3. Wdog starts, but have to ctrl+c, otherwise it restarts miner and after that restarts rig:
Mon Dec 11 19:37:02 MST 2017 - reboot in 10 seconds
4. If I ctrl+c wdog, than miner continues working as if nothing happened:
2017-12-11 07:35:51 PM|# zm 0.5.6
2017-12-11 07:35:51 PM|# GPU0 + GeForce GTX 1050 Ti MB: 4037 PCI: 1:0
2017-12-11 07:35:51 PM|# GPU1 + GeForce GTX 1050 Ti MB: 4038 PCI: 2:0
2017-12-11 07:35:51 PM|# GPU2 + GeForce GTX 1050 Ti MB: 4038 PCI: 3:0
2017-12-11 07:35:51 PM|# GPU3 + GeForce GTX 1050 Ti MB: 4038 PCI: 4:0
2017-12-11 07:35:51 PM|# GPU4 + GeForce GTX 1050 Ti MB: 4038 PCI: 5:0
2017-12-11 07:35:51 PM|# GPU5 + GeForce GTX 1050 Ti MB: 4038 PCI: 6:0
I think leenoox solved 1050 ti Open 5watchdog and check if you have v0009 # v=0009 : leenoox: Workaround for some 1050's reporting "Unknown" or "ERR" when power.draw is queried from nvidi-smi if not update to latest by running the latest update script again Can you update to the latest version as papampi suggested and post if it's working after the update. If not I will revisit this again. Also please post the output from and version of 5watchdog and 6tempcontrol Thanks
|
|
|
|
thaelin
Newbie
Offline
Activity: 64
Merit: 0
|
|
December 12, 2017, 11:00:54 AM |
|
Just a heads up to who ever takes care of the WTM prgm. Over the weekend, I tried out the BTG Miner and had limited luck on that. All seems to have went well except my wallet is still empty. I used the BTG Core and all looks good. Will have to let it run more to see if it just needs more time.
Now, I have manually switched back to ETH on that test machine. When I got home today, it says I am still mining BTG. I did a re-edit of 1bash and then totally restarted the machine then off to work. The terminal says I am in fact mining ETH and the pools shows it there. Not sure why this happened. I do not have the auto switch on as I just want to see which coin is the best at that time.
thay
|
|
|
|
alko67bi
Newbie
Offline
Activity: 26
Merit: 0
|
|
December 12, 2017, 11:24:20 AM |
|
I try to use v0019-2. Changed settings in 1bash: ZM_or_EWBF="ZM" ZEC_POOL="europe.equihash-hub.miningpoolhub.com" but starting EWBF with pool us-east.equihash-hub.miningpoolhub.com Where I must change it?
|
|
|
|
papampi
Full Member
Offline
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
|
|
December 12, 2017, 11:27:01 AM |
|
Just a heads up to who ever takes care of the WTM prgm. Over the weekend, I tried out the BTG Miner and had limited luck on that. All seems to have went well except my wallet is still empty. I used the BTG Core and all looks good. Will have to let it run more to see if it just needs more time.
Now, I have manually switched back to ETH on that test machine. When I got home today, it says I am still mining BTG. I did a re-edit of 1bash and then totally restarted the machine then off to work. The terminal says I am in fact mining ETH and the pools shows it there. Not sure why this happened. I do not have the auto switch on as I just want to see which coin is the best at that time.
thay
I'm the one you want to shout at ... but dont know why Dont understand what you mean by your wallet is empty? WTM switcher just switches, if you have problem setting up your wallet, miner, ... then for sure when it switch it cant mine. Does the pool shows your hashrate when you mine? When you disable wtm auto switch in 1bash you should stop its script if you dont want to restart the rig either by closing its guake tab or run pkill -f 8wtm_auto_switch
|
|
|
|
|