Yeah, for a while now I've been asking for the feature of being able to set the frequencies by serial number, not dev node. But I don't think Sandor111 has added that yet.
It's really the only way to do this reliably though. It's too hard otherwise to match the dev node to the right frequency set.
Your request has been fulfilled, it was a small change.  Wow! That's great news Sandor111! So was this change just committed? If so I'll do a pull and rebuild. I guess the syntax is indicated in the new help? Presumably I can set the frequency by serial number in a config file, like other options? I'll play with it on my test rig. Looking forward to moving completely to cpuminer and Minera on my main rig. |
|
|
|
i just made a test too.
After booting the Rasberry, the Grid Numbering has been shuffled and so the stored frequencies don't match to the grids anymore.
Looks like the ttyACM Numbers are not bound to the serialnumber of the grid.
screen -r on the console also shows me another order of the grids, then minera does
Yeah, for a while now I've been asking for the feature of being able to set the frequencies by serial number, not dev node. But I don't think Sandor111 has added that yet. It's really the only way to do this reliably though. It's too hard otherwise to match the dev node to the right frequency set. |
|
|
|
It's probably being started to early, when the filesystem and networking aren't fully initialized yet. One solution would be to add a sleep 30.
Thanks for getting back to me. I guess I can change rc.local to call a script that either implements a delay or calls something that waits for resources to be available. |
|
|
|
I'm using cpuminer v1.0a under Ubuntu 12.10. I've got the minerd application set to load via rc.local as part of a Minera installation. I've got a problem after a reboot where minerd goes into a weird state where it doesn't hash anything. When I grab the stats with a python script I wrote, I see the following weirdness: {
"start_time": 1399756136,
"err": 0,
"devices": {
"ttyACM1": {
"serial": "6D89577A4857",
"chips": []
},
"ttyACM0": {
"serial": "6D8A21A34857",
"chips": []
},
"ttyACM2": {
"serial": "6D8E40854857",
"chips": []
}
}
}
If I manually stop and start minerd, it starts working. But that kind of the defeats the purpose of the auto restart feature. Any ideas what might cause this? Maybe minerd is being launched too early, where certain system resources are not yet available? I posted this in the Minera thread, but it seems like this is an issue with cpuminer being started under rc.local. |
|
|
|
For better or worse, I'm part of the "Big ASIC Massacre of 2014" in a small way. I've mostly used ASICs, with just a bit of GPU dabbling. So I for one hope that suchmoon keeps at least some reasonable representation of scrypt pool options. As far as the massacre is concerned, is there any one event that's got you concerned suchmoon? Or is it just that ASICs will continue to gain momentum and lead to the same arms race as happened with bitcoin? When you look at the ASIC options out there, few of them have any hope of an ROI. I knew that getting into this, but I was more interested in learning about crypto currencies and having fun. This chart pretty much sums it up: https://docs.google.com/spreadsheets/d/1msn9gC7wgBYdiyOLZLhQifOSKpt3ukdnuTy14m-F-s8/edit#gid=1966313813Of course math doesn't stop people from buying unprofitable rigs. The scary ones are the products that haven't shipped yet and actually appear have a decent ROI. If the KnC Titan and Mini Titan actually ship before the bottom drops out of the scrypt market, and if they can ship in quantities needed to meet demand, it looks like they could have a major impact. I have to admit that 150 Mh/s for under $6k and an ROI of a month is pretty interesting... |
|
|
|
[...] I mean, this might be overly basic but you've tried 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 POINTSIt 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. |
|
|
|
I've mined mostly on CleverMining and WafflePool. I'm back on CleverMining because WafflePool has had profitability problems recently. Usually CM and WP are pretty close in profitability, according to suchmoon's awesome charts. So I expect that WP's slump will be over at some point. For now I will stay on CM because multi-pools are all about averages and it doesn't pay to pool hop too much. But at some point when the profitability argument is gone, I will likely return to WP. Why? Because I prefer some of the service features that WP offers. Here's a summary of what I like: - Individual workers for the same BTC address - I really like being able to easily see the poolside hash rate of individual rigs without having to deal with multiple addresses. Of all the pools I've mined, CM is the only one that doesn't have this feature.
- Lots of statistics - I like being able to see the recent work shifts, earnings log, and coin balances. It gives me a sense of momentum that you don't get from CW's arguably prettier, but more static site.
- API - There are several WP applications out there that do a really nice job of providing statistics, graphs, etc. Some are web apps, and some are mobile apps. A clean API enables this kind of development by third parties. That in turn increases the value of the service.
- Better visibility - I get the argument that Terk needs to keep wraps on what coin is being mined. But with CM there is no visibility at all into what's going on. WP does a much better job there, although it does sometimes have "hidden" coins (as during the whitecoin pump and dump). And usually, recent slump aside, WP competes nicely with CM profitability wise, so increased visibility doesn't seem to be hurting WP.
I'm know that none of the above feature requests are new. I just want to add my voice to what I'd like to see. While I hope that CM maintains high profitability, and that's the biggest "feature" there is, my guess is that that won't always be the case. Profitability ebbs and flows, and the "whale" splashes between the pools. What I would like to see is CM be more competitive from a feature perspective other than just profitability. That way when profitability equals out again (and it will), I'll have fewer reasons to go back to WP. Just to be clear, I'm not posting this to make people defensive or start a thread war. I'm just indicating features do matter to some of us. And when profitability is a wash, features win. |
|
|
|
|
Michelem09, can you think about moving your logs to /var/log? It makes a bit more sense than having logs in a subdirectory of www.
Also, some of us (er, I might be the only one) are using ramlog on our Raspbery Pi's to avoid SD flash wear and tear. If you move your logs to /var/log, then they will automatically take advantage of writing the logs to a ram disk mount point.
If you can't do this, no big deal. I guess I can make a symlink from your directory to /var/log. But that means some maintenance when I do an update of Minera. Maybe I'll pull together a post update script...
Also, I still have no fix for the problem where rebooting leaves cpuminer in a bad initial state on Ubuntu 12.10. Should I bring this up with Sandor111 in the support/tuning thread?
|
|
|
|
So what are these more profitable places or are you just bitching without better knowledge as 75% here? Judging http://poolpicker.eu/text differences seem negligible  PoolPicker uses pool reported profit values from APIs instead of actual testing rigs. Decent reference but there are other more complete and accurate sources of comparison data. Try suchmoon's comparison charts: https://bitcointalk.org/index.php?topic=514242.0They'll show you better profit comparisons based on actual hashpower across more pools and leasing services. There are quite a few higher profit choices. +1 for suchmoon's comparison thread! |
|
|
|
Please check the troubleshooting section for "Cannot open your terminal" error I'm going to think about add a daemon tools like you suggested but I prefer to use supervisord I think it's more modern and easy to use. For the reboot problem, please can you paste me your /etc/rc.local file? May be when you save the settings from Minera it cannot write the rc.local file, so double check 1) rc.local permission should be 777(-rwxrwxrwx) 2) the content of rc.local If you find your permissions wrong run: sudo chmod 777 /etc/rc.local Then go to settings and save them (when you click the save button Minera recalculate the command string and overwrite the rc.local file) Please let me know PS I just added a cool temperature widget, wait for the next release Thanks for getting back to me. Also thanks for the troubleshooting tip. I tried what it said and it worked. The permissions of rc.local are world executable, as you've indicated: -rwxrwxrwx 1 root root 426 May 10 13:24 /etc/rc.local
Of course since minerd is running at boot, I don't think it's a permissions problem. It's just not hashing or behaving properly. Here's the contents of rc.local: #!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
su - minera -c "/usr/bin/screen -dmS cpuminer /var/www/minera/minera-bin/minerd --config /home/minera/config/minerd.config"
exit 0
FYI, the config file is world readable: -rw-r--r-- 1 minera minera 808 May 10 13:35 /home/minera/config/minerd.config
Here's my config file contents (with my user info obscured): {
"gc3355-detect" : true,
"freq" : "850",
"gc3355-freq" : [
"/dev/ttyACM2:950:0", "/dev/ttyACM2:925:1", "/dev/ttyACM2:925:2", "/dev/ttyACM2:925:3", "/dev/ttyACM2:925:4",
"/dev/ttyACM1:900:0", "/dev/ttyACM1:875:1", "/dev/ttyACM1:900:2", "/dev/ttyACM1:900:3", "/dev/ttyACM1:900:4",
"/dev/ttyACM0:875:0", "/dev/ttyACM0:900:1", "/dev/ttyACM0:900:2", "/dev/ttyACM0:900:3", "/dev/ttyACM0:900:4"
],
"pools" : [
{
"url" : "stratum+tcp://sf.clevermining.com:3333",
"user" : "user",
"pass" : "x"
},
{
"url" : "stratum+tcp://doge.ghash.io:3333",
"user" : "user.minecraft",
"pass" : "x"
},
{
"url" : "stratum+tcp://uswest.wafflepool.com:3333",
"user" : "user_minecraft",
"pass" : "x"
}
],
"debug" : true
}Note that I'm using a newer version of cpuminer that supports the "pretty" config file format for device frequencies. Also, I've changed the binary at /var/www/minera/minera-bin/minerd to a symlink to my built and installed version. I did this because I want to be able to rev versions of cpuminer separately from Minera. As an aside, I realize that if there are API differences it could result in breakage between Minera and my version of cpuminer, but so far you and Sandor111 have keep pretty well in sync. Doesn't seem like I'm living too dangerously... Just to be sure, I checked and there's only one copy of minerd running (it looks like two, but the first one is screen): ~$ ps auxwww | grep -i [m]inerd
minera 2362 0.0 0.0 5512 1472 ? Ss May10 0:08 /usr/bin/SCREEN -dmS cpuminer /var/www/minera/minera-bin/minerd --config /home/minera/config/minerd.config
minera 2363 0.4 0.1 99152 3080 pts/3 Ssl+ May10 4:07 /var/www/minera/minera-bin/minerd --config /home/minera/config/minerd.config
Maybe the issue is that the rc.local mechanism is starting cpuminer too soon in the boot cycle? Maybe the "gc3355-detect" is failing when run too early? Again, I should mention that I'm running under Ubuntu 12.10 on my test rig. It's not a Raspberry Pi. I'm not that familiar with the rc.local launch mechanism. Maybe there's a way to delay running until later in the boot process? Or perhaps I could change it to call a script that waits for kernel resources (like the network) to be up before starting minerd. Regarding daemontools verses supervisord, I don't have a strong preference. I'm just used to daemontools, and I like D. J. Bernstein's work. But either package would be fine. Again, thanks for getting back to me. Minera is really an awesome application. I've tried MineNinja and Scripta. Minera, in combination with Sandor111's cpuminer, is hands down the best I've used so far. You both should be proud of your work. |
|
|
|
I've moved my Ubuntu based test rig to Minera today. I've mostly got it working, with a few issues. Like others on this thread, I couldn't get the cron jobs to work until I installed the PHP cli: sudo apt-get install php5-cli
I was working from the read me on git hub. I think that it should be updated so that other newcomers can avoid this problem. Looks like this just got added to the read me. Thanks!
A more important issue is that when I reboot, cpuminer goes into a weird state where it doesn't hash anything. When I grab the stats with a python script I wrote, I see the following weirdness: {
"start_time": 1399756136,
"err": 0,
"devices": {
"ttyACM1": {
"serial": "6D89577A4857",
"chips": []
},
"ttyACM0": {
"serial": "6D8A21A34857",
"chips": []
},
"ttyACM2": {
"serial": "6D8E40854857",
"chips": []
}
}
}
Note this is with minerd being started from rc.local, as per the Minera installer script. When I stop and restart the miner from with the Minera GUI, it starts working. I'd really prefer to start minerd as a daemontools service with full logging, but when I tried that, Minera thinks that the miner has not started. Apparently it uses some mechanism other than just trying to talk to the API. I didn't try hacking Minera to support alternative launch methods, but I might take this on if I have no better solution for rebooting and reliably restarting minerd. Since the default installation uses screen to run minerd, I tried to switch to the "minera" user and attach to the screen, but I get an error: Cannot open your terminal '/dev/pts/2' - please check.
I'm not a big fan of screen anyway, but if I cannot reliably attach to the miner GUI then it's not providing any value at all. Again, I might turn to daemontools and run minerd in text mode (no text GUI) if I can figure out how to get Minera to play nicely with it. I'd love to move my main rig to cpuminer and Minera, but I need to work through these issues on my test rig first. |
|
|
|
|
Unfortunately I've reached my limit too and have moved to another pool.
I really love this pool though, so when reasonable profitability returns, so will I.
|
|
|
|
This is my result with latest Cpuminer on one Vmodded GS
Nice! Which voltage mod did you do? Last I checked there were a bunch of variations. |
|
|
|
Have a great trip Suchmoon. Don't stress about updating the thread. We can live without fresh numbers for a few days Wafflepool has been kind of, er, waffling lately. It's too bad because I really like its transparency and stats. It's kind of hard to justify moving to CleverMining because the difference isn't that great. Although you probably can't go too wrong playing "follow the whale." I've got mostly GSD ASICs so the scrypt-N and X-11 pools are out for me. But TradeMyBit seems to be doing really well in the 10 day average. I assume that the "TradeMyBit" numbers are for their scrypt multi-pool, right? I searched the thread and it looks like you added them on April 20th, but I just want to be sure that those posted numbers are for the multi pool. Thanks in advance. Yes, TradeMyBit is Scrypt, I guess I should add "Scr" to it. Just keep in mind that its numbers are inflated by one lucky day when they mined ShibeCoin when big pools didn't. You can see that bump on the big chart. Otherwise they are about on par with the other pools. Although it stands to reason that being a smaller pool they are more flexible and will be able to jump on the next meme when it comes along. It's your hashes to gamble, I'm just a messenger Ah, I missed the fact that they were early ShibeCoin adopters. Thanks for pointing that out. |
|
|
|
Have a great trip Suchmoon. Don't stress about updating the thread. We can live without fresh numbers for a few days Wafflepool has been kind of, er, waffling lately. It's too bad because I really like its transparency and stats. It's kind of hard to justify moving to CleverMining because the difference isn't that great. Although you probably can't go too wrong playing "follow the whale." I've got mostly GSD ASICs so the scrypt-N and X-11 pools are out for me. But TradeMyBit seems to be doing really well in the 10 day average. I assume that the "TradeMyBit" numbers are for their scrypt multi-pool, right? I searched the thread and it looks like you added them on April 20th, but I just want to be sure that those posted numbers are for the multi pool. Thanks in advance. |
|
|
|
I've been using auto-tune on a test rig for a few days and it's been rock solid. Thanks so much to Sandor for all the hard work. This is really shaping up to be the best mining software for GSDs out there. As I understand it, I can harvest the auto-tune results of per chip frequency values from the API. I can use toxic0n's PHP script to do that. But it looks like the frequency specification is on a per device node basis. I suspect that the dev nodes can change when rebooting, or if you add or remove GSDs. It seems to me that in order to really make auto-tune useful, you need to be able to specify the frequencies on a per serial number basis, not per device node. And as cool as toxic0n's script is, I think that cpuminer should output the results of auto-tune so that it can be easily used for future launches. So here's the features that I'd like to see to round out auto-tune: - Add something in the main GUI indicating the status of auto tune. It would be nice to have an idea of how far it has to go without using the --debug option and scanning the log output.
- Add the option to specify the frequency by GSD serial number so that it will always work for known units, regardless of the order of device discovery.
- When quitting cpuminer and autotune is done, output the command line options that could be used in subsequent launches. Ideally this would be the serial number based frequency specification.
Sandor, thanks in advance for thinking about these features. |
|
|
|
Is 24 hours really enough for auto-tune to do its work? I thought it could take a while to figure out the optimal clocks.
If it takes over 24 hours to achieve best results, I'm not interested. That would mean every pool change, software update, reboot, power blip, etc would require it to start from scratch. That doesn't work for me. My understanding is that the auto tune feature maximizes the frequency for the hardware, and that that is unrelated to pool changes. You can use the API to obtain the frequency values after auto-tune is done and use those to create the command line for any subsequent runs. In fact, this person coded a PHP script to do that: https://bitcointalk.org/index.php?topic=482352.msg6603449#msg6603449Note that in order to tell when auto-tune is done, you should use the --debug option. |
|
|
|
cpuminer-gc3355 v0.9g * Failover pool strategy is supported * Low reject rate (--no-refresh -> disabled) --url=stratum+tcp://pool1:port --userpass=user1:pass1 --url=stratum+tcp://pool2:port --userpass=user2:pass2 --url=stratum+tcp://pool3:port --userpass=user3:pass3 Pool 1 is the main pool, if it is down, it will try to connect to the backup pool(s) and query the main pool until it is back up and switch pools automatically. Will add support for config file soon. Wow! You are amazingly responsive! Thank you so much! |
|
|
|
|
A couple of feature requests for Sandor's cpuminer.
It would be great if cpuminer directly supported failover to other pools, with the option to return to the primary pool. As it is, it looks like the dev suggests a script with multiple calls to minerd, where a different pool is specified on each command line. While I can see that this kind of works, the result is that the miner will be stuck on alternate pools until those pools fail.
In my case with cgminer, I have my primary pool set to a multi-pool. When fails, the rig points at a fixed coin pool. When the primary comes back online, it points back to the primary.
The reason why I have it configured this way is because I prefer the multi-pool for profitability. But when it's down I don't want to point the rig at another multi pool because it's usually for only a brief time, which often results in not meeting the minimum payout, and dust sitting in the secondary pool forever. It's much cleaner to just mine a single coin for a brief time while the primary is out. That way there are no exchange issues.
The second feature request is for support of a config file. It would be great to be able to specify options in a JSON config file rather than on the raw command line. This would especially be useful to specify auto tune derived frequencies (which can be large for bigger rigs).
Also, if the failover feature is implemented at some point, it's cleaner to specify multiple pools and user credentials in a config file rather than on the command line.
|
|
|
|
Auto tune isn't going to affect or be affected by any pool changes - all it's really doing is optimizing the settings for your specific hardware, and those settings will be the same regardless of pool or coin.
Basically, each gridseed chip on the miner can be told to run at a different rate. Higher rates mean more hashpower, but too high for the chip and you'll just get errors and not actually see any results for your hashpower.
The simplified explanation of how auto tune works is it slowly increases the operating speed of each chip until it starts to see errors and then backs off a bit until the error rate is stable. The result is your hardware will be operating at the highest speed it is capable of without producing errors.
I thought it was a gimmick when I first started using it - my miner would autotune and stay at 850 where i started it - BUT when I bought two more, one comfortably runs at 930-950 sometimes nudging above 400kh. Go figure.
Anyway - once you autotune once, the numbers per device and chip are basically established and aren't going to really change boot to boot. The idea is by starting with those instead of autotuning, you aren't wasting time running at subprime efficiency until the tuning process completes.
Thanks for getting back to me. That's a good explanation. For some reason I thought that some hardware errors could be the result of pool changes. I've got the latest version running under Ubuntu on a test rig with 3 GSDs with auto tune on and it's set frequencies between 895 and 930 MHz. Looking good so far. This is far easier than cgminer. It took me something like a week to tune my other rig, and I only bothered to tune per unit, not per chip, because it was too time consuming. I plan to move to minerd and Minera on my main rig this weekend. |
|
|
|
|
Show Posts
