|
@VoskCoin That is the API build into the EWBF miner. When you launch EWBF you can add the following to the script:
--api minerip:42000
Where minerip is the IP address of your rig.
You then simply point a browser to minerip:42000 to get the above stats. They update about every 30 seconds or so when new work is assigned.
|
|
|
|
I rather not use api to kill my miner every once in a while just to see the web page stats better enable screen log and use tail change from: screen -dmS miner $HCD ...
To: screen -dmSL miner $HCD ...
Then ssh to your rig and use this : My miners running flawlessly for 2-3 days with no restart True I could do that, but pointing a browser to the API seems like a much more elegant solution, plus I could get creative and do up a local html page and use iframe to show all the miners in a single browser tab. Tailing log files just seems very "old school".  |
|
|
|
|
So wait, I have a wife, 5 and 6 year old daughters, a dog, 3 cats and 3 birds. I have 3 open rigs (each between 7 and 9 GPUs, mostly 1080Tis) and my plan was to pull them up from the basement and scatter them about the house to heat it during the winter months. Each draws about 1,500 W from the wall. So you guys are saying that would be a bad idea? This will be my first season winter mining. I had to get a 2 ton mini split and put in the basement to keep it from getting too hot. I was hoping to negate that expense during the winter months by using the rigs for heat almost exclusively.
|
|
|
|
I agree this is an ewbf linux bug. Unfortunately the author does not seem to be active these days. My friend that is having the exact same issue took a look at the watchdog script and ripped out some logic to create an "apicheck" bash script. It goes like this: #!/bin/bash
source ~/1bash
#########################################################################
API_IS_UP=0
if nc -vzw1 $IPW 42000;
then
API_IS_UP=1
fi
echo ""
if [[ $API_IS_UP == 0 ]]
then
echo "$(date) - Miner api is down: reinitializing now"
# If miner runs in screen 'miner' kill the screen to be sure it's gone
pkill -e miner
# Kill 3main to re-init
target=$(ps -ef | awk '$NF~"3main" {print $2}')
kill $target
else
echo "$(date) - Miner api is up"
echo ""
fi
If would be awesome if the above logic could be incorporated into the official watchdog. It would also mean adding something like this to 1bash: USE_EWBF_API=”YES”
EWBF_API_PORT=”42000”
And modify 3main to launch EWBF with the api flag. Something along these lines: screen -dmS miner $HCD --eexit 3 --fee $EWBF_PERCENT --pec --server $ZEN_POOL --user $ZENADDR --pass z --port $ZEN_PORT --api $IP:$EWBF_API_PORT;
Thanks It just happened again. Here are my 4 miners, the one running ewbf on windows recovered fine, but the 3 running nvOC never did:  And here you can see the connectivity glitch on the pool right around 11am:  So adding the above tweaks to the distro should solve this. EDIT: My friend who is already running the above tweaks confirmed it worked perfectly. Thanks |
|
|
|
Here's my latest bill:  I have a 20kw solar array which is why I had no consumption from March - June and only a tiny bit in July, which is when I started mining. My usage would have been another 2,500 kWh this past month had it not been for the solar array. Here's my historical over the last 3 years:  I need to modify it to show my effective kWh rate with the solar offset. I'm doing about 14 ksol/s and Burst mining with 260Tb. I'm hoping the use my miners for heating during the cold season to offset the cost. This summer's heat was pretty brutal. |
|
|
|
You are duplicating "workername", the workername is included in ZENADDR variable, why adding it again? Delete the part listed in orange or you will get something like address.worker.worker instead of address.worker
Those are nice looking stats, where did you get this api? Is it pool specific, miner specific, nvOC specific??? How do you connect to it? You are supplying local network ip address... hrmm... care to share more info about the api?
Thanks. Good catch. I was playing around with the environment variables earlier and forgot to change that back. I know have this, which is generic enough to deploy on all my rigs: screen -dmS miner $HCD --eexit 3 --fee $EWBF_PERCENT --pec --server $ZEN_POOL --user $ZENADDR --pass z --port $ZEN_PORT --api $IP:42000;
Adding the --api $IP:42000 allows you to point a browser from any machine in your lan, to the ip:port of the miner and get a nice little display showing how that rig is doing. This is a feature built into ewbf. I did open an issue on Github for this (the api stopping working if the pool drops out), but since the author of ewbf seems to have run off for the last month or so, I'm not sure if it will ever get resolved. Enabling --api kinda makes --pec redundant since it passes the same information to the api, especially if you run your rig monitor less and don't plan to teamview into it. Oh, I never used ewbf, hence my lack of knowledge about it... thanks for the info though, if/when i start using ewbf i will try it. It seems it's ewbf linux bug... if it works for 10 hours you can use crontab to restart the miner every 10 hours... it's not the best solution, but if you must use the api it seems it's the only solution until the developer fixes the bug... or you can maybe try older version of ewbf that might not be affected by this bug I agree this is an ewbf linux bug. Unfortunately the author does not seem to be active these days. My friend that is having the exact same issue took a look at the watchdog script and ripped out some logic to create an "apicheck" bash script. It goes like this: #!/bin/bash
source ~/1bash
#########################################################################
API_IS_UP=0
if nc -vzw1 $IPW 42000;
then
API_IS_UP=1
fi
echo ""
if [[ $API_IS_UP == 0 ]]
then
echo "$(date) - Miner api is down: reinitializing now"
# If miner runs in screen 'miner' kill the screen to be sure it's gone
pkill -e miner
# Kill 3main to re-init
target=$(ps -ef | awk '$NF~"3main" {print $2}')
kill $target
else
echo "$(date) - Miner api is up"
echo ""
fi
If would be awesome if the above logic could be incorporated into the official watchdog. It would also mean adding something like this to 1bash: USE_EWBF_API=”YES”
EWBF_API_PORT=”42000”
And modify 3main to launch EWBF with the api flag. Something along these lines: screen -dmS miner $HCD --eexit 3 --fee $EWBF_PERCENT --pec --server $ZEN_POOL --user $ZENADDR --pass z --port $ZEN_PORT --api $IP:$EWBF_API_PORT;
Thanks |
|
|
|
|
I know this is primarily discussing leaving Bitcoin in an exchange, but what if you are holding a dozen coins on an exchange like Bittrex, let say with a combined value of $5,000. Wouldn't it be a pain to setup 12 different wallets on your desktop or elsewhere and move these holdings there?
Are there online wallets that can accommodate a mixed portfolio, or do they all only work with a single coin?
|
|
|
|
Yeah, switch to ZEN.  |
|
|
|
You are duplicating "workername", the workername is included in ZENADDR variable, why adding it again? Delete the part listed in orange or you will get something like address.worker.worker instead of address.worker
Those are nice looking stats, where did you get this api? Is it pool specific, miner specific, nvOC specific??? How do you connect to it? You are supplying local network ip address... hrmm... care to share more info about the api?
Thanks. Good catch. I was playing around with the environment variables earlier and forgot to change that back. I know have this, which is generic enough to deploy on all my rigs: screen -dmS miner $HCD --eexit 3 --fee $EWBF_PERCENT --pec --server $ZEN_POOL --user $ZENADDR --pass z --port $ZEN_PORT --api $IP:42000;
Adding the --api $IP:42000 allows you to point a browser from any machine in your lan, to the ip:port of the miner and get a nice little display showing how that rig is doing. This is a feature built into ewbf. I did open an issue on Github for this (the api stopping working if the pool drops out), but since the author of ewbf seems to have run off for the last month or so, I'm not sure if it will ever get resolved. Enabling --api kinda makes --pec redundant since it passes the same information to the api, especially if you run your rig monitor less and don't plan to teamview into it. |
|
|
|
I stole your list and pulled out just the 10x0 series and sorted by sol/s and added efficiency column. It seems very few of you guys tune for efficiency. I have marked all the ones I could determine in green that were over 3.50 sol/W.  |
|
|
|
|
Had the API stop working again on the rigs running EWBF on nvOC. So the trigger is a momentary loss of connectivity to the pool The windows rigs running EWBF recovers within seconds, but the nvOC rigs never get the API back up again, but they do go back to mining.
|
|
|
|
So I have this little bit of custom code added to my 3bash file on all my rigs: ZENADDR="$ZEN_ADDRESS.$ZEN_WORKER" screen -dmS miner $HCD --eexit 3 --fee $EWBF_PERCENT --pec --server $ZEN_POOL --user $ZENADDR.$WORKERNAME --pass z --port $ZEN_PORT --api 10.0.1.110:42000; I have 3 rigs that run nvOC (for now) and others that run windows 10. All are mining with EWBF 0.34b. What happens is that after about 10 hours, the nvOC rigs all drop the api functionality at the same time and my browser windows starts showing disconnected for the miner and server, yet they are still mining away. The windows boxes just keep trucking along. I thought is was something with my setup, but a buddy of mine is seeing the exact same thing on the rigs he switched over the ncOC as well. Killing the miner and restarting it brings the API back to life. This is happening on both 0019 and 0019.1-2 rigs. Any ideas? Alternatively, is there a better "single pane of glass" to give me a view similar to this?  Thanks |
|
|
|
I knew that old 5 1/4" HD would be good for something one day.  |
|
|
|
try to run after it downloaded the files run see how it goes. That worked! After running the 1st part, it got stuck again trying to open a 2nd window, but I just did a ctrl-c and then ran the 2nd command. When it was done and rebooted, I copied my 19.1-1 1bash file over, but it then tried to update to 19.1-2 again. So I modified the 19.1-2 1bash instead and I'm mining again, AND I DON'T HAVE THE ISSUE WITH IP ONLY BEING ASSIGNED 50% OF THE TIME. GREAT JOB!!! So the above trick should work for doing a manual update over ssh where you can't pop a 2nd screen? |
|
|
|
|
I do about $15/day on Burst. I have 255TB on a single server that scans 84 drives (all on SAS2 backplanes) in 24 seconds, so my deadlines are pretty good. Its a bit of a power hog though since 60 of those drives are 2TB old school Hitachi 7200 RPM spinners. The rest are fairly new WD REDs (6 and 8TB). So yeah, if I hadn't already had about 200TB sitting around doing nothing (backup to my media server), it would probably not be worth it, but as it is, I should easily ROI those new WD REDs in well under a year.
|
|
|
|
Before reimaging as a last resort, you can try to ssh to your rig and, edit 1bash to include AUTO_UPDATE="BETA" and run: bash 4update
Thanks. I gave that a shot, but when it got to the part where the update process is supposed to pop another window, it failed since I just did a plain ssh session using putty. So for now, that rig is back to mining with EWBF on windows since I still have the SSD in there from before I switched to ncOC (running off USB stick). I'm leaving my production rigs on 0019 stable for now. |
|
|
|
I set auto update to yes in 1bash and rebooted. It started mining, then killed the miner and started the update process (which includes a newer nVidia driver). Anyway, when it was done, it rebooted to this:  I type it the miner1 password, and it just keep looping back to the same prompt. Rebooted and got the same thing. I SCP'ed over my 0019-1.1 1bash and 3main files and rebooted again. Got to the same screen as above. So I guess my only option now is to go back to the 0019 image and start fresh? |
|
|
|
|
I'm getting a positive vibe about this coin. Just thew about 12ksol hash at it. Fingers crossed.
|
|
|
|
0019-1.1 is not able to pick up an IP address on a consistent basis. It only picks it up on every other reboot or thereabouts. If I run this from the console m1@skylake:~$ IPW=$(ifconfig | sed -En 's/127.0.0.1//;s/.*inet (addr:)?(([0-9]*\.){3}[0-9]*).*/\2/p')
m1@skylake:~$ echo “My IP is” $IPW
It returns nothing about 50% of the time. 0019-1 did not have this issue. I'm seeing this behavior on rigs with the following mobos: ASRock Fatal1ty Z170 Gaming K6 (using on-board NIC) Asus Maximus VIII Extreme (using Intel X520 10G NIC) My main rigs use these mobos, but I have not dared upgrade any of those yet: Asus PRIME Z270-A MSI Z270A PRO Is this a known issue? I'll check load average at the time that problem occurs: If you use static ip may be could help disable network-manager.service. Check the status like this: systemctl status network-manager.service May be the network is down so the ifconfig can't get the ip? This script may help you to test that: #!/bin/bash
LOG="test_network.log"
uptime &>> $LOG
# ping 3 packets every 2 seconds, wait 3 seconds maximum
/bin/echo "$(date +%F\ %T) &>> $LOG
/bin/echo "Pining 8.8.8.8 with 3 paquets of data every 2 segs, wait 3 segs max" &>> $LOG
PING=$(ping -n -c 3 -i 2 -W 3 8.8.8.8 2>&1)
if [[ $? != 0 ]]; then # If not response from host
if [[ $PING =~ "loss" ]]; then
# no reply
ERROR=$(echo "$PING" | grep 'loss')
else
# destination unreachable
ERROR=$PING
fi
echo "ERROR ----> $(date +%F\ %T) - Failed check - $ERROR" &>> $LOG
echo &>> $LOG
exit
fi
/bin/echo "8.8.8.8 ----> OK" &>> $LOG
/bin/echo "------------------------------------" &>> $LOG
/bin/echo &>> $LOG
exit
In order to get it working first do: nano /home/m1/net_uptime.sh
Copy the script. Then CTRL+O, say yes to save the file. then: chmod 700 /home/m1/net_uptime.sh
run it from cron: add this line to run it every minute: */1 * * * * /home/m1/net_uptime.sh > /dev/null 2>&1
if your system open the crontab file with "vi" then: ":wq" to write the modification on crontab and exit. if your system open the crontab file with "nano" then: "CTRL+O", say yes to write the modification on crontab and exit. you should get to the log file here /home/m1/test_network.log Hope it helps. My guess is this is due to a system update which changed the priority of networking services or created a conflict. I will add a conditional to verify the IP is properly detected in an update; what is the IP set to when it is not properly set? In my case, no IP is assigned. So a reboot from the local console is the only way to get back in. All devices on my LAN (about 60) have static mappings managed by my router/gateway. Never had issues with them not being assigned IPs on reboots or when their leases renew. This behavior is definitely associated with 19-1.1 I agree is sounds related to networking services or a conflict. |
|
|
|
0019-1.1 is not able to pick up an IP address on a consistent basis. It only picks it up on every other reboot or thereabouts. If I run this from the console m1@skylake:~$ IPW=$(ifconfig | sed -En 's/127.0.0.1//;s/.*inet (addr:)?(([0-9]*\.){3}[0-9]*).*/\2/p')
m1@skylake:~$ echo “My IP is” $IPW
It returns nothing about 50% of the time. 0019-1 did not have this issue. I'm seeing this behavior on rigs with the following mobos: ASRock Fatal1ty Z170 Gaming K6 (using on-board NIC) Asus Maximus VIII Extreme (using Intel X520 10G NIC) My main rigs use these mobos, but I have not dared upgrade any of those yet: Asus PRIME Z270-A MSI Z270A PRO Is this a known issue? |
|
|
|
|
Show Posts
