Search content
Sort by
Showing 20 of 40 results by disq
Re: [Phoenix Addon] Simple export hashrate and accepted/rejected to a text file
I've modified this patch (when you first posted it to the Phoenix thread) to also include a timestamp in the file. It's distributed with the "Rug Monitor" package. Link: https://github.com/disq/bitcoin-rug-monitor/blob/master/logtotext-1.48.diff
Re: "Rug Monitor" - Monitor your mining rigs (graphs for hashrate, temps, etc.)
I tried removing "--right-axis 1:50" and not only does it not scale, but it doesn't show the temps.
This is the main thing I'd like to get fixed, any other suggestions?
This is the main thing I'd like to get fixed, any other suggestions?
Ah sorry, you also have to edit the line that says "LINE2:tempoff#D62728CC:"Temp"" to "LINE2:temp#D62728CC:"Temp"" (line 272 i believe)
If you set an offset other than 50 in the axis, you also have to change line "CDEF:tempoff=temp,50,-,0,MAX" (line 257) to reflect the change. (LINE2 should stay as "tempoff" then)
Re: "Rug Monitor" - Monitor your mining rigs (graphs for hashrate, temps, etc.)
Well, yes, if you set status_type to hashrate you have to point the status_file to a file which is updated with the hashrate. There is no built-in support to get your miner's current hashrate to a file, you have to implement this part yourself. Also, if you use this method, there is no way to get share counts.
Thanks for clarifying that you can only have hashrates or shares.
Quote from: wacked
I tried removing "--right-axis 1:50" and not only does it not scale, but it doesn't show the temps.
This is the main thing I'd like to get fixed, any other suggestions?
Doing that worked for me, but it also removed the right-axis. (The red temps-line didn't disappear) To keep the right axis, use "--right-axis 1:0" (so scale=1, offset=0) If you want to offset the temp values/right axis, but not offset it by 50 (which is the default), just change the 50 to something else.This is the main thing I'd like to get fixed, any other suggestions?
Quote from: wacked
Believe me, I've done numerous hours of research including that file, but the gen-graph.php file code doesn't seem to match very well with examples on the internet.
Yeah, generating graphs dynamically (variable # of variables, etc) requires a different programming style than building them statically. Sometimes it gets me confused as well.Re: "Rug Monitor" - Monitor your mining rigs (graphs for hashrate, temps, etc.)
I understand setting:
I know I would set it in:
hashrates or how to get the hashrates to log to a file. I assume the same thing would be needed to get shares?
Well, yes, if you set status_type to hashrate you have to point the status_file to a file which is updated with the hashrate. There is no built-in support to get your miner's current hashrate to a file, you have to implement this part yourself. Also, if you use this method, there is no way to get share counts.Code:
"status_type":"phoenix"
toCode:
"status_type":"hashrate"
but where do I get the hashrate data from? It's not explained in the readme.I know I would set it in:
Code:
"status_file":"Off",
by replacing Off with the source of the file, but I need more info on which file has the hashrates or how to get the hashrates to log to a file. I assume the same thing would be needed to get shares?
Quote
Does anyone know how to scale the load/temp graphs to scale on the right side for temperatures to something lower than 150? Right now my temps are in the mid 80s for the high, yet the right side scales to 150.
You can edit gen-graph.php and remove the "--right-axis 1:50" statement (I think it's in line 276) to prevent the right-axis values from shifting.Quote
Any help would be appreciated. The README file is good, but I think it assumes I know more than I do. 
rrdgraph manpage is a good resource 
check out this thread: http://forum.bitcoin.org/index.php?topic=7216.0
I've lost one Setsugen custom cooled 5870 (reference design) to swapping cards. I probably put too much physical strain on the gpu. Now I get a reboot (or sometimes hang, IIRC) when I try to boot X from that card, and bios spits out a "HyperTransport error" afterwards :/
Tip: Don't go handling cards just from the heatsink/cooler, support them from the pcb as well.
Tip: Don't go handling cards just from the heatsink/cooler, support them from the pcb as well.
there's Bitparking Namecoin Exchange: https://exchange.bitparking.com/
Re: "Rug Monitor" - Monitor your mining rigs (graphs for hashrate, temps, etc.)
I start my miners with
I have seen in the code, that phoenix dumps the stats every second.
When I do a "tail -f /tmp/gpu1.log" I recognized that the file updates irregularly, sometimes with >8s delay.
I think 30 seconds for testing phoenix is still alive is okay for most setups.
After I changed the time for above setting to 15s, my "shares submitted" Graph do not recognize the shares anymore.
Code:
-t /tmp/gpu1.log -k phatk DEVICE=1 VECTORS BFI_INT AGGRESSION=15 WORKSIZE=64 FASTLOOP=false
I have seen in the code, that phoenix dumps the stats every second.
When I do a "tail -f /tmp/gpu1.log" I recognized that the file updates irregularly, sometimes with >8s delay.
I think 30 seconds for testing phoenix is still alive is okay for most setups.
After I changed the time for above setting to 15s, my "shares submitted" Graph do not recognize the shares anymore.
I think it's the high aggression. I run my miners with aggression=13. Anyway, I've increased the allowed delay to 30s in git.
The shares submitted graph/data shouldn't have anything to do with this though, are you sure? What's the output of update.php? It's in the format "N::::::", can you check if it's reading the share counts ok? (If so, it's an rrdgraph/rrdupdate problem. If not, it's about Phoenix's output not being parsed correctly somehow)
Re: "Rug Monitor" - Monitor your mining rigs (graphs for hashrate, temps, etc.)
very nice scripting
I am using manual patched phoenix 1.50.
I noticed, that hasrates per device values were incorrect. (rates were too low)
I am not very familiar in php coding but I found this line in update.php
line 25
I increased the value from 3 to 15 seconds and now the rates seem to be correct.
Is there a reason, why you set the interval of file change date so low?
I am using manual patched phoenix 1.50.
I noticed, that hasrates per device values were incorrect. (rates were too low)
I am not very familiar in php coding but I found this line in update.php
line 25
Code:
if (is_array($st) && time() - $st['timestamp']<3)
I increased the value from 3 to 15 seconds and now the rates seem to be correct.
Is there a reason, why you set the interval of file change date so low?
fyi, the 1.48 patch can be applied to 1.50 as well. the reason behind that code is the assumption that if the stats isn't updated within the last 3 seconds than there's something wrong with the miner, maybe the card/miner froze or miner is not running. (as phoenix by default updates the file/dumps status every second)
of course, if phoenix updates the stats less frequently, this assumption isn't true. are you running phoenix with a custom avgsamples (-a) setting? i should probably extend the time to something like 30 seconds to cover most possibilities.
Re: "Rug Monitor" - Monitor your mining rigs (graphs for hashrate, temps, etc.)
one last question, the "shares submitted" graph shows XXm on the y-axis. where is this value calculated? (i think somewhere around line 220)
i thin the 'm' does not stand for 'million'
i thin the 'm' does not stand for 'million'
m is 'milli' (thousandth) the units have SI symbols. The shares submitted graph shows shares per second. The negative Y-axis (below 0) is shares rejected, positive is shares accepted. I had a problem with the shares submitted graph that, sometimes it would get confused and get spikes. Since rrdgraph automatically "zooms out" to view all the data, when this happens the actual shares graph is useless (since it's all zoomed out). Sorry for that, still looking for an explanation/solution.
It would be nice if you left the files default setting files there so we could edit them manually rather than have to fight with Apache about write premissions and what not :<
rrdgraph creates new image files with each generation. You could play with 'umask', but it could be easier (depending on your setup) to schedule a chmod each time after gen-graph runs.
awesome! Tipped you
Next week it's time to start building our cluster mgmt software and was just thinking howto monitor, thanks for solving it!
Rest should be easy
Thanks and good luck! Tipped you Next week it's time to start building our cluster mgmt software and was just thinking howto monitor, thanks for solving it!
Rest should be easy
Re: "Rug Monitor" - Monitor your mining rigs (graphs for hashrate, temps, etc.)
nice script 
however i had to set the -t /tmp/* path to the home dir of the user, cause i wanna start phoenix through a script, and so the privilege management was easier.
is there a way to create bigger images? i only found the width value, but no height value. you could may add the values to the config?
however i had to set the -t /tmp/* path to the home dir of the user, cause i wanna start phoenix through a script, and so the privilege management was easier.
is there a way to create bigger images? i only found the width value, but no height value. you could may add the values to the config?
If you're running from a usb thumb drive, I highly recommend putting the phoenix output to tmpfs, since writes on flash memory are limited. (btw, noticed that in stock debian6, /tmp isn't tmpfs, it just resides on disk. this is bad of usb sticks as well. you can fix this by mounting /tmp as tmpfs in fstab)
Anyway, to change the chart configuration, currently one has to edit the gen-graph.php file. In later versions I could make the rrdgraph parameters configurable via the config file. But for now, here's a quick reference from RRDtool website: rrdgraph manpage (Scroll down to "Size" section)
Re: Continuum Mining Pool: No fees; Optional PPS; Client uptime monitoring
is it possible to make exceptions on the minimum payments? i'm running PPS and having sub-1btc transactions few times a day really crimps my wallet's style :p
maybe use the password field for settings (though it wouldn't be secure) or raise the minimum auto-payout limit and provide a "button" to get paid early.
maybe use the password field for settings (though it wouldn't be secure) or raise the minimum auto-payout limit and provide a "button" to get paid early.
Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
v1.50, I've been getting this from time to time:
Quote
Traceback (most recent call last):
File "/usr/lib/python2.6/dist-packages/twisted/internet/tcp.py", line 519, in connectionLost
protocol.connectionLost(reason)
File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 826, in dispatcher
return func(*args, **kwargs)
File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 1438, in _connectionLost_WAITING
self._disconnectParser(reason)
File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 1367, in _disconnectParser
parser.connectionLost(reason)
--- ---
File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 494, in connectionLost
self.bodyDecoder.noMoreData()
File "/usr/lib/python2.6/dist-packages/twisted/web/http.py", line 1388, in noMoreData
finishCallback('')
File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 409, in _finished
self.finisher(rest)
File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 1346, in _finishResponse
self._giveUp(Failure(reason))
exceptions.UnboundLocalError: local variable 'reason' referenced before assignment
File "/usr/lib/python2.6/dist-packages/twisted/internet/tcp.py", line 519, in connectionLost
protocol.connectionLost(reason)
File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 826, in dispatcher
return func(*args, **kwargs)
File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 1438, in _connectionLost_WAITING
self._disconnectParser(reason)
File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 1367, in _disconnectParser
parser.connectionLost(reason)
--- ---
File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 494, in connectionLost
self.bodyDecoder.noMoreData()
File "/usr/lib/python2.6/dist-packages/twisted/web/http.py", line 1388, in noMoreData
finishCallback('')
File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 409, in _finished
self.finisher(rest)
File "/home/bitcoin/phoenix-1.50/minerutil/_newclient3420.py", line 1346, in _finishResponse
self._giveUp(Failure(reason))
exceptions.UnboundLocalError: local variable 'reason' referenced before assignment
Re: BTC Guild - 0% Fees, Long polling, SSL, JSON API, and more [~1500 gH/sec]
**********PSA**********
This is in your best interested to distribute yourselves out.
This is in your best interested to distribute yourselves out.
Whats stopping btcguild from using round robin or some other distributing algoritm when going over? that would solve the single server overload issue directly.
Deepbit points you to the closest server when you use their adress so it is possible to do.
Edit. everyone mining with the guiminer or other mining softwartes with hardcoded addresses would have to change miners to use those links.
well, the round-robin doesn't need to be smart, he could use vanilla DNS for it without any balancer. can't control it automatically and fast though (well, unless very short TTLs are used along with some bash-fu to check availability/update the main dns record) but at least wouldn't lose mining time and the eventual hashing power drop could be avoided. (of course, port 80 needs to be redirected to the main webserver which needs to run in a subdomain, maybe 'www')
Re: Monitoring your miner's GPU TEMP/LOAD/CLOCK with CACTI + SNMP
Good stuff! For people who don't want to use snmp (or just have a few rigs and not a dozen) they could use my custom solution "rug monitor", link in the sig. (Shameless self plug)
Re: "Rug Monitor" - Monitor your mining rigs (graphs for hashrate, temps, etc.)
I recently tried this with 4 gpus (3 cards) on one box. Fan query seems to be a bottleneck, at least for my setup (sdk 2.1)
If running getstatus.php takes more than 2 seconds for you, or you get occasional gpu at 0% reports (jitters in the charts, etc) you should try disabling fan monitoring.
Edit your config.json file and change "fan":"yes" lines to "fan":"no" and see if it changes anything for you.
If running getstatus.php takes more than 2 seconds for you, or you get occasional gpu at 0% reports (jitters in the charts, etc) you should try disabling fan monitoring.
Edit your config.json file and change "fan":"yes" lines to "fan":"no" and see if it changes anything for you.
Re: [MINER] Phoenix - New efficient, fast, modular miner **BFI_INT support!**
Here is the logtotext patch for the 1.48: https://github.com/disq/bitcoin-rug-monitor/blob/master/logtotext-1.48.diff
Re: "Rug Monitor" - Monitor your mining rigs (graphs for hashrate, temps, etc.)
Is there a modification of the patch for phoenix-1.48 yet?
Sorry about that, I've just uploaded a patch for phoenix-1.48. Get it from github, put in phoenix dir, apply with "patch -p1