Show Posts
|
Pages: [1] 2 3 »
|
I seem to be asking lots of questions before I get answers. sorry When you: sudo systemctl stop cgminer.service sudo systemctl disable cgminer.service sudo systemctl enable bfgminer.service sudo systemctl start bfgminer.service Does that permanently use bfgminer when MinePeon reboots? Yes, but when I did it, I had to modify bfgminer.service slightly to make it work
|
|
|
Rde, if you could make it easy to see in the miner how many shares were found and how many were submitted of each type: 6ch, 7ch, 8 ch. This would make it clear how bad the issue is or if it's even an issue. Also it would make it possible to compare it to the other builds.
Thanks!
Every block that passes has this detail
|
|
|
I have seen twice that my newly found 8-chains share not showing in "share value" display on the upper right of the ypool's page. Both times the display responded to 6-chains and 7-chains like clockwork. So it was not a problem with network or pool's down time. The XPM column in the personal stat page didn't have any change more than 0.001 after the above 8-chains were found. Not all 8-chains are missing. Often they do get counted. (Because my 8-chain/h is less than 1, most times it is the 6-chain/7-chains that contribute to the XPM column. So once an 8-chain is found you can see the result in the XPM column, if it gets counted.)
I am wondering what was happening. I am using one of the unofficial miners. Is it possible that the miner is secretly sending some of the more valuabe shares to another account?
More than likely what is happening (and you can verify this by keeping an eye on your miner's output) is that those shares end up invalid for some reason. Most often (for me) the cause of this is finding a share right as a block is solved, causing the share to become outdated.
|
|
|
anyone else get -worse- performance on 64bit linux by compiling the sources yourself for linux? If i compile the source and run the linux ELF binary i get about 4500 pps, if I run version 7.1 (need to update so i get the right share value shown though) through 64-bit wine I get about 7200 pps.... although with the linux version it actually takes about 5 minutes to "auto-configure" the sieving while the windows version doesn't say anything about this to me, that is the configuring part, it does say that auto-config is on.
Just curious...
You should probably check 6, preferably 7+ chains per hour over a couple of hours for a descent comparison. Primes per second has been proven to be an inaccurate performance index numerous times You can also use 4 and 5 chains per hour to determine possibilities for higher chains. For instance, one of my machines with an AMD Phenom II X4 910 pulls about 5195.19 4ch/h and 499.58 5ch/h. Using the following maths, you can get a decent idea of higher chains: 5195.19 / 499.58 = 10.399 (truncated for ease) 6ch.h: 499.58 / 10.399 = 48.04 (41.90 is my real measurement) 7ch: 48.04 / 10.399 = 4.62 (3.95 is real number) 8ch: 4.62 / 10.399 = 0.44 (0.62 is real number) and so on
|
|
|
Maybe the newest versions of MinePeon are somehow incompatible with bfgminer. I will check into this when I get home, it would be a bit of a bummer if it is true. The only reason I have been able to support both bfgminer and cgminer is because the API is the same and if they start to differ there is going to be problems. Neil I am using bfgminer with 0.2.3 MinePeon, but you have to make a modification to /usr/lib/systemd/system/bfgminer.service: Instead of "-S auto", just change it to "-S all --icarus-options 115200:1:1 --icarus-timing 3.0=100"
|
|
|
YPool posted an update to their share formula, and now I can't connect through 7.1 or the rdebourbon versions. They say they recommend mums v4, will try and see.
rdebourbon's version still works, pool was just down for a minute while they changed things. I would love to see an 'unofficial' version that reads the share value from the server too
|
|
|
First off, thanks for the update, loving the new setup.
One minor gripe I have (and I'm not sure how hard it is to fix) is that when using bfgminer, the hashrate average that is displayed in the status area at the top of the screen in "Advanced" is read from the 5s average instead of the total average. I'm not sure if this was intentional, but when I hover the mouse over the display area, it says "cgminer > summary > mhsavg" so I assume it's just looking at the wrong value when using bfgminer.
One other issue that seems rather intermittent is that the auto update of the "Advanced" tab doesn't seem to work sometimes. Once in a while it will auto update as intended, but much of the time it just continues to count up seconds without refreshing.
All in all, I still really enjoy this distro for pi mining, keep up the great work!
|
|
|
For part 1, read up on this page
yes sudo ntpd -s helps after the miner is running but as ive asked can you get the time right at the startup before the miner starts? like when the power goes out and the pi restarts it always goes back to 1960 something i'm a big fan of rtfm also but havent found the answer to my questions in the 40 pages i've read so far here or in the wiki https://bitcointalk.org/index.php?topic=137934.msg2925270#msg2925270my post, about 7 posts before your initial one
|
|
|
new user to linux,pi and bitcoins so be gentle but had two questions 1. is there anyway to get the time correct before the miner starts so the webpage doesnt say uptime of 15930 days? 2. how would i fix this on the webpage ? Graph error: opening '/opt/minepeon/var/rrd/hashrate.rrd': Permission denied Graph error: opening '/opt/minepeon/var/rrd/hashrate.rrd': Permission denied Graph error: opening '/opt/minepeon/var/rrd/hashrate.rrd': Permission denied Graph error: opening '/opt/minepeon/var/rrd/hashrate.rrd': Permission denied Graph error: opening '/opt/minepeon/var/rrd/hashrate.rrd': Permission denied
For part 1, read up on this page
|
|
|
I'm getting this today, I've never had this before. [minepeon@minepeon minepeon]$ git pull fatal: unable to access 'https://github.com/MineForeman/MinePeon.git/': SSL certificate problem: certificate is not yet valid
Think you have an issue with the date on the Pi date sudo ntpd -s Since I use wifi only, I'll put in my 2 cents, I had to make sure openntp was enabled so that time would update on reboot as well: sudo systemctl enable openntpd.service
|
|
|
I seem to be having some trouble switching to bfgminer as the auto-start miner. I did the following: sudo systemctl stop cgminer.service sudo systemctl disable cgminer.service sudo systemctl enable bfgminer.service sudo systemctl start bfgminer.service
But the miner never seems to start. So I dug in and started bfgminer via ssh only to receive the message "All devices disabled". Might I have to edit the line in bfgminer.service that starts the miner? All that said, MinePeon is freaking awesome, was plug and play for using cgminer with a block erupter (pi will power 1 off it's own ports surprisingly). Only exception to plug and play was setting up wifi (still super easy thanks to wicd-curses) and setting up auto ntp time updating at start (time issue was really bugging me). Thank you so much for getting all this together, and I love the new stats pages, keep up the freaking awesome work! Unfortunately with the 3.x.x series bfgminer and cgminer went two different ways as to how they use USB, bfgminer still works but you may need to edit;- /usr/lib/systemd/system/bfgminer.service And put your options into it. Neil Thanks! Though I did make the edit and I'm still getting "all devices disabled" perhaps I'm missing something else? Here's what the ExecStart line in bfgminer.service looks after the small edit: ExecStart=/usr/bin/screen -dmS bfgminer /opt/minepeon/bin/bfgminer -S all --icarus-options 115200:1:1 --icarus-timing 3.0=100 --api-listen --api-allow W:172.0.0.1 --sharelog /opt/minepeon/log/share.log -c /opt/minepeon/etc/miner.conf EDIT: strangely starting the service didn't work (after enabling) but a quick reboot on the pi and it's all good now, mining away with the latest bfgminer (very slightly less cpu usage)
|
|
|
I seem to be having some trouble switching to bfgminer as the auto-start miner. I did the following: sudo systemctl stop cgminer.service sudo systemctl disable cgminer.service sudo systemctl enable bfgminer.service sudo systemctl start bfgminer.service
But the miner never seems to start. So I dug in and started bfgminer via ssh only to receive the message "All devices disabled". Might I have to edit the line in bfgminer.service that starts the miner? All that said, MinePeon is freaking awesome, was plug and play for using cgminer with a block erupter (pi will power 1 off it's own ports surprisingly). Only exception to plug and play was setting up wifi (still super easy thanks to wicd-curses) and setting up auto ntp time updating at start (time issue was really bugging me). Thank you so much for getting all this together, and I love the new stats pages, keep up the freaking awesome work!
|
|
|
I'm not sure what Val/h is, but my Core2 Duo downstairs is getting about the same, with much lower PPS.
I may not be able to answer all your questions, but I can do this one. Val/h is "share value per hour". And Share Values are exactly what they sound like, the value of each found and submitted share (6ch = 0.1, 7ch = 1, etc)
|
|
|
Well, block payments just dropped below 11 and difficulty passed 9.54
It's amazing how much a software update and better parameters can get you. On that note, I'm starting to think the chains/day measurement is becoming less accurate. Either that or I've been quite unlucky.
It seems to not be accurate for me - I haven't gotten any blocks since the 25th (other than an orphan on the 25th) on my desktop though so I feel it's hard to tell. Then again my sister got three blocks on saturday with the same cpu... It seems like it's a rough average that was accurate when it was added but is slowly becoming less useful for judging how often you might get a block from my experiences. I wonder if there's a way to use stats like jhPrimeminer (ypool client) does but in this build. Basically counts how many chains per hour of different lengths. For instance, my AMD Phenom II X4 is currenlty 17 6-length chains per hour, 193 5 length/hour, and 2046 4-length/hour. There are more stats of course, but that gives you an idea. If you let it run for a day or so, it is quite accurate. You are proposing to build a model to predict how many blocks can be found per day. As I understandd that was basicly why Sunny added the chains per day gauge. However Sunny pointed out somewhere that chain/d is not block/day. They are just closely related. Well less of a model to predict blocks/day and more of a way to measure performance. For instance, it could help someone tweak their setup to finding longer chain lengths instead of shorter. Or really, just help people understand what their tweaks are doing to performance
|
|
|
Those little LCDs are sweet! Anyone know if there's a place that sells them for BTC? Also, any thoughts on including support for the Adafruit LCD (used in this cool guide) in MinePeon? EDIT: PiMiner ( https://github.com/adafruit/PiMiner) is what is used, just was curious if you planned to include it in the future
|
|
|
Well, block payments just dropped below 11 and difficulty passed 9.54
It's amazing how much a software update and better parameters can get you. On that note, I'm starting to think the chains/day measurement is becoming less accurate. Either that or I've been quite unlucky.
It seems to not be accurate for me - I haven't gotten any blocks since the 25th (other than an orphan on the 25th) on my desktop though so I feel it's hard to tell. Then again my sister got three blocks on saturday with the same cpu... It seems like it's a rough average that was accurate when it was added but is slowly becoming less useful for judging how often you might get a block from my experiences. I wonder if there's a way to use stats like jhPrimeminer (ypool client) does but in this build. Basically counts how many chains per hour of different lengths. For instance, my AMD Phenom II X4 is currenlty 17 6-length chains per hour, 193 5 length/hour, and 2046 4-length/hour. There are more stats of course, but that gives you an idea. If you let it run for a day or so, it is quite accurate.
|
|
|
|