Well its weird. When I screen -r I see bfgminer and cgminer my hardware errors are just around 2%~ But when I check out Minepeon it says the average of both singles is 51%. With bfgminer some engines even display 98% hardware errors. Not sure whats going on. I'm getting the same issue, and I think there is a bug in the number of accepted shares being reported. Reported shares on the web UI are roughly one tenth of actual shares. Maybe someone's deleting a zero somewhere. . . It does appear that my accepted shares are off by about 1300 / per miner, from cgMiner's stats to the stats being displayed on MinePeon's webUI. Since I'm only running erupters, I could see where something on a larger scale could report much higher. Going to take a look at the code since I'm awake (and shouldn't be). 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.
|
|
|
Well its weird. When I screen -r I see bfgminer and cgminer my hardware errors are just around 2%~ But when I check out Minepeon it says the average of both singles is 51%. With bfgminer some engines even display 98% hardware errors. Not sure whats going on. I'm getting the same issue, and I think there is a bug in the number of accepted shares being reported. Reported shares on the web UI are roughly one tenth of actual shares. Maybe someone's deleting a zero somewhere. . . It does appear that my accepted shares are off by about 1300 / per miner, from cgMiner's stats to the stats being displayed on MinePeon's webUI. Since I'm only running erupters, I could see where something on a larger scale could report much higher. Going to take a look at the code since I'm awake (and shouldn't be).
|
|
|
I am running two BFL Singles at the moment with Minepeon. I am getting 58% hw errrors. This isnt right is it?
surely doesn't seem right... if I had access to a BFL, I'd know more to help ya, sorry.
|
|
|
SSB, you rock man... came home yesterday to two nice boxes
|
|
|
Need help: cgminer 3.3.4 on MinePeon 0.2.3a restarts every few hours. Can someone tell me how to look at the log files?
Your typical linux log files are in /var/log/ to read the log files within you will need to use sudo Examples: sudo tail errors.log sudo cat messages.log
Going off of the dates of the files from within /var/log/, it looks like the log files that are being used by the system are: auth.log crond.log ddemon.log errors.log everything.log faillog kernel.log lastlog messages.log So if you know what you're looking for in regards to linux OS, then it should be simple for you to find it.
|
|
|
Pretty nice. I installed it on my Ipad but it looks like there is nothing to connect it with CGMiner on Minepeon? Any ideas on a date?
Thanks, IAS
Right now, my only gripe is a short 'hack' I did for the stop/start commands, which I have a more thought out way of doing it but would require a change within MinePeon (possibly), going to shoot off a message to Neil today. I see stellan0r mentioned an API running on his Rpi. Is this what you are referring to with the stop/start commands? I just want to be able to monitor things while I'm away from the house. Does this API do that? (And is it on your website?) Thanks It's about sharing stellan0r is referring to the API within CGMiner that allows MinePeon's WebUI talk to CGMiner (to provide stats, etc...) stellan0r - The issue you experienced basically means at some point the WebUI wasn't able to communicate to the CGMiner application (for whatever reason), from my experiences, CGMiner will try to restart itself on error within MinePeon (believe that's an option, can't remember atm, I know if I kill the cgminer process it will instantly come back up), with that being said, if the WebUI tried to pull stats from the CGMiner application during a restart (or if CGMiner was down) then it's going to fail communicating to CGMiner on port 4028 (which is the default API port for CGMiner) in the CGMiner configuration it is setup to only allow API requests from the localhost (so don't freak out thinking someone else can connect to it). Actually, on 0.2.2 I can hit the cgminer API from any box on my local subnet (still plenty secure). I wonder if this changed on the latest release? I'm gonna try and put the latest on my test Pi today. I can't remember the setting exactly, but I don't believe it's being explicitly set to 127.0.0.1 - Plus I haven't read the CGMiner API documents full, but I know from what I did read you can set the range, if you wanted to limit it to certain ip ranges on your local subnet.
|
|
|
Pretty nice. I installed it on my Ipad but it looks like there is nothing to connect it with CGMiner on Minepeon? Any ideas on a date?
Thanks, IAS
Right now, my only gripe is a short 'hack' I did for the stop/start commands, which I have a more thought out way of doing it but would require a change within MinePeon (possibly), going to shoot off a message to Neil today. I see stellan0r mentioned an API running on his Rpi. Is this what you are referring to with the stop/start commands? I just want to be able to monitor things while I'm away from the house. Does this API do that? (And is it on your website?) Thanks It's about sharing stellan0r is referring to the API within CGMiner that allows MinePeon's WebUI talk to CGMiner (to provide stats, etc...) stellan0r - The issue you experienced basically means at some point the WebUI wasn't able to communicate to the CGMiner application (for whatever reason), from my experiences, CGMiner will try to restart itself on error within MinePeon (believe that's an option, can't remember atm, I know if I kill the cgminer process it will instantly come back up), with that being said, if the WebUI tried to pull stats from the CGMiner application during a restart (or if CGMiner was down) then it's going to fail communicating to CGMiner on port 4028 (which is the default API port for CGMiner) in the CGMiner configuration it is setup to only allow API requests from the localhost (so don't freak out thinking someone else can connect to it).
|
|
|
As the title states...
Looking to be a BFL Jalapeno, PM me what you are asking for it. I'm also willing buy broken BFL Jalapeno units, depending on the issue and asking price.
|
|
|
iOS 7 too aye.
and I almost didn't renew my iOS developer subscription this year. LOL! Good thing you did. Looks like nice work. The iOS (& android & winMobile) applications are MobileMinerApp ( http://www.mobileminerapp.com), I just wrote the code within the MinePeon UI to connect to the MobileMinerApp API. I renewed iOS because I was debating on writing a few mobile apps (back in Jan) and haven't gotten around to a single one, been to busy at work.
|
|
|
This is great! Congratulations, tk1337. I already installed it in my Galaxy S3 Android Gizmo and already registered it. What do I need now to do to my 3 Rπ's with MinePeon?
Going to chat with Neil, try to get it in the next release, plus I want to see if I can get some information from him about other USB devices people are connecting to the rPi from within MinePeon. I'll let everyone know soon.
|
|
|
Pretty nice. I installed it on my Ipad but it looks like there is nothing to connect it with CGMiner on Minepeon? Any ideas on a date?
Thanks, IAS
Right now, my only gripe is a short 'hack' I did for the stop/start commands, which I have a more thought out way of doing it but would require a change within MinePeon (possibly), going to shoot off a message to Neil today.
|
|
|
This is what you need (and a Breeze Fan):
AnkerŪ Uspeed USB 3.0 9-Port Hub + 5V 2.1A Charging Port with 12V 5A Power Adapter
ARCTIC Breeze Mobile USB-Powered 92mm Portable Fan, Portable Cooling Solution, Quiet Fan - White
I have 2 USB hubs, 9 USB Block Eruptors, 1 Fan X2
If only Anker's worked with raspberryPi's
|
|
|
I bought the Satechi 12-port hub, which will the power adapter that came with it, it should be able to power at least 6 (but we'll say 5)... it barely support 4, with an upgraded 5v 6amp adapter. The erupters just start having COM I/O errors all the place (that's just with 6 on it). My opinion is simply, Satechi isn't a a good brand to go for, I would imagine it having something to do with the way they are setting up the I/O for each port on the board, probably can't handle a full bandwidth of usb devices (since usually USB devices aren't always 'fully on' to the port/hub).
I got a Belkin 7-port hub (5v 3.6-3.8a) up to 5 erupters before failing and a Dynex 7-port hub (5v 3.6a) to 5 as well... oh well, sitting here waiting for my Rosewill RHB-500's to get here.
|
|
|
iOS 7 too aye.
and I almost didn't renew my iOS developer subscription this year.
|
|
|
I know its exactly what im doing now. I use a netbook to run the proxy.
But i cant get it work on the rpi, thats my Problem.
Its already running with the proxy.
Ok. on my Pi, I recompiled with libmicrohttpd I started miner and set a httpd-port I changed config of my blade and added ip address of pi (i.e. 192.168.1.10,192.168.1.10) http-port: 8330,8330 And it worked just fine I've got 4 blades coming in soon & with another rPi, I don't foresee an issue from your previous posts, but I might bug you later if I can't get it going
|
|
|
Just thought I'd share this over here as well... I just finished a little addition for MinePeon, which is integration with MobileMinerApp (including remote Start,Stop,Restart from within the app)... I haven't pushed it to github yet (still need to talk with Neil (MineForeman.com)), like wise I'm still playing with a few other things on MinePeon. There is a script running in the background that updates MobileMinerApp with stats & checks for incoming commands, currently every minute. There will be a configuration to allow you to turn the checking down to every 30 seconds (minimum). Anyhow, here's some iOS screenshots...
|
|
|
Got my 1st order today, thanks a ton...
|
|
|
I imagine these usb sticks would (should) be usb 3.0?
If they are USB 3 then you could have potential issues with the raspberry pi yes, that's why I'm asking. I would imagine them to be usb 3.0 for more power (vs. usb 2.0). The bitfury chip does not require the added power that USB 3 would give nice, I was wondering (and at the time, being extremely lazy and didn't feel like doing research, was too damn early for me).
|
|
|
I imagine these usb sticks would (should) be usb 3.0?
If they are USB 3 then you could have potential issues with the raspberry pi yes, that's why I'm asking. I would imagine them to be usb 3.0 for more power (vs. usb 2.0).
|
|
|
I imagine these usb sticks would (should) be usb 3.0?
|
|
|
|