Topic: "Rug Monitor" - Monitor your mining rigs (graphs for hashrate, temps, etc.) (Read 11768 times)

Wonder if this can be adapted to work with the new cgminer which is rpc capable

Well, the only issue I see that I overlooked and I'm not sure if rrdgraph can do it or not but I want the left side "load" scale from 0 to 100%, and the right side "temp" to scale from say 50 to 90C.  If that's not possible, it's not a big deal, as I can simply look and see the avg load and last load.

Nice, that did work well, as it now scaled to 100. 
I changed it from  "--right-axis 1:50" to  "--right-axis 1:0" and then changed that tempoff to temp and it now scaled to 100C.
I then added -u 90 -r and it now will scale to only 90. 
Thanks much!

As far as the shares and hashrate, I personally don't need both, and would prefer hashrate over shares anyhow, but having both would help others I'm sure.

I personally run the ./gen-graph.php every 14 minutes and ftp the data every 15 to a external web server.
The overall ./gen-graph.php all is generated twice a week, and then all the generated PNG files all deleted 30 minutes later so the normal FTPing of just the ./gen-graph.php data can proceed.

It does what I need it to do, that's all that matters!
Thanks again for your help! =)

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)

You can have both only if you use the phoenix patch and phoenix miner. I can devise another import mechanism though, if you like. Maybe also accept a hashrate file in the format of ";;" etc. If you're interested, it should be fairly easy for me to implement this.

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.

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.

Thanks for clarifying that you can only have hashrates or shares.


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?


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.
Like I said, I'm not a programmer, but I can normally figure things out if pointed in the right direction.

Thanks!

Thanks,

 I has already patched phoenix, but it just wasn't clear to me I had to start phoenix with the 't /tmp/miner.log'

 

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.

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.

rrdgraph manpage is a good resource

Hello


There is a patch included for phoenix miner, which enables logging to a file.
Or get the patch here https://raw.github.com/disq/bitcoin-rug-monitor/master/logtotext-1.48.diff

It says 1.48 but works on 1.50 too.
After you patched phoenix with that you can add something like this to the commandline which
starts phoenix miner "-t /tmp/miner.log". That is the file you give as status_file in the config.

Ok, I've got the basics up and running, and now I am allowed to POST, or I would of asked this question and posted earlier, but I was a little confused on what I need to set in the config.json to get the hashrates and shares.

I understand setting:
 to
but where do I get the hashrate data from? It's not explained in the readme.

I know I would set it in:    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?

A few other questions.
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.  I've managed to change the graph size to be something much larger and also changing the colors of the graphs. I also don't use the fan speed, because my fans are set to a constant speed.


That gave me something much larger and easier to read, and I changed my colors to something slightly different for output on load/temps along with adding Min and Max temperature readouts with this code:


Any help would be appreciated. The README file is good, but I think it assumes I know more than I do.

BTW, here's an output of the modified load/temp file.

http://img685.imageshack.us/img685/9350/tempsminingrugd00.png

Good stuff! I'll roll this into my Cacti templates (http://forum.bitcoin.org/index.php?topic=23406.0) when the 6990's come in...

To get the hash rate out of phoenix, you can also use my XML-RPC interface approach instead of parsing log files.

the 1.48 patch works fine with 1.50

Is there a patch for phoenix 1.50 yet?

is there a way to 'open' the database and have a look on the data?

When I just worked a bit with the graphs while such a anomaly occurred. I noticed the console/system was lagging at the moment, don't think it is a graph problem.

Another thing, I tried to create a 'average-valid-shares'graph with the "TREND" function. But I don't understand the logic behind this one.

My graph actually looks like this:
http://s1.directupload.net/images/110620/i4kf6thz.png

Orange = accepted shares
Blue = accepted - rejected shares = valid shares
Red = average shares (on 12h base)

the red one is created by: $cdef[] = 'CDEF:aver'.$unid.'=vali'.$unid.',43200,TREND';

is dis correct? and why stops the line in the middle of the graph?

btw. I added "--start end-23h-59m" to the graph_internal() function, to have hourly marks on the x-axis.

greetings

How strange is this?
I changed back to 30 s and now the shares are counted - but wrong as it seems.


Grap shows following values
GPU0 : 40
GPU1 : 28
GPU2 : 20

y-achsis top mark is 200

Changing value to 3s does not fix "shares submitted" problem.


Any idea why the graph does not update?

The output of update.php seems to be ok:

All other graphs seem to be okay - only shares submitted doesn't show results anymore.
I'll put the file-change value back to 3 seconds to check this behavior.

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)

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.