[Minera v0.9.1] Your next mining dashboard - Antminer/CPUminer/CGminer/BFGminer

[SilentH]

Upgrade went smooth.

Slick Stuff!

real time logs never show anything when i hit play though, and the raw logs link gives me a 404 error.. just a heads up.

looks like no sym link from application folder to var/log

[1715443966]

1715443966

[1715443966]

1715443966

[1715443966]

1715443966

[1715443966]

1715443966

[1715443966]

1715443966

[SilentH]

strange, just updated second Pi, also went smooth but real time logging working fine..

go figure.

[fivejonnyfive]

thank you very much for sharing this, I checked every commits made on install/upgrade scripts but I cannot find the problem, so I'm thinking about a bad "git pull" or something like that which placed bad chars on them.

Hope it doesn't happen anymore.

thanks

Don't sweat it. Like I said I had hastily deployed minera to a pre-existing system so who knows where the problem came into play.

I duplicated the SD card and edited the sudoers file on the original to remove the offending -e, but then the Pi failed to boot fully. Who knows why - maybe macfuse borked the filesystem. Dupe of the original SD still boots fine.

I didn't have time (and/or was too drunk to code) last night so I didn't build a system from scratch yet - and at this point since it's still happily mining I may just wait until you release img files.

If you're unfamiliar with it, apple pi baker is a great tool for making and deploying properly partitioned img files for the raspberry pi:
http://www.tweaking4all.com/hardware/raspberry-pi/macosx-apple-pi-baker/

Way faster than the dd command I used to use.

Anyway I very much appreciate you looking through old commits - your software is great and even if it had been your error - you wrote free software that helps make me money, what complaint could I possibly have. Expect a donation once I reach ROI in a week or two.

Well, Minera 0.1.8 is out

What's next: I finally have a RPi to start build Minera images (pretty exciting), but I still have to put Json config and start/stop daemon.

One question for you all:

What do you think about you will not be able anymore to "screen -r" into cpuminer from Minera? This is because there is some issues playing with screen sessions and daemontools/supervisor, so if we opt in for one of those daemon tools we have to leave the screen solution.

But before doing this I would like to hear your opinion or may be if you have some solutions to run screen with a daemon tool. (The problem I saw is that you can run the screen session within the minerd command, but you cannot quit it, and this is the main problem).

I didn't try this too much, but looking around the web it seems a common problem, so please let know what do you think about this.

Thanks

I mean, this might be overly basic but you've tried

Code:

screen -dmS miner [command]

Im not familiar with daemontools but when I was writing daemons for launchd on the mac this would detach the screen session from the daemon so it would run when the daemon quits. This was a while ago on a different flavor of *nix so, not sure if that helps at all.

Personally, I wouldn't be too busted up about not being able to screen -r into the miner as long as there are some logs to review in the event of troubleshooting.
The entire reason I'm using minera is so that I don't HAVE to screen -r into the miner - which is how I was operating before just using cpuminer-gc3355 and a basic startup script.

If the last 'n' lines of miner output were available in a log file somewhere it would satisfy my needs at least, where 'n' is an arbitrary amount of logging that goes far back enough to enable troubleshooting but doesn't just fill up the disk ad infinitum

FOR BONUS POINTS
It would be really sleek if you could download the available logs, maybe even as a zip file, from somewhere within the minera interface. Far from a requirement, also I feel like the interface might not be working in the hypothetical situation where I need to get at the logs - but still. I think that would be a worthy tradeoff for losing screen TUI access.

I just noticed you added a log viewer already, which is basically even better. I can't upgrade till I fix my sudoers issue but when I do I'll let you know if that has the logs i'm referring to.

[SilentH]

yea the raw logs opens up a new url to the raw log file which I'm prompted to download locally.

So here's something strange for you, michelem, on the system with the working log files, I no longer have the ability to switch between "Guided" and "Manual" setups. Both buttons are there, but greyed out. Mousing over changes nothing, and clicking either does nothing.

[michelem]

yea the raw logs opens up a new url to the raw log file which I'm prompted to download locally.

So here's something strange for you, michelem, on the system with the working log files, I no longer have the ability to switch between "Guided" and "Manual" setups. Both buttons are there, but greyed out. Mousing over changes nothing, and clicking either does nothing.

Did you run the upgrade_minera.sh script? Can you run it and let me know? (I need to add it to the auto-update system).

BTW, run this fixes the guided/manual settings for sure:

Code:

redis-cli set guided_options 1

But running the upgrade should fix also the log file issue.

[michelem]

