At this point your better off you didn't. It's probably just me getting greeted with the pi's limitations but when I plug my powered hub in 2 usually don't light and the 3rd I have is solid light and none are noticed and even when they are , I call "sudo cgminer" and it asks for questions of what to connect to and closes. I've gotten ticked for the night and plugged them back into my pc.
I have yet to find info on autostart since I can't get it to call by itself and go and add more difficulty to the mix.
Should it make any problems that the wifi is on the same hub as the miners?
See my post here, https://bitcointalk.org/index.php?topic=246858.msg3156304#msg3156304 - it's my MinePeon setup (and you'll see the small Raspbian setup there as well), I put a message at the bottom about USB Wifi. The Raspbian installation doesn't have any issues with the Wifi dongle either plugged into the 2nd port on the rPi or on the hub or chained from a root hub on another hub (same dongle on both, the small $12 (USD) wifi from adafruit.com/newark/element14). Are you using MinePeon, Raspian or what distro? |
|
|
|
I tried that and got configure doesn't exist even though I see it does and then when I just for kicks try to send the make command it says makefile doesn't exist.
My pi is being sour. Are you using raspbian or something else on your pi with cgMiner?
Ah, yes, actually that rPi is indeed running Raspbian, it's easier to test with (and I wanted to test cgMiner 3.4.3 before putting it on the other rPi). Of which it keeps locking up after about an hour of usage. I keep the stable rPi running MinePeon (currently 0.2.3a). |
|
|
|
Running 20 currently, waiting for the rest of the hubs to come in. Best hub for $/per port I found was Rosewill RHB-500 (10 port, 8 usable. $22 @newegg.com), I tried the D-Link 7-Port, only seemed like 5 were usable, I tried a few other hubs (got about $120 in hubs to return at the moment), so far the Rosewill RHB-500 has been the best. I plan on maxing trying to max it out on the one rPi to see how many I can get going just with one rPi with MinePeon. Some pictures of my setup (not complete & dark, made from a NZXT Phantom case I had laying around), this setup is running MinePeon 0.2.3a (with some added stuff), still not done modifying the case, going to cutout a space for an lcd display on the side, remove the bay hard-drive bay (currently the rPi is sitting there, it will get moved to the back) to fit more hubs & fans, the PSU is getting switched out for one with less of a power draw (psu only controls the fans atm, it was all I had without ordering something). - Raspberry Pi Model B - ATXRasPi board (addon for rPi) - Currently 3x Rosewill RHB-500 10-port hubs - Currently 20x erupters - Some erupters have heat-sinks, some do not.    Here's my test Pi, running raspbian w/4 erupters.  ** Edit **I did forget to put in one thing, every time I try to use a USB Wifi and try to connect to it using 'sudo wicd-curses' it completely locks up I've tried it with the USB Wifi on a hub, on a hub replacing an erupter, on the 2nd USB port of the rPi, always fails. I want to try a different wireless manager for arch, but haven't got around to it yet, mainly because I have wireless-to-ethernet adapter (Trendnet TEW-647GA) which makes it still wireless, but wired to the rPi). |
|
|
|
I downloaded what I thought was the right file package minus that it was for 3.1.1 at the time and I can't use the make or configure options if needed to make this program go. I try to call it as it is and nothing pops up that indicates it working after changing the cgminer file to open as an executable. I'd just like to use the least amount of voltages and not kill my normal pc doing mining with my bitcoin eroupters. The file for 3.4.3 does not have a make file and "./configure" will not enable or disable features I hope This can be made to work Thanks below is the instructions for 3.1.1 but since 3.4.3 is missing what I think I need, its probably no help at all either. http://learn.adafruit.com/piminer-raspberry-pi-bitcoin-miner/install-cgminerMake sure you're downloading the correct file... wget http://ck.kolivas.org/apps/cgminer/cgminer-3.4.3.tar.bz2(you do *not* want http://ck.kolivas.org/apps/cgminer/cgminer-3.4.3-x86_64-built.tar.bz2) Other than that the directions there are pretty spot on, I have 3.4.3 installed on my Pi... however I will say, it's not being that stable, as I have it on my rPi test miner, running raspbian, it locks up about every couple of hours w/4 erupters on it, can't seem to determine why yet, will probably take it back a version, as the only thing that has changed on this is cgminer. Least my rPi with MinePeon is still kicking away with 20 erupters on it  |
|
|
|
Hi All. I just wanted to let everyone know that I've added a MtGox Bitcoin price ticker to the cgminerLCDStats script. I even added a cool colored arrow to indicate "price direction". Note that the ticker isn't really real time - there is a delay of a few seconds between updates, so don't use it for trading or anything time sensitive! I've tested the code pretty extensively on MinePeon v 0.2.2 with no problems. I'm not running v0.2.3 currently, but I HAVE done limited testing on that version. I welcome your feedback, and I hope y'all find the code useful. If so, please consider a donation  You can find the updated code here: https://github.com/cardcomm/cgminerLCDStatsInstructions on how to update cgminerLCDStats on MinePeon v0.2.3 to the current code can be found here: https://github.com/cardcomm/cgminerLCDStats/blob/master/MinePeon%20Install.mdAnd finally, here is a photo of the new screen setup:  nicely done. |
|
|
|
How do you expand the partitions?
yeah can I do that with a console command via SSH right into the Pi or do I need to shut down the RPi and do that on my Mac with an SD-Card reader? (or even worse, do I need to do that before I install Minepeon?) should be able to do it through ssh no problem, I haven't done it yet, the only thing is you may have to download a disk utility through pacman. I'll play with it tonight when I get home after work and post the procedure (unless someone else beats me to it). |
|
|
|
How long does a class 10 8GB SD card in an RPi with MinePeon last? In weeks/months? For a couple of days now my Pi is doing some odd things, like stopping mining/crashing. This morning my Peon was down for 8 hours (all Block Erupters green) but l could SSH into the machine and simply do a "sudo systemctl start cgminer.service" to get it mining again. 2 days ago I had to unplug the power cable from the Pi as it seemed to be hung up completely. Before that the Pi was running for over a month straight. Can this be the SC card? will it fill up with logs or other files at some point, or will MinePeon delete it if necessary? Could the SC card be degrading? I'm still on 0.2.2 because I am afraid to update  Maybe someone can make a new short guide on how to install and update the newest version of MinePeon + cgminer + the usb lcd screen (the one that was supposed to be working with 0.2.3a), just a rundown of the shell commands needed to get a working, not every couple hours rebooting miner. I noticed (last night actually) that you need to expand the partitions if you're on a SD Card that's over 2GB. I don't think log files should fill up that quickly, but I did notice that the default image is at 1.7GB for the main working partition, which it's taking up 70% on that, smaller partitions for the other stuff seemed fine. however, 350mb (+/-100mb) of play area for the main partition. |
|
|
|
|
I got this issue yesterday, tbh, it just means it couldn't locate the lcd display from the GPIO.
I'm starting to think a longer delay period before running CGMiner on bootup is a really great idea. As someone mentioned in the other post the factor of time (since there's no hardware clock) can skew CGMiners stats and more-than-likely cause a few other issues, I would imagine. So, I'm going to write a bash script to stage things, start processes in an order, then (if it's actually starting a process that should be constantly running) check said process to make sure it's running before starting the next item. I haven't really taken the time to look to the current script that starts CGMiner other than a few quick glances.
Granted on a bootup CGMiner might take a few to load, but I'd rather that then have random oddities.
|
|
|
|
The drop in long-term average hash rate to near zero is specific to the Pi, and probably to MinePeon. At boot time, the Pi's date starts at Jan 1, 1970. After a few minutes, a background task updates it to the right time. But in the interim, cgminer has started. So to get the average, it calculates your total hashes divided by run time. Since the apparent run time is over 43 years, the average is near zero.
A very logical response, thank you. I honestly didn't even think about the time issue playing a factor into this as I have a script on boot to set the time correctly, it should technically run before cgminer, but looks like it hangs sometimes. I will try delaying cgminer for a couple of seconds to let system scripts start, then run cgminer, I like the idea of a timed delay on the start of cgminer on bootup the more I think about it. Again thanks. |
|
|
|
Seeing how my first test of the issue was from miner.php, which showed the difference in the output as well, I don't think that was the issue. I do believe that something may be up with the read/write. After about 5 restarts of CGMiner today I got it to show correct stats, I noticed the avg rate was in kH/s which was odd, along with the shares being off (also odd), a couple restarts and now it's fine again. The SD card is about 2 days old (class 10, spec'd from eLinux.org wiki as completely compatible with rPi), also I have 5 other SD cards (all class 10, random sizes), so it would be easy to test that theory just by cloning the card. I'm going to monitor this a bit more, I have another rPi that will be here tomorrow, I'll play with it some there on the new rPi as well. I also have this problem. After boot up of the pi, and after cgminer has been hashing for about 10 minutes, it suddenly halts everything, stops for a second, then all the data values of GH/s turn to KH/s. Only the Average GH/s, turns to Kh/s, the 5second value of miner speed stays accurate and true. It's weird though, because when i started mining PPC coins, the cgminer was fine, worked great, but once i turn to mining BTC on BTCguild, it occurs almost spot on. Mining TRC is fine as well.. When i go into the WEBUI, the average values are at zero, but the 5second hash values are similar to that of cgminer when i SSH and do screen -r. Interesting, I've been recently mining on slush's vs. BTCGuild... yea I can quite pinpoint the randomness factor of it, but I'll play around with different pools now that you mentioned that. kano - As I've said before, the invalid results were showing regardless of which PHP script (using your miner.php, what minePeon is using (cgminer.inc.php), or my own also either on PHP, RUBY, C, or Python, but hey I'll go ask my co-worker today to write me a java app to just send some raw data over sockets). You're missing the point of all this, it doesn't matter which script is being ran to hit the API, the API is coming back with different stats than the output screen, after a few restarts of CGMiner, from my experience it goes away. So please stop trying to wrap your head around the calls (as if they were invalid calls, I wouldn't be getting the same data back with other people's scripts), problem is clearly stated, people seem to be having issues with it so far it is seemingly random unless there is a method recreation to where I (or someone else) can produce the issue every time on the spot. |
|
|
|
Seeing how my first test of the issue was from miner.php, which showed the difference in the output as well, I don't think that was the issue. I do believe that something may be up with the read/write. After about 5 restarts of CGMiner today I got it to show correct stats, I noticed the avg rate was in kH/s which was odd, along with the shares being off (also odd), a couple restarts and now it's fine again. The SD card is about 2 days old (class 10, spec'd from eLinux.org wiki as completely compatible with rPi), also I have 5 other SD cards (all class 10, random sizes), so it would be easy to test that theory just by cloning the card. I'm going to monitor this a bit more, I have another rPi that will be here tomorrow, I'll play with it some there on the new rPi as well. You still have yet to tell me what you are doing to cause the problem. How are you getting this problem, what data are you sending to the API and how are you sending this data to the API Again, the API is a simple text protocol, no binary, no hex, all simple text. My miner.php simply sends text to the cgminer API and gets back text replies. So I don't get what the true/1 issue is. Yes I've written 10's of thousands of lines of PHP I do understand that one can make such mistakes, but they don't exist in miner.php as far as I know ... If you've found a bug in miner.php - report it, you seem to know a little about PHP, so you should be able to clearly point out what is happening. P.S. 'summary' has no parameters For someone to say they know anything about programming and not know references (or differences) between an INT or BOOL is beyond me, very basic stuff right there.. I've clearly stated it could be a combination of things (CGMiner,I/O w/ SD Card). I've already proved it was at the application level, by restarting CGMiner several times before finally getting the correct data returned through API calls. Which seems semi-isolated and almost random (for me) however other people have reported incorrect readings between the output screen and what MinePeon's WebUI is showing, which is coming from the UI. So far I personally have seen incorrect speeds, invalid share totals and a few other minor things, all of which eventually get flushed out after restarting CGMiner (usually about 4-5 times after a reboot of the Pi). Please stop saying you wrote miner.php, you've said it enough times, I don't care because I'm not using it for anything other than to compare data results from the API call (also, it doesn't look like the latest release of MinePeon is calling/including miner.php anywhere now). I'm not pointing a finger at you, but you seem to somehow think I am? So you're continually trying to defend yourself it seems. I'm glad you know how to send text over sockets, wonderful. I used it (miner.php) along with cgminer.inc.php and my own code to try and see if I was getting the same results as OTHER PEOPLE were reporting and I did... Also, nice touch trying to "dick measure" with the '10's of thousands of lines of PHP' (yet you still use globals? (in miner.php, everywhere) finding that hard to believe...). |
|
|
|
Seeing how my first test of the issue was from miner.php, which showed the difference in the output as well, I don't think that was the issue. I do believe that something may be up with the read/write. After about 5 restarts of CGMiner today I got it to show correct stats, I noticed the avg rate was in kH/s which was odd, along with the shares being off (also odd), a couple restarts and now it's fine again. The SD card is about 2 days old (class 10, spec'd from eLinux.org wiki as completely compatible with rPi), also I have 5 other SD cards (all class 10, random sizes), so it would be easy to test that theory just by cloning the card. I'm going to monitor this a bit more, I have another rPi that will be here tomorrow, I'll play with it some there on the new rPi as well. |
|
|
|
okay, need to go to sleep, I keep screwing with this...
I changed the parameter to the API call to a integer (1) rather than a boolean (true) and now I'm getting a different set of data back that is actually correct.
Gives me something to go off of, I'll look at it more in the morning.
I've got no idea what you are referring to there. I wrote the cgminer API, but yeah I need a little more information to make any sense of that. Basically, when passing the command & parameter to the API from PHP, it seems to like an integer to be passed rather than a boolean. Something PHP might be doing odd on the write to the socket, who knows, some times there is some strange shit that pops up. $command = 'summary';
$parameter= 1; Rather than $command = 'summary';
$parameter= true; PHP will parse 1 as true (and 0 as false) unless explicitly defined... ie: if($foo == 1)() is the same as if($foo == true){} (also if($foo == '1'){} and if($foo == "1")() even though technically the 1 is a string in the last example, PHP doesn't really care), unless you specifically look for a boolean like so, if($foo === true){} or if(is_bool($foo) && $foo == true){} When I'm passing it to the API socket as true, it seems to not like it for some reason, but it's fine with it as an integer, someone on the CGMiner thread did bring up an interesting thing about SDCard read/writes and I have about 10 SDCards at the house, so I may clone the card and just check that. I'm at work now, if I survive the day with no sleep, I'll try a few things and post more info later today. |
|
|
|
|
okay, need to go to sleep, I keep screwing with this...
I changed the parameter to the API call to a integer (1) rather than a boolean (true) and now I'm getting a different set of data back that is actually correct.
Gives me something to go off of, I'll look at it more in the morning.
|
|
|
|
|
actually, odd, I was going to dump the output of the api call to a file, decided to change the parameter to an INT (1) instead of a BOOL (true) and now I'm getting back correct data...
that gives me enough of a lead to where I can figure it out (or at least get the correct data to show), thanks for the responses.
|
|
|
|
Okay, I wrote a separate connector to the cgMiner API (just to rule out anything currently in MinePeon)... and it appears that the response from CGMiner is actually returning different data than what it's showing on the output screen. Could be a bug in the latest CGMiner release.
Edit: With 623 pages on the CGMiner thread, not sure if the issue has already been reported, but definitely seeing a 1319 accepted share difference for each USB Erupter I have going at the moment. However I made a post there, we'll see if anything becomes of it, it could be some kind of offset (maybe?) or just a bug in the API callback.
If it's any help, my LCDStats screen is outputting the correct figures. hm... that is interesting. I'll work on this more tomorrow, I need some sleep. |
|
|
|
It appears that the API is reporting a different number of accepted shares than what is being shown on the output. Not sure if this is intentional for some reason or if this is an already known issue (sorry, not going through 600+ pages). Small example: CGMiner Output screen says 8105 accepted shares, the API returns 6786 for said device (1319 difference, seems to be across the board for each device).
Please let me know if you would like me to supply the data from the API vs. data on the output.
Maybe you're using a pool with variable difficulty and you're at a hashrate that keeps you bouncing around between difficulty 1 and 2 shares? I would assume CGMiner's API would report the same data as what it's showing to the user on the output screen. Otherwise either the output screen or the API would be incorrect at all times. |
|
|
|
It appears that the API is reporting a different number of accepted shares than what is being shown on the output. Not sure if this is intentional for some reason or if this is an already known issue (sorry, not going through 600+ pages). Small example: CGMiner Output screen says 8105 accepted shares, the API returns 6786 for said device (1319 difference, seems to be across the board for each device).
Please let me know if you would like me to supply the data from the API vs. data on the output.
Nope, I don't see it on any of my 4 instances. You'll need to provide more info. Also ... try java API summary and java API devs and compare those outputs to the screen. CGMiner API summary reports a total accepted as 47634, CGMiner output shows the total as 57407, a difference of 9773 divide that by the number of devices (7), looking at a difference of around 1396 per device. I'm falling asleep here, but I'll post screenshots & data to back up this tomorrow morning. Edit: This is on linux (MinePeon distro) with ASIC USB Erupters only, however others are reporting an error with BFL devices as well on the same distro, I wrote a stand alone call (separate from MinePeon's WebUI) to see if there was any difference in what the WebUI was getting from CGMiner API versus what the WebUI was showing. Turns out, there is no difference in the WebUI on MinePeon's side, but it appears the difference is coming from CGMiner's API, as at the time of the call the numbers are off from what what the output screen is displaying. |
|
|
|
I know that the first step would be to check the MinePeon logs, but I don't know where they are saved.
Not sure if you saw my response in the MinePeon thread, but the system log files are located: /var/log/
sudo cat /var/log/auth.log
sudo cat /var/log/crond.log
sudo cat /var/log/daemon.log
sudo cat /var/log/errors.log
sudo cat /var/log/everything.log
sudo cat /var/log/faillog
sudo cat /var/log/kernel.log
sudo cat /var/log/lastlog
sudo cat /var/log/messages.log
(Use sudo cat to output the entire contents of the file or you could do sudo tail -n [number] /var/log/[filename].log (Example: sudo tail -n 50 /var/log/auth.log would give me the most recent 50 entries within that file.) auth.log = authorization systems log crond.log = crontab log / cron jobs daemon.log = system & application daemons (usually background processes) errors.log = system errors. everything.log = *should be **everything*** (hehe) faillog = login failure log. kernel.log = messages from the linux kernel lastlog = login log messages.log = general messages and system notices. |
|
|
|
|
It appears that the API is reporting a different number of accepted shares than what is being shown on the output. Not sure if this is intentional for some reason or if this is an already known issue (sorry, not going through 600+ pages). Small example: CGMiner Output screen says 8105 accepted shares, the API returns 6786 for said device (1319 difference, seems to be across the board for each device).
Please let me know if you would like me to supply the data from the API vs. data on the output.
|
|
|
|
|
Show Posts
