I wanted to setup a backup pool and so I installed everything on a debian server. If I specify all of the command line options, it starts fine. But "--help" gives an error.
Fixed, thanks for pointing that out. |
|
|
|
Ente: Here's a version with the submitold commit reverted: https://github.com/forrestv/p2pool/tarball/nosubmitoldDo you think you could test it to see if it fixes the problem? EDIT: Also, does GUIMiner have any log files? There should be an additional message after the "Unexpected error" lines, but it's not there. Maybe it's appearing on the terminal or something? |
|
|
|
After rebooting all rigs, now all (0.8.1) p2pool instances seem to give/get work to guiminer. The rig with 0.8.3 is the only one with "unexpected error" with guiminer.
All 8 rigs have the same versions, configs, tools, everything is identical (except 0.8.1/0.8.3)
Ah, thanks, that gave me enough information to find the (likely) problem - this commit: https://github.com/forrestv/p2pool/commit/d39081784f6 ! GUIminer doesn't use a real JSON parser, and that additional field might be confusing it.. Which backend are you using? By the way, those releases are really old. There have been some important fixes since then.. Most people just use something recent from git master. I might get back into the habit of making releases soon, though. |
|
|
|
Still using GuiMiner, it throws: 2012-02-10 17:50:49: Miner "p2pool": 127.0.0.1:9332 10/02/2012 17:50:49, long poll: new block 000004f709b08c9c
2012-02-10 17:50:53: Miner "p2pool": 127.0.0.1:9332 10/02/2012 17:50:53, Unexpected error:
2012-02-10 17:51:03: Miner "p2pool": 127.0.0.1:9332 10/02/2012 17:51:03, Unexpected error:
2012-02-10 17:51:09: Miner "p2pool": 127.0.0.1:9332 10/02/2012 17:51:09, Unexpected error:
2012-02-10 17:51:10: Miner "p2pool": 127.0.0.1:9332 10/02/2012 17:51:10, long poll: new block 000004f709b08c9c
2012-02-10 17:51:16: Miner "p2pool": 127.0.0.1:9332 10/02/2012 17:51:16, long poll: new block 000004f709b08c9c
2012-02-10 17:51:18: Miner "p2pool": 127.0.0.1:9332 10/02/2012 17:51:18, long poll: new block 000004f709b08c9c Any ideas? Do all of the rigs have identical configurations? It looks like you're using poclbm as the backend.. Maybe try downloading the newest version of poclbm from https://github.com/m0mchil/poclbm/downloads and dropping it into GUIMiner's directory? |
|
|
|
I've been meaning to ask for a while... how are version numbers generated? Do they encode any information of interest to a user?
They are git commit hashes. You can look at the source code for your version by going to https://github.com/forrestv/p2pool/tree/053d7ca or you can see changes I've committed since your version, by going to https://github.com/forrestv/p2pool/compare/053d7ca...master . I'm sorry my sentence keeps coming up, I was answering a previous message from piuk with a link to blockchain.info which had a wrong block listed and just the day before p2pool log file was found by me to contain out-of-date (and as such "misleading" as in "misleading to a user" of p2pool) informations (they clearly are not misleading to their author or to someone who digs into the source code and understands its inner workings).
I also did not check that blockexplorer link because I thought that grepping p2pool log file was the surest way to know what was going on and in case of troubles (blocks being lost and share numbers swinging a lot were yesterday "problems" I was trying to go after) looking up an address to see if it got its payment is not a good idea IMHO since on a lost block every address should not receive any payment.
So I was trying to express the idea that there is not a "place" which lists blocks found and found but rejected by the network as it happens with other pools which often have such a "place".
Maybe my sentence sounds to english speaking peoples in way that is too harsh or just stronger than it was meant to be, my apologies if this is the case.
Ah, sorry, I guess I didn't understand then. The best way to see invalid blocks is to see if any of the blocks mentioned in your log aren't present on Block Explorer. Just looking at Block Explorer only tells you confirmed blocks, and only looking at your log can sometimes tell you old blocks and sometimes not tell you about new blocks, due to them being stale on P2Pool. It wasn't too harsh!  |
|
|
|
This fact that is not possibile to tell exactly what was found and when is a big problem, IMHO, which could stop miners from switching to p2pool.
The first post has had a link to a full, guaranteed list of P2Pool-found blocks for a long time: |
|
|
|
I have multiple interfaces on a host and I want run_p2pool.py to listen on 9.8.7.6:9332 How do I do this?
P2Pool should listen on port 9332 on all interfaces. Is this a problem..? You mentioned just needing to connect external miners, which many people already do. |
|
|
|
FEATURE REQUEST: Could P2Pool load config values from a file, and accept a parameter to tell it where to put its data? This would be nice to have, instead of passing a massive long command line to it.
It isn't documented well (yet), but you can use @FILENAME to make P2Pool load options from that file. File contents would be like: Accepting a parameter for data files is done as of https://github.com/forrestv/p2pool/commit/ff2a677f . |
|
|
|
Huh!?!?! Whats going on here? Pool: 10458MH/s ? Pool stales: 48% ?
Updating and restarting P2Pool seems to fix it. Several users had this problem, and I'm looking into it right now. Will post more updates soon. |
|
|
|
I'm sure this has been answered before ... but ... Is there somewhere where you can see the pool (share-chain) if you are not running p2pool at the moment? i.e. blocks + shares + share difficulty, also current block being worked on and unpaid share list? I guess forrest's client is the best one to consider if I'm not running p2pool if that info is available? ( Where this comes from: http://forre.st:9332/graphs/ ) This one seems to not work any more: http://yat.uukgoblin.net/p2pool-stats/current_payouts.html(or is this information lost for eternity? Thus no way to verify anything?) I plan to make something like the Bitcoin Block Explorer for shares, but even then, old shares are cleared out after they're 48 hours old, as they're unnecessary. The current block payout is determined by at most the last 24 hours of shares. I notice that the "verified" shares take a long time to completely finish loading. What is the main limitation that makes it take so long? Is it strictly bandwidth between peers, or is it CPU based verification that is slow, or perhaps it is a disk throughput issue like bitcoind when it loads the blockchain for the first time?
This is normal and doesn't hurt you. It's because any given share requires the previous 24 hours of shares to be validated, so you can't validate them all in one go. You have to download the last two day's shares, validate the last day's, then wait a day for those unvalidated ones to be forgotten about, all the while new, instantly validated ones are arriving. |
|
|
|
Wait, the same block was just found again!
Sometimes peers broadcast old blocks, for example if they are syncing up with the P2Pool sharechain. It's fixed in newer versions of P2Pool, sorry for the confusion. |
|
|
|
I knew 1% was okay, but if other miners submit stales I need Phoenix to do this as well (or switch miners) otherwise I lose out on 1% efficiency. Is there some link I can trace to see if it is incorporated in the main build (of the main developers accept your commit)? (I am using Windows and usually building things yourself on none-Linux systems is a real pain,so I usually end up waiting for the windows binary like a regular user ). The link I gave will tell you what they do with it. |
|
|
|
So if I use Phoenix and have about 1% stales in the miner this will really cost me 1% as opposed to using another miner? Damn it, I have Phoenix optimized and now I have to it for some other miner too.
Any ideas on which is best?
1% is pretty normal.. I have 0.8% right now with CGminer. Other miners won't necessarily be much better. Just pull in my change from https://github.com/jedi95/Phoenix-Miner/pull/3 if you're going to use Phoenix! |
|
|
|
Good to know its normal. And Im sure there is a good reason for it, but arent you causing a lot of stales by having to force a restart every 10 seconds?
Yes, but those stales aren't lost. They can still be block solutions, and payouts are computed by your number of shares relative to everyone else's, so if everyone gets the same amount of stales, payouts are completely fair. However, some miners try to minimize network overhead by dropping share solutions when a long poll response comes in. This could possibly cause P2Pool to lose a true block solution (the same applies to any merged mining pool), so people should run CGminer with --submit-stales or use newer versions of CGminer that do that automatically. Poclbm also has this behaviour with no way to disable it, as of yet ... I'll put in a pull request. |
|
|
|
|
Proofer: If you upgrade to a more recent version of P2Pool (see first post in thread), the local hash rate estimation is much more accurate now, because it doesn't just use shares.
wachtwoord: The weird number just comes from the P2Pool difficulty changing over time, so each share is worth a slightly different amount. When combined together, you get weird numbers for the payouts.
|
|
|
|
ziomik: What is your displayed "Efficiency"? Is it near 100%? The reason for the rare payouts has been that the pool has been pretty unlucky in the past few days. See: http://u.forre.st/p2pool/luck.png We found two blocks in the morning, though.. hopefully on the way back. Spiccioli, some blocks don't appear in logs because they were stale as P2Pool shares when they were found, and so weren't broadcast. |
|
|
|
litecoin problem:  After awhile the error stopped and information continued as normal, I tried to mine, but I got this:  What exactly am I doing wrong? I installed MinGW with the installer on the site, ...or do I have to build it with python? I think you should be using port 9327 instead of 9338. There was a bug that caused the ZeroDivisionError, which I believe I fixed.. I'll make a new windows build soon. |
|
|
|
I've been working on a graph of luck.. Here it is:  So yes, we've been rather unlucky recently, but before that we were very lucky at some times. The only solution is growth. The split will probably be probably be Eastern hemisphere v.s. West or something similar. If you mine on the correct one, you'll have less stales than mining on the other, so there is incentive to switch (if we coordinate it so many switch at the same time). |
|
|
|
|
Show Posts