[...]
I mean, this might be overly basic but you've tried

Code:

screen -dmS miner [command]

Im not familiar with daemontools but when I was writing daemons for launchd on the mac this would detach the screen session from the daemon so it would run when the daemon quits. This was a while ago on a different flavor of *nix so, not sure if that helps at all.

Personally, I wouldn't be too busted up about not being able to screen -r into the miner as long as there are some logs to review in the event of troubleshooting.
The entire reason I'm using minera is so that I don't HAVE to screen -r into the miner - which is how I was operating before just using cpuminer-gc3355 and a basic startup script.

If the last 'n' lines of miner output were available in a log file somewhere it would satisfy my needs at least, where 'n' is an arbitrary amount of logging that goes far back enough to enable troubleshooting but doesn't just fill up the disk ad infinitum

FOR BONUS POINTS
It would be really sleek if you could download the available logs, maybe even as a zip file, from somewhere within the minera interface. Far from a requirement, also I feel like the interface might not be working in the hypothetical situation where I need to get at the logs - but still. I think that would be a worthy tradeoff for losing screen TUI access.

I just noticed you added a log viewer already, which is basically even better. I can't upgrade till I fix my sudoers issue but when I do I'll let you know if that has the logs i'm referring to.

Thank you very much for your nice words, I much appreciate them even more than a donation (while donations are great too )

Thanks for pointing me to ApplePI-Baker, I didn't know it, I like so much my terminal window but in this case it could be useful, I will give a try.

For the screen/daemontool issue, I understood your point of view and you are right, people who loves Minera don't love to SSH into it and screen -r when they can do the same (perhaps even better) by simply pointing their browser to an url, claro.
And yes, I just proposed a solution on 0.1.8 release that I think could be right for everybody (log viewer like tail -f in the dashboard and link to full log).

I tried the "-dmS miner" solution but that wasn't work, but before I give up I wanna try some more options, I will update you soon.

[edonkey]

[...]
I mean, this might be overly basic but you've tried

Code:

screen -dmS miner [command]

Im not familiar with daemontools but when I was writing daemons for launchd on the mac this would detach the screen session from the daemon so it would run when the daemon quits. This was a while ago on a different flavor of *nix so, not sure if that helps at all.

Personally, I wouldn't be too busted up about not being able to screen -r into the miner as long as there are some logs to review in the event of troubleshooting.
The entire reason I'm using minera is so that I don't HAVE to screen -r into the miner - which is how I was operating before just using cpuminer-gc3355 and a basic startup script.

If the last 'n' lines of miner output were available in a log file somewhere it would satisfy my needs at least, where 'n' is an arbitrary amount of logging that goes far back enough to enable troubleshooting but doesn't just fill up the disk ad infinitum

FOR BONUS POINTS
It would be really sleek if you could download the available logs, maybe even as a zip file, from somewhere within the minera interface. Far from a requirement, also I feel like the interface might not be working in the hypothetical situation where I need to get at the logs - but still. I think that would be a worthy tradeoff for losing screen TUI access.

I just noticed you added a log viewer already, which is basically even better. I can't upgrade till I fix my sudoers issue but when I do I'll let you know if that has the logs i'm referring to.

Thank you very much for your nice words, I much appreciate them even more than a donation (while donations are great too )

Thanks for pointing me to ApplePI-Baker, I didn't know it, I like so much my terminal window but in this case it could be useful, I will give a try.

For the screen/daemontool issue, I understood your point of view and you are right, people who loves Minera don't love to SSH into it and screen -r when they can do the same (perhaps even better) by simply pointing their browser to an url, claro.
And yes, I just proposed a solution on 0.1.8 release that I think could be right for everybody (log viewer like tail -f in the dashboard and link to full log).

I tried the "-dmS miner" solution but that wasn't work, but before I give up I wanna try some more options, I will update you soon.

