Topic: Linux mining distro for the Raspberry PI - MinePeon - page 66. (Read 685140 times)

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.

Hey for some reason the email alerts does not work ? I'm using stmp.gmail.com anyone else having issues with getting emails from gmail for this?

Oh no! Not again! cgminer: LATEST-IS-3.4.3

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.

Whenever I reboot my RPi, I need to restart ntpd and then cgminer to get reasonable results.

Yeah, the lack of a RTC on the Pi doesn't seem like a big deal at first, but it can be a real PIA sometimes! :/

I'm using the same just with another branding. It works well with 5 USB Miners. For over a Month now. have You tried different USB Cables? Sometimes it helps to cut the red cable of the Connection, but I didn't.

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.

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.

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.

I know the exact difference, however, I've no idea why someone would send the wrong one in the php code they wrote.
As I said "So I don't get what the true/1 issue is."
... since miner.php doesn't have this issue anywhere as far as I know ...

No - you've said you wrote your own php using parameters that were incorrect, data types that were incorrect, and got unexpected results.
But you won't say exactly what you did in php so I can work out what's going on.
Fine I give up - have fun with it.

Oh and hint ... java API ...

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.

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...).

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

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.

It works fine with one USB miner, but not with 2... Tnx! I'll try a better hub!

Pi ports don't have enough power to supply one I don't think

They aren't powered per se

Tnx!
The problem is that it doesn't work even if I plug the two USB miner in the Pi USB ports... Is that a know problem?

Should really try to stick with one that is confirmed compatible

http://elinux.org/RPi_Powered_USB_Hubs

Probably not a good one...
USB 2.0 HUB Powered 7-Port high speed+Free AC Adapter

http://www.ebay.co.uk/itm/370812764010

Tnx for help