chirale
|
|
September 11, 2013, 06:06:33 PM |
|
Hello guys, I have a quick question... I have been using my Pi with 1 USB asicminer for more than a month and has been working fine. I recently got another USB ASIC miner and I plugged it in, but is now giving a lot of errors. It recognizes the new Usb miner well, but if does not get any share, only errors. Plugged individually both usb miner work fine, but together one doesn't work.... Maybe I am missing something very obvious...tnx
|
|
|
|
RicRock
|
|
September 11, 2013, 07:06:26 PM |
|
Hello guys, I have a quick question... I have been using my Pi with 1 USB asicminer for more than a month and has been working fine. I recently got another USB ASIC miner and I plugged it in, but is now giving a lot of errors. It recognizes the new Usb miner well, but if does not get any share, only errors. Plugged individually both usb miner work fine, but together one doesn't work.... Maybe I am missing something very obvious...tnx
What kind of hub are you using?
|
|
|
|
|
|
chirale
|
|
September 12, 2013, 12:10:37 AM |
|
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?
|
|
|
|
RicRock
|
|
September 12, 2013, 12:11:30 AM |
|
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?
Pi ports don't have enough power to supply one I don't think They aren't powered per se
|
|
|
|
chirale
|
|
September 12, 2013, 12:18:09 AM |
|
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?
Pi ports don't have enough power to supply one I don't think They aren't powered per se It works fine with one USB miner, but not with 2... Tnx! I'll try a better hub!
|
|
|
|
tk1337
|
|
September 12, 2013, 12:44:49 AM |
|
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.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
September 12, 2013, 02:14:54 AM |
|
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
|
|
|
|
tk1337
|
|
September 12, 2013, 03:03:49 AM |
|
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...).
|
|
|
|
chanberg
|
|
September 12, 2013, 03:06:39 AM |
|
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.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
September 12, 2013, 03:52:34 AM |
|
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 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 ... 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).
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 ...
|
|
|
|
tk1337
|
|
September 12, 2013, 09:51:14 AM |
|
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.
|
|
|
|
KyrosKrane
|
|
September 12, 2013, 11:06:36 AM |
|
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.
|
|
|
|
tk1337
|
|
September 12, 2013, 11:28:14 AM |
|
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.
|
|
|
|
teletobi
|
|
September 12, 2013, 02:17:58 PM |
|
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.
|
|
|
|
cardcomm
|
|
September 12, 2013, 04:16:18 PM |
|
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. 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! :/
|
|
|
|
LogicalUnit
|
|
September 13, 2013, 04:45:10 AM |
|
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. 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! :/ Whenever I reboot my RPi, I need to restart ntpd and then cgminer to get reasonable results.
|
|
|
|
stellan0r
|
|
September 13, 2013, 08:38:47 AM |
|
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.
|
Allgemeine Gesundheitsberatung gegen Bitcoin-Zahlung. Bei Fragen einfach eine PM schicken! If you want to send a thank you: BTC "1PZJvKvarRviQRQWejpvXW2j4e1xbT8MZb"
|
|
|
ct1aic
|
|
September 13, 2013, 12:17:10 PM |
|
Oh no! Not again! cgminer: LATEST-IS-3.4.3
|
Rui Costa, Portugal - BTC : 1ct1aicGoUVpZeovsw3cCcPJZJHV5JXtW
|
|
|
|