+1 for no screen, good logging options (with rotation so that they don't fill up the disk), and reliable mining as a service (where the miner is launched at boot, and relaunched when crashed). The whole point of a GUI tool like Minera is to replace the text GUI with a nicer, more manageable one.

As mentioned before, I'm a fan of daemontools. It works great on my other rigs and solves all of my reliability and logging needs. But I'm fine with any service solution that michelem decides to use.

[SilentH]

had run the upgrade already on both.

Just did it again, no issues with he script. also ran the "redis-cli set guided_options 1" on the system with the greyed out buttons.

rebooted both boxes.

Gridseed Mini System: greyed out buttons still
Gridseed Blade system: still no logging

[michelem]

had run the upgrade already on both.

Just did it again, no issues with he script. also ran the "redis-cli set guided_options 1" on the system with the greyed out buttons.

rebooted both boxes.

Gridseed Mini System: greyed out buttons still
Gridseed Blade system: still no logging

Sorry forgot to push the latest commits. Please try:

Code:

redis-cli set manual_options 0
redis-cli set guided_options 1
cd /var/www/minera
sudo git reset --hard
sudo git fetch
sudo git pull
sudo ./upgrade_minera.sh

[SilentH]

Fixed both Issues..


Extremely happy with the product.

Just want to throw out a few wishlist items:

• Some Way to switch between pools with a click or two
• Someway to identify which tab is which system, maybe by throwing the hostname within the page title? once you have 2 or more raspberry Pi's open it starts to get confusing

Just wishes!


Thanks Again.

[chinatom]

Fixed both Issues..


Extremely happy with the product.

Just want to throw out a few wishlist items:

• Some Way to switch between pools with a click or two
• Someway to identify which tab is which system, maybe by throwing the hostname within the browser tab? once you have 2 or more raspberry Pi's open it starts to get confusing

Just wishes!


Thanks Again.

yep,i think switch pool  IS USEFUL to miner.

[michelem]

Fixed both Issues..


Extremely happy with the product.

Just want to throw out a few wishlist items:

• Some Way to switch between pools with a click or two
• Someway to identify which tab is which system, maybe by throwing the hostname within the page title? once you have 2 or more raspberry Pi's open it starts to get confusing

Just wishes!


Thanks Again.

Glad to hear that

Well, live pool switching is cool but before I can get it on Minera Sandor needs to put a API command to cpuminer, I don't think there is one now.

We can talk about this.

[fivejonnyfive]

Glad to hear that

Well, live pool switching is cool but before I can get it on Minera Sandor needs to put a API command to cpuminer, I don't think there is one now.

We can talk about this.

In the interim, it might be worth while to be able to reorder the pools in the list and then have a "save and restart miner" button that would relaunch cpuminer with the new configuration. Not as cool as live pool switching, but a serviceable substitute if you don't mind losing your autotune progress.

Although, there's a nifty idea for a feature - "save autotune results".

Basically you pull from the api the per chip frequency setting once the autotune process is done per chip. I don't know if it would be a pain to parse the log for the autotune complete messages. You could also just have it save autotune results after 12 hours or so.

Then you add those per chip settings to the miner's startup command.

There was a message in the cpuminer-gc3355 thread about a php script to output those frequencies formatted correctly for the startup command:

I didn't want to do autotune every time the miner restarted and manually entering the values every time was tedious. For some reason, the device names changed after upgrading the miner version.
I wrote a little PHP script that will query all the frequencies for the chips and format them into a command string to use with cpuminer. Now I can just wait for the autotune to finish and then copy and paste the output into the command string.

Code:

<?php
if(!($fp = fsockopen("127.0.0.1", 4028, $errno, $errstr, 0)))
{
    echo("Failed to open socket");
}
stream_set_blocking($fp, false);
$out = json_encode(array("get" => "stats"))."\n";
fwrite($fp, $out);
usleep(100000);
$out = "";
while(!feof($fp))
{
    if(!($str = fgets($fp, 2048))) break;
    $out .= $str;
}
fclose($fp);
$arr = json_decode($out,true);

$cm_string = "--gc3355-freq=";
foreach(array_keys($arr['devices']) as $devices){

foreach(array_keys($arr['devices'][$devices]['chips']) as $chips){
$fr = $arr['devices'][$devices]['chips'][$chips]['frequency'];
$cm_string = $cm_string."/dev/".$devices.":".$fr.":".$chips.",";

}
}
echo rtrim($cm_string,",");

And the output:

Code:

--gc3355-freq=/dev/ttyACM0:875:0,/dev/ttyACM0:875:1,/dev/ttyACM0:850:2,/dev/ttyACM0:875:3,......etc

You'd be wise to include something that correlates ttyACM0,ttyACM1 etc to a given serial number so if for some reason the miners change com ports it reverts back to autotune. Or at least warns the user that his/her custom per-chip frequencies are incorrect.

Anyway - that seems like a lot of work, or maybe it isn't - I only know how to code bash scripts. But I think a heap of users would enjoy it. I know I would.

And now that I'm thinking about it, I should be able to just pop that php in the settings page so it shows me the string right above the manual miner startup command settings. Once I have my rig tinkerable I might just do that.

[michelem]

Glad to hear that

Well, live pool switching is cool but before I can get it on Minera Sandor needs to put a API command to cpuminer, I don't think there is one now.

We can talk about this.

In the interim, it might be worth while to be able to reorder the pools in the list and then have a "save and restart miner" button that would relaunch cpuminer with the new configuration. Not as cool as live pool switching, but a serviceable substitute if you don't mind losing your autotune progress.

Although, there's a nifty idea for a feature - "save autotune results".

Basically you pull from the api the per chip frequency setting once the autotune process is done per chip. I don't know if it would be a pain to parse the log for the autotune complete messages. You could also just have it save autotune results after 12 hours or so.

Then you add those per chip settings to the miner's startup command.

There was a message in the cpuminer-gc3355 thread about a php script to output those frequencies formatted correctly for the startup command:

I didn't want to do autotune every time the miner restarted and manually entering the values every time was tedious. For some reason, the device names changed after upgrading the miner version.
I wrote a little PHP script that will query all the frequencies for the chips and format them into a command string to use with cpuminer. Now I can just wait for the autotune to finish and then copy and paste the output into the command string.

Code:

<?php
if(!($fp = fsockopen("127.0.0.1", 4028, $errno, $errstr, 0)))
{
    echo("Failed to open socket");
}
stream_set_blocking($fp, false);
$out = json_encode(array("get" => "stats"))."\n";
fwrite($fp, $out);
usleep(100000);
$out = "";
while(!feof($fp))
{
    if(!($str = fgets($fp, 2048))) break;
    $out .= $str;
}
fclose($fp);
$arr = json_decode($out,true);

$cm_string = "--gc3355-freq=";
foreach(array_keys($arr['devices']) as $devices){

foreach(array_keys($arr['devices'][$devices]['chips']) as $chips){
$fr = $arr['devices'][$devices]['chips'][$chips]['frequency'];
$cm_string = $cm_string."/dev/".$devices.":".$fr.":".$chips.",";

}
}
echo rtrim($cm_string,",");

And the output:

Code:

--gc3355-freq=/dev/ttyACM0:875:0,/dev/ttyACM0:875:1,/dev/ttyACM0:850:2,/dev/ttyACM0:875:3,......etc

You'd be wise to include something that correlates ttyACM0,ttyACM1 etc to a given serial number so if for some reason the miners change com ports it reverts back to autotune. Or at least warns the user that his/her custom per-chip frequencies are incorrect.

Anyway - that seems like a lot of work, or maybe it isn't - I only know how to code bash scripts. But I think a heap of users would enjoy it. I know I would.

And now that I'm thinking about it, I should be able to just pop that php in the settings page so it shows me the string right above the manual miner startup command settings. Once I have my rig tinkerable I might just do that.

Just added a "save current frequency" button.

Commit/push tomorrow

[fivejonnyfive]

Just added a "save current frequency" button.

Commit/push tomorrow

Next time you're in NYC you're drinking on my tab. That's awesome.

(Also, that sudoers file issue I was having was actually easily resolvable if I took the goddamn time to google it. *facepalm*)
http://askubuntu.com/questions/73864/how-to-modify-a-invalid-etc-sudoers-file-it-throws-out-an-error-and-not-allowi

[SilentH]

so on my blade rig, im trying to run each blade at its own freq.

when i do a manual setup and use the following line:

Code:

--gc3355-detect --gc3355-freq=ttyACM0:850,ttyACM1:850,ttyACM2:838,ttyACM3:838 --log /var/log/minera/cpuminer.log

After a restart all 4 blades default to 600. what am I doing wrong?

[christian1980]

Glad to hear that
Well, live pool switching is cool but before I can get it on Minera Sandor needs to put a API command to cpuminer, I don't think there is one now.
We can talk about this.

You could kill the mining process and restart it on another pool...

[dloganbill]

Is the latest version compatible with Nicehash yet? I'm holding off until it is.

Bump

[n00bminer]

Amazing work.

Mox235 pointed me to this and I am really happy.  Running 2 blades at 838 0 errors, and 5 infinity seeds @ 850.  the ramp up time on cpuminer is different for me, but the solid performance is a huge bonus.


Others have the wish list pretty well covered.  It is hard to let go of screen -x =) to see what is happening lol. I like scripta's backup/restore functionality.  I did not see cpuminer autotuning on the small seeds once I set a start freq though.


Thanks for the kickass work!

[SilentH]

Is the latest version compatible with Nicehash yet? I'm holding off until it is.

Bump

That has been answered in this thread already. As well as cpuminer  thread.  

Yes