A guide for mining efficiently on P2Pool, includes FUD repellent and FAQ

[gyverlb]

This guide is a work in progress and already quite large, a TL;DR; chapter is at the end of this post for a quick summary.
If you have a good or bad experience with P2Pool to report which brings new useful information, please do report it after reading this whole post to check that your problem or tip isn't already known.

Please stay on topic: this is not about current luck or unsubstantiated feelings of bad behavior from P2Pool as a whole or your node. I am looking for ways to make P2Pool efficient for as many as possible and know that there are configurations performing badly. If unfortunately you are in this case and can't find out why after reading this guide, please report or ask questions. On the other hand if your problem is already described in this guide and you don't have any solution yourself then we are sorry for you but as there's nothing to be done please don't pollute the thread.

Why P2Pool and How?

Introduction to P2Pool: why would you use it?

You can find an introduction and useful information at the P2Pool's page on the Bitcoin Wiki, its forum thread and the Github project page. P2Pool supports Bitcoin/Litecoin/Terracoin mining. Merged mining with other coins is supported too.

P2Pool is an elegant implementation of a distributed pool by forrestv. He truly deserves to be praised and rewarded for his hard work. Hint: look at his signature in the original post of the forum thread for his donation address.

Here's my own description in one of my posts in the forum thread:

I think p2pool is for geeks who like to setup and tune everything themselves. When you can host a node properly (for me this means locally on a host with a good CPU, 2GB RAM on a Linux server dedicated to bitcoind+p2pool, a SSD to store bitcoind's data and with a good QoS setup so that both bitcoind and p2pool don't suffer from other traffic on your WAN connection) and configure a backup pool it's arguably the most reliable and profitable option.

It's not for everyone, but if you are a serious miner and have the network connection and hardware available it's simply the best solution. From what you wrote there are surprising latencies in your setup: it probably isn't for you.

Reasons to use P2Pool as your mining pool

• You are in charge.
• No single point of failure in the pool
• It's fun for geeks to learn
• There are small statistical advantages increasing income vs traditional pools

Reasons to avoid P2Pool

• You have to maintain your node (expect some sysadmin work)
• Some hardware simply can't perform well on P2Pool (less likely since July 2013)
• You have to provide the CPU/RAM/Disk/Net capacity P2Pool needs
• Currently P2Pool is between 1 and 1.4 TH/s, this relatively low hashrate means high variance, especially for low hashrate miners

P2pool's advantages for miners looking for better incomes

Fees are optional (1% is going to forrestv unless you disable it) and transactions are paid to miners. On average, if your miners have latencies comparable to the other miners on P2Pool, you should have more income on P2Pool than on any other pool. In fact you should expect as much (or more, see point below) income as you would have solo mining with reduced variance thanks to other P2Pool miners contributing their own hashrate.

P2Pool blocks are quickly broadcasted to the Bitcoin network through all the bitcoind nodes used by the whole P2Pool network. If another pool finds a block at the same time than P2Pool, it probably is at a disadvantage: that's more income for P2Pool on average.

General advices on running P2Pool

Security

Don't use the node's wallet, always configure p2pool to pay an address (use the "-a" parameter) you can secure appropriately (big fat wallets on a public server are not a good idea).

Maintain up-to-date software

• Monitor the P2Pool forum thread to be aware of new developments
• Run the latest code: you can run something like the bash script I run by cron everyday to restart p2pool after updating it when there's a new version available. You'll need to know how to install p2pool from git, create a "pool.sh" script to run your node the way you want and adapt this to your environment (if you can't find out how by yourself after reading P2Pool's README, I wouldn't advise running p2pool)

Tools

• miner: always use a miner able to switch to backup pools. cgminer is my favorite, by default it will detect specific P2Pool error conditions (like a bitcoind crash) when P2Pool starts rejecting shares repeatedly, switching to the backups and saving you income. Use --failover-only to avoid leaking p2pool work to backup pools.
• home router: if your node doesn't have a public IP address, configure your router to forward the 9333 TCP port to your node: it will help you maintain a good connection with the P2P network.
• monitoring: you are hosting a pool now: use sysadmin best practices and monitor your system (send alerts when bitcoind or P2Pool are down, start them automatically when the system boots, monitor the disk space to avoid surprises, ...). You can do some of this with simple hackish scripts but I advise you to learn how to monitor and maintain a server properly (I use Zabbix for monitoring, a combination of init scripts and/or "@reboot" crontab entries for startup with tmux or screen to launch p2pool and miners).

Maximize your income

Tune bitcoind for more income by editing bitcoin.conf:

Code:

blockmaxsize=1000000
mintxfee=0.00001
minrelaytxfee=0.00001

This will include more fees in the blocks you find, making more income for everyone using P2Pool, including yourself.

Study your income

Don't let your feelings about short bad luck periods cloud your judgment. Compute your expected income according to your hashrate and current difficulty, store it in a spread sheet day by day in a column (don't forget to include your downtimes), add your real income in another column, compute the accumulate theoretical income (the one you would get on a 100% PPS pool) and real one and graph them. This will help you keep a cool head and see how P2Pool really performs for you. I even went a step further and computed my own past luck on 30 and 90-days windows to check the values reported by http://p2pool.info (which by the way was surprisingly accurate, I expected the difference to be greater due to personal variance/downtime/...).

Patience

If you are beginning on P2Pool you should expect irregular payments which can be frustrating. P2Pool is attracting more and more hashrate (from a low 200GH/s in March 2013 to a high 1.4TH/s in July 2013) but its variance is still somewhat high.

First you should be prepared to mine for a couple of days to check that your configuration is good enough (study the efficiency value displayed by your node's main page). If your efficiency is near or above 100%, you can expect more income on P2Pool than in most traditional pools. The only question for you is how long you are willing to wait for variance becoming negligible. On P2Pool with the current hashrate, you should expect to be in the 80-120% luck range in a couple of weeks. I've never seen P2Pool get <80% luck during more than a month. In 6 months I've seen both near 120% luck in a month and near 80% luck in another. As I wrote elsewhere: add your hashrate by joining us and variance will go down!

Note: P2Pool's payment method is PPLNS, with its current configuration you have to wait approximately 72 hours (on Bitcoin, this changes with other coins) to get the first "full" payments. These payments are mined coins (unlike most other pools), they are usable after 120 confirmations not 6 (but you get them as soon as the block is found which makes them usable as quickly as most other pools).

What matters for good P2Pool results: low latencies

On average a miner on a classic pool needs to react to a new coinbase every 10 minutes. Every 10 minutes a miner on any pool can submit a share based on a block that isn't the last one anymore. This is wasted effort: it doesn't help generate the next block in the chain and the pool suffers from this. Most pools reject such work and ignore it when they compute miners' rewards.

Miners are often separated from their pools by long-distance networks with tens or hundreds of milliseconds of latency. This means that every 10 minutes a miner on a normal pool is wasting its efforts for at least tens or hundreds of milliseconds. This is why there are rejects even on properly tuned classic setups: for 10ms of latency between miner and pool on average you should expect 0.01/(60*10) = 0.0016%:

Latency	Expected rejects
10ms	0.0016%
100ms	0.016%
1s	0.16%

Conclusion: on a traditional pool, relatively high latencies aren't such a big deal.

On P2Pool, the tracking of the proof of work is implemented by a sharechain which mirrors several properties of the Bitcoin blockchain:

• A share is a proof of work with a given difficulty
• A share uses the previous share in its input to make a sharechain like blocks do to build the blockchain
• It builds on a block template given by a Bitcoin node: a share hitting the Bitcoin difficulty can become a block too
• It's difficulty is dynamically adjusted to maintain a fixed average rate of share generation (one every 30 seconds)

The last point means that having a low latency is more important for a P2Pool miner than a miner on a traditional pool. Pay attention to the fact that a share being submitted too late to enter the sharechain can still produce a block so it's not wasted work (high reject rates are not a problem for global income on P2Pool unlike rejects on traditional pools). This said as the rejected share isn't in the sharechain it won't count as a proof of work for the purpose of distributing the pool's income.

The important thing is: high latencies don't hurt the pool's income but they hurt the miner's income.

Let's suppose that all miners on P2Pool have an average latency with the P2Pool network of 150ms. A "slow miner" configures a P2Pool node and begins mining with a latency of 600ms with the P2Pool network.
The amount of his work not entering the sharechain is 0.6/30 = 2%. The amount of work not entering the sharechain for his peers is 0.15/30=0.5%.

For 150ms more latency, this "slow miner" efficiency is 98/99.5: ~98.5%.

No work is wasted so the pool itself will make as much as any other pool with the same hashrate. But the slow miner will see 98.5% of the income he may have expected. All the other miners will earn more than they should (how much depends of their aggregated hashrate vs the hashrate of the "slow miner").

On some setups the addition of latencies at various levels can easily add up to a whole second. Miners with such latencies can expect up to 3.3% of lost income (this isn't as much as it used to: before July 2013 the BTC share interval was only 10 seconds instead of 30 seconds now which made the lost income ~3x what it is today).

The hunt for latencies

Here's a comprehensive list of latency sources and how to reduce them.

Cause	Solution
WAN latencies	: QoS, remove superfluous trafic and tune bitcoind/P2Pool for less network usage
Miner<->node latencies	: put them on the same LAN or see above
P2Pool node latencies	: use a fast CPU for the node
Hardware latencies	: tune your miner software, don't use some hardware on P2Pool
Bitcoind latencies	: Use bitcoind 0.8.2 or later, tune bitcoin.conf
IO latencies	: Use bitcoind 0.8 or later, SSD or tmpfs/ramfs, large RAM amounts for cache

You often can pinpoint where your latencies are by studying the graphs available at http://<yourserver>:9332/static/graphs.html?Day or the main stats page at http://<yourserver>:9332/static/
P2Pool maintains statistics for your node since its start time, it's often not easy to compare them with stats for the whole P2Pool network for which you can follow the changes over time in the graphs (the 1 hour average is displayed on the main page). Tip: restart your P2Pool node and check the value you want to compare after 1 hour and then 1 day (you can get averages for the whole network on these periods in the graphs page).

WAN latencies

Wan latencies are sources of orphans. You can get your amount of orphans in the main stats page (compute the % by dividing it by your total amount of share and multiplying by 100) and the average % of the network in the graphs page.

If your orphan % is noticeably above the network one, your Internet connection needs care: unclog your pipes or use QoS!

QoS
The best way to solve the problem is QoS. Just give top priority to the bitcoind and P2Pool traffic :

• TCP port 8333 in both directions (bitcoin P2P)
• TCP port 9332 to the node (miner connections to node)
• TCP port 9333 in both directions (P2Pool P2P network)

Making room
If you can't setup QoS, your next best option is to limit the traffic used by all the bandwidth hogs (when the bandwidth usage reaches the limit, the latencies skyrocket). A good rule of thumb to start with is to leave ~100KB/s in both directions available for P2Pool + bitcoind.

Tune bitcoind and P2Pool
If you can't use the methods above or they aren't enough you can limit the number of connections used by bitcoind and P2Pool.

For bitcoind, use the parameter maxconnections in bitcoin.conf

Code:

maxconnections=10 # 125 is the default, don't go below 8

There's a compromise here: the more connections, the faster your node will be notified of new blocks and avoid wasting work, the faster it can include transactions with fees in the coinbase and the faster it will propagate a P2Pool block minimizing chances it would become orphan.
But the less connections, the less bandwidth used and the lower the latency.

More than 20 for maxconnections is probably overkill: from my experience (trying various values from 6 to 100) it seems there's not much gain to have past this value (and if you don't have enough WAN bandwidth it can hurt your latencies by queuing transfers between P2Pool nodes during peaks).
Note that this may change in the future if the behavior of bitcoind/P2Pool network changes: when in doubt, monitor your interface(s) bandwidth usage and raise this value when most peaks are below your link capacity.

If your orphan rate is fine, don't tempt the devil and try tuning maxconnections below 20: you may reduce your income more than you increase it...

Warning: P2Pool needs one connection to bitcoind and bitcoind tries to fill all the allowed connections after startup. If you start P2Pool just after bitcoind (or before, it will repeatedly try to connect), it shouldn't have problem connecting because bitcoind will still have connection slots available. If you set maxconnections too low P2Pool might not succeed connecting.

For P2Pool, you can do the same by passing parameters to P2Pool:

Code:

--max-conns 8 --outgoing-conns 4

Note: orphans will quickly rise if you have very few connections (they are the means to be notified of other shares after all). I would prefer reducing bitcoind connections before P2Pool's.

In my experience you can get as low as 6 total connections (3 in, 3 out) without noticeable efficiency changes. The default values seem overkill (6 outgoing, 40 incoming). The large number of incoming connections (--max-conns) is designed to help the whole network (some nodes are behind firewalls that don't allow incoming connections). You probably should allow more incoming connections (and check that your network setup allows incoming connections) to do your part in helping the network.

Tune the block generation to limit your bandwidth usage
Even if you have low latencies and didn't need to tune anything above, a limited upload bandwidth can slow down the transfer of your shares to other nodes resulting in more orphans. Check how much of your bandwidth is used by P2Pool in the graphs. You want most of the peaks shown in the "Hour" graphs to be below your available bandwidth.
To know your available bandwidth subtract the bandwidth used by other process from your peak bandwidth. For bitcoind an upper limit to how much bandwidth it can use should be around 2x the max blocksize (1MB) per connection with peers (1x for learning and transmitting transactions, 1x for learning and transmitting a block including them) every 10 minutes this is ~3kB/s for each connection (this is why I recommend to lower the setting from 125 to 10 above).

If lowering your number of bitcoind and P2Pool connections to the values above doesn't free enough bandwidth, you might want to setup bitcoind so that the amount of data transferred by both bitcoind and P2Pool is lower. You can do that by limiting the size of the blocks your bitcoind accepts to create, this will limit the number of transactions included in your coinbase and the amount of data transmitted to other nodes:

Code:

blockmaxsize=250000 #default is 500000

If you don't have this problem, you should raise the blockmaxsize value instead to get more income:

Code:

blockmaxsize=1000000 #default is 500000

This is the maximum value allowed by the Bitcoin protocol. There are lots of unconfirmed transactions with low fees just waiting for P2Pool users to mine them and get the benefits. You should only use lower values if all other means of saving bandwidth don't work without lowering your efficiency (lowering the number of connections from both bitcoind and P2Pool as shown above). Lowering this setting not only lowers your income, it lowers every other P2Pool user's income too.

Miner <-> node latencies and hardware latencies

These 2 sources of latencies are causes of DOA shares. Use the same method than the one described above for orphan shares to see if you are affected.

Hardware latencies

ASICMINER Block Erupter blades: they seem to work correctly according to this post.

Avalon: works fine with latest firmware. If you don't get good results, your first check should be to find out if you can upgrade your firmware.

BFL: if you have a BFL Single, an early FPGA MiniRig (cgminer has a parameter for later ones to fix them, check its documentation) you may want to avoid P2Pool, they have huge latencies and can't perform well on it (might be good enough with the current 30s share interval, you'll have to test it for yourself). Put them on a traditional pool to be safe.  If you have a BFL SC (ASIC), ckolivas and kano reported the same problem, see ckolivas post. At least two users reported around 100% efficiency: here and here. You might want to test it for yourself for at least 24h and report your results here (please include the details from cgminer's API if possible). It's likely that with the new 30 second interval they are OK.

FPGA: I only have experience with Icarus and Cairnsmore1. They are excellent for P2Pool: even better than my tuned GPUs. Most other FPGA-based miners using Spartan6 should be able to interrupt their current work to start again on a new coinbase so you probably should not have any problem with them. Note that I tried bfgminer with Cairnsmore1 to test its support for dynamic clocking and it generated more orphans than valid shares, MPBM didn't have this problem (but could only connect with longpoll, not stratum). If you have problems with bfgminer, try to switch to cgminer or MPBM with longpoll.

GPU: If you use cgminer or Luke-Jr's fork bfgminer, an example working well on sha256d coins (Bitcoin/Namecoin/...) is:

Code:

-Q 0 -g 1 --intensity d --gpu-dyninterval 50

Dyninterval sets the maximum amount of time a GPU should be blocked, it's set in milliseconds. 50ms is a good compromise because the hashrate is still good and the maximum blocked time is still less than 0.5% of the share interval of P2Pool so can't influence its efficiency much (theoretically at most 0.25%).

For scrypt coins (Litecoin/...) optimizing is kind of a black art. I've seen at least one guide on this forum. Notes: dynamic intensity with cgminer didn't work well for me on 5870/5970. "-g 1" has been reported bad on 7970 (although it works for me...).
cgminer versions before 2.11.2 created a lot of stack traces in p2pool logs. Upgrading to at least 2.11.3 is advised (you should always try the latest versions anyway).

Miner <-> node latencies
As much as you can, put the miners and the P2Pool node on the same Local network. If it isn't possible, see how to optimize for WAN latencies and apply to the network used to connect your miners to P2Pool.

Note that at least one user (zvs) reported good efficiencies with as much as 300-350ms average latency between miners and node.
Another report reported excellent efficiency with 19ms and 32ms RTT (Round-trip time) to the miners and 110-115% efficiency. Try to keep your RTT low for miner <-> node traffic by using QoS.

P2Pool node latencies

I'm not sure if the node code has been profiled to find out if there are code paths slow enough to create noticeable latencies. If you can, use a fast CPU to run the node and at least a dual-core so that bitcoind and P2Pool won't have to share a core.

Bitcoind latencies and I/O latencies

Use the latest stable bitcoind (0.7 is very slow, old 0.8 versions still have performance problems).
You should run bitcoind on the same system than p2pool for best results if you can (I don't have results for setups where bitcoind and P2Pool are on different systems).

Latest tests show that the getblocktemplate latency doesn't influence efficiency much (at least up to 0.4s). Note that one possible side effect of high latency is that your CPU is used at 100% while bitcoind is processing the request and this could slow down P2Pool, indirectly lowering efficiency. You should not notice this effect on a multi-core CPU if it's not heavily used by other processes.

If your getblocktemplate latency is really high (>0.3s) and your efficiency is <100% your low efficiency might be linked to your getblocktemplate latency, it's more likely to be linked to high bandwidth or CPU peak usage, so check that you don't have regular CPU/network peaks before trying to lower getblocktemplate latency needlessly.

You can follow these tips (especially if you have a weak CPU) ordered roughly from most to least efficient (you can skip the ones you can't do easily obviously). For each tip applied, look at your average bitcoind latency and efficiency as reported by p2pool for at least 24h starting from a p2pool restart before changing something else (or you won't know for sure if the changes you noticed are due to network fluctuations or your modification). Stop tuning as soon as an average of 0.2s latency or 100% efficiency is reached going below 0.2s will hurt your income and everyone else's on P2Pool.

Note that to do any valid comparison of impact on efficiency you must study your efficiency changes while both the whole network P2Pool's hashrate and average DOA+orphan are stable. Tuning the block size and fee limits lowers the income per block and impacts everyone including the ones doing it, don't do it unless you really need to.

• Install the latest version of bitcoind if you don't already run it
• give CPU and IO priority to your bitcoind and p2pool processes if your OS allows it. With Linux, use nice (nice -n -10 <command> for higher CPU priority, see man nice) and ionice (by default nice gives higher IO priority too, see man ionice to override the defaults) and use the CFQ scheduler) by putting "elevator=cfq" in your boot commandline (google for grub/lilo/... examples)
• use a faster at least dual-core CPU (one core for bitcoind, one core for P2Pool)
• move the bitcoind and p2pool data directory to SSD storage
• reduce blocmaxsize to 500000 instead of 1000000
• raise mintxfee and minrelaytxfee back to defaults (0.0001)
• at this point, if you are still above 0.4s and your efficiency is <100%, reapply the measure that had the most impact between the last 2 (blockmaxsize=250000 or mintxfee/minrelaytxfee=0.0005 for example)

Did you succeed and do you have a good setup now?

Check your P2Pool node's web interface (http://<yourserver>:9332/static/) or logs: your efficiency should be near 100%.

If it's noticeably below after tuning, you might want to describe your setup in this thread so that we can find out if something can be done and enhance this guide. Unfortunately some configurations have inherent latencies that will put you at a disadvantage without any way to improve the situation.

Lower than 100% setups might not make P2Pool a bad solution: it depends on your other options.

Raising P2Pool income
Versions of bitcoind before 0.8.2 had trouble managing large number of transactions. Now bitcoind is more efficient and we can tune it to include more transactions in a block than the default. This will raise the income of each P2Pool miner.

First, if you don't have 0.8.2 or a later version, install the latest stable version.

Then use these parameters in your bitcoind.conf:

Code:

# default is 500000, 1000000 is the maximum allowed and will fit more transactions (more fees)
blockmaxsize=1000000
#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.00001
# Same but for relaying the tx to our peers
minrelaytxfee=0.00001

Processing transaction is now cheaper, so we can include transactions with lower fees. bitcoind automatically selects the most profitable combination of transactions, using these values allows it to select from a larger set than the default values.

Avoid restarting bitcoind when you don't need to: on each restart, the local copy of unconfirmed transaction is reset and your node must wait for peers to transmit them again (this is a very slow process). If you find a block just after a bitcoind restart, there will be almost no transaction fees in it.

Myths, urban legends and misconceptions about P2Pool

"P2Pool has bad luck"

I'll begin with a surprising introduction: there's no such thing as having bad luck. Yes, you read it right, this doesn't exist. Now everybody here and myself included have seen long periods of bad luck so how can I say that we can't have it?
This is due to the very nature of what we refers as luck: we can say that we had bad luck in the past, but not that we are having it right now. Luck is defined on a period of time, so there's no "luck" now, only luck in the past (we can't speak for the future, now can we?).

So when someone tells you that a pool, any pool, "has bad luck", what she means is that the pool had bad luck in the recent past. It could be at the beginning of a lucky period or not, there's no way to tell based on what happened before.

In the case of P2Pool, the relatively low hashrate creates high variance in income. At the date I'm writing this it just found out as many (3) blocks in 15 hours than the 5 days before. This is not a problem due to P2Pool but to the lack of hashrate on P2Pool: come join us to solve it

Statistical analysis of the P2Pool results have repeatedly shown that P2Pool doesn't exhibit any abnormal behavior and is just as lucky or unlucky one can expect it to be. The "but it feels wrong" argument is not backed by any evidence and disappears when P2Pool's recent luck remains above 100% for extended periods of time.

"P2Pool has many orphans"

In fact it did. There was a time in 2012 when the rising popularity of P2pool seemed to have hit a roadblock. After analysis it seems there was indeed a flaw that could lead to a larger proportion of orphans than other pools. P2Pool nodes took time to propagate found blocks and the local bitcoind wasn't used right away to publish the block. This didn't compare well to big pools using very well connected bitcoind nodes to publish their shares. This was a latency problem and was solved by letting the local bitcoind publish a potential block right away and by pre-transmitting the future block content between nodes in advance to avoid wasting time doing this transfer when the block is found.

In its current state, as presented above P2Pool is certainly one of the fastest pools to publish blocks, if not the fastest so it's orphan rate should be among the lowest.

"I tried P2Pool briefly and didn't get as much as I expected"

P2Pool's high variance and PPLNS might explain it: people with such experiences might very well have tried it during a period when luck was low or not waited enough to get the full payouts (although they probably did get paid after stopping to mine on P2Pool thanks to the PPLNS payout system).

At the current hashrate, P2Pool uses the average proportion of hashrate over 3 days to compute a miner's share of income in a block. With high variance P2Pool can find a block shortly after you begin to mine on it, give you a very small reward and then nothing for a while: this is expected (and won't harm your overall income in the long run).

"Making smaller blocks increase my income"

For most people it's the exact opposite. Smaller blocks have less fees. There are only 2 known reasons why bigger blocks could hurt your income:

• Generating larger blocks need more bandwidth for transaction pre-forwarding
• Generating larger blocks need more CPU power when calling getblocktemplate and may interfere with P2Pool's process if there are no other available core for it to use

If you don't have enough bandwidth you can lower your number of bitcoind and P2Pool connections. Up to a point (see the guide for recommended values) this won't affect your efficiency (in fact it will increase it if your system is bandwidth-constrained).
If you don't have enough CPU power because it is shared with other processes, give priority to bitcoind and P2Pool (see the guide for Linux tips).

There is some nonsense about reaching a value as low as possible for the getblocktemplate latency with people advising settings bringing it to ~1ms. There's no evidence that this latency is important for efficiency. Setups with 0.4s latency have shown efficiency levels as good as others with 0.001s. This legend most probably takes root in the fact that high getblocktemplate latency occurs when one of the two problems above occurs too but it isn't a problem by itself lowering this value doesn't address the problem efficiently, it only hurts everyone's income when done blindly.

Another inaccuracy is that generating large blocks leads to noticeably more orphans. P2Pool pre-forwards transactions betweens nodes: when a block is found, peers can build it with small bandwidth usage as they already have the nearly all the data needed locally: large blocks are broadcasted efficiently by all P2Pool nodes which makes it less likely to generate orphans.

FAQ

bitcoind tuning

Q: Is tuning the block sizes causing a problem with p2pool?
A: Not for the pool itself (your setting doesn't influence what other nodes do), but it may introduce latencies in your own setup which could lower your income (see the guide above on how to tune bitcoind).

Q: I don't have much memory, how can I fit p2pool and bitcoind on my server?
A: You probably can fit p2pool and bitcoind with good results in 1GB. The less RAM you have and the more compromises you'll have to make, lowering your efficiency in the process.
For p2pool, the number of open connections has an impact on memory usage, you can test --max-conns 3 --outgoing-conns 3 instead of the defaults (going lower might impact your efficiency, if you can't accept incoming connections, raise --outgoing-conns to 6 to get a total of at least 6 connections).
For bitcoind, its memory usage is more dependent on the number of transactions it maintains in its memory pool, raise mintxfee and minrelaytxfee from their default values to slim it down (note that you'll have to wait nearly 24h to see bitcoind reach a stable RAM usage: it grows at it slowly learns transactions from the network). Lowering the maxconnections value from 125 to 10 can't do much harm (you'll have to test to see if it makes any difference).

Known bugs/issues

Q: Why do I get lots of "Worker <name> submitted share with hash > target:" in my P2Pool logs? It seems to put a large CPU load on P2Pool.
A: Your miner may not support pool-settable difficulties. It may be a problem if the rate of these messages gets very high (putting more strain on p2pool). Using stratum-proxy or the scrypt version might help.

Q: My P2Pool node can't connect to my bitcoind node but it is running fine.
A: One common cause is that your bitcoind reached its maxconnections setting. You will have to restart it to avoid waiting for a connection slot to be freed. If your P2Pool node can't connect even if you just started bitcoind, set a higher maxconnections setting.

TL;DR;

Mining on P2Pool needs more attention than traditional pools.
You should keep an eye on your efficiency as reported by P2Pool's main page.
If it's around 100% or above, you are fine and should leave the coins come in without worrying about luck.
If it isn't or you can't stop worrying take the time to read this guide.

[1714500269]

1714500269

[1714500269]

1714500269

[1714500269]

1714500269

[1714500269]

1714500269

[1714500269]

1714500269

[gyverlb]

Note on the post above :

this post was motivated by several questions from new users who often misunderstand P2Pool or get suboptimal performance after misconfiguring some components of a P2Pool mining setup.
There are people spreading FUD and repeating nonsense about P2Pool, I'll try to address some of the urban legends spreading about P2Pool.
Finally P2Pool isn't for everyone, there are configurations and hardware performing poorly with it: they would be better used on traditional pools.

I'm a x86/amd64 Linux user for nearly 20 years now and didn't use Microsoft software for more than 10 years, so tips and advices will have examples for Linux. I'm not sure if P2Pool can perform well with Windows (it depends on the python implementation on it). If Windows admins have experience successfully tuning a Windows P2Pool node, I'll welcome contributions. Experience on other systems are welcome too.

[maqifrnswa]

This is great! Thank you!

If someone tries tmpfs for the data directory, and they lose power, they will lose the blockchain (and wallet). Extra care has to be taken to make sure no important addresses are in that wallet (since p2pool will create one unless you specify another address) and that the blockchain should be backed up to disk to prevent re-downloading every boot.

[gyverlb]

This is great! Thank you!

If someone tries tmpfs for the data directory, and they lose power, they will lose the blockchain (and wallet). Extra care has to be taken to make sure no important addresses are in that wallet (since p2pool will create one unless you specify another address) and that the blockchain should be backed up to disk to prevent re-downloading every boot.

The wallet should not be used at all: p2pool should be started with a payment address to make sure it doesn't pick one from the bitcoin wallet.

The method described runs another bitcoind to maintain an on-disk blockchain up to date.

[gyverlb]

Added recommendations:

• don't use the node's wallet
• forward the P2P port to your node

Added a FAQ entry on blocksize tuning.

[taltamir]

Always use a miner able to switch to backup pools. cgminer is my favorite, by default it will detect specific P2Pool error conditions (like a bitcoind crash) when P2Pool starts rejecting shares repeatedly, switching to the backups and saving you income.

Can you make cgminer in that sentence a hyperlink?

[wknight]

Great job! Very informative! Last time I ran p2pool was when I had all gpu miners and BFL FPGA's didnt work. Not sure if thats the case anymore

[gyverlb]

Always use a miner able to switch to backup pools. cgminer is my favorite, by default it will detect specific P2Pool error conditions (like a bitcoind crash) when P2Pool starts rejecting shares repeatedly, switching to the backups and saving you income.

Can you make cgminer in that sentence a hyperlink?

Done

[taltamir]

Thank you

[rav3n_pl]

Automatic fee (a small tip for forrestv for his great work) is 1% from some time, not 0.5%.
It can be changed (up or down) using --give-author optional parameter.
IE:
--give-author 2
will give 2% of your reward to forrestv

[gyverlb]

Automatic fee (a small tip for forrestv for his great work) is 1% from some time, not 0.5%.
It can be changed (up or down) using --give-author optional parameter.
IE:
--give-author 2
will give 2% of your reward to forrestv

Thanks, fixed.

[organofcorti]

This is great work, really.

By making clear the advantages and disadvantages of mining at p2Pool, it should attract prospective miners who are geeky and have good network connections but aren't statistically literate.

[gyverlb]

This is great work, really.

By making clear the advantages and disadvantages of mining at p2Pool, it should attract prospective miners who are geeky and have good network connections but aren't statistically literate.

That's my not-so-secret plan

[Subo1977]

lightning fast bitcoind

[gyverlb]

lightning fast bitcoind

"lightning fast" -> extremely fast

Does it answer your question?

[Subo1977]

lightning fast bitcoind

"lightning fast" -> extremely fast

Does it answer your question?

No. Where can i get this ?

[gyverlb]

lightning fast bitcoind

"lightning fast" -> extremely fast

Does it answer your question?

No. Where can i get this ?

That's not something you download but something you configure using Linux, tmpfs, the standard bitcoind v0.8 and your skills as a sysadmin. I didn't do it myself because I don't have enough RAM to store the whole data directory (so it wouldn't work well for me) but I've met someone on IRC who claimed having done so with a getwork latency < 0.01s.

If someone can post instructions, I'll link to them.

[Subo1977]

lightning fast bitcoind

"lightning fast" -> extremely fast

Does it answer your question?

No. Where can i get this ?

That's not something you download but something you configure using Linux, tmpfs, the standard bitcoind v0.8 and your skills as a sysadmin. I didn't do it myself because I don't have enough RAM to store the whole data directory (so it wouldn't work well for me) but I've met someone on IRC who claimed having done so with a getwork latency < 0.01s.

If someone can post instructions, I'll link to them.

Thats Fine. I have One Maschine with 4 x Xeon quadcore and 64 Gb RAM 

[gyverlb]

Just reorganized and added details in the "General Advices on running P2Pool chapter".

Damn my own ADSL connection or router seems to be dying. I've had extended period of downtimes.

Next chapter (kidding but maybe not): how to setup a backup 3G network connection for your own home network using Linux and some script voodoo.

[maqifrnswa]

That's not something you download but something you configure using Linux, tmpfs, the standard bitcoind v0.8 and your skills as a sysadmin. I didn't do it myself because I don't have enough RAM to store the whole data directory (so it wouldn't work well for me) but I've met someone on IRC who claimed having done so with a getwork latency < 0.01s.

If someone can post instructions, I'll link to them.

Code:

mkdir -p /var/ramdrive
mount -t tmpfs -o size=10G,mode=0744 tmpfs /var/ramdrive

Tune it for you own mount location, desired size, and desired permissions. You may need to run the scone command as root, and if you do you'll need to chown the new mount point:

Code:

sudo chown user:user ~/ramdrive

now copy over your blocks to ~/ramdrive and it will be super fast. Note that you'll need > 7GB for your blockchain, I don't know how many consumer level machines are around with that much (but Sub's 64GB will rock)

You need to remount it every boot, or you can put the following at the end of your /etc/fstab

Code:

tmpfs /var/ramdrive tmpfs size=500M,mode=0777 0 0

it's going to be root owned, so you can tune the permissions as you wish

take from http://kvz.io/blog/2007/07/18/create-turbocharged-storage-using-tmpfs/

[Subo1977]

That's not something you download but something you configure using Linux, tmpfs, the standard bitcoind v0.8 and your skills as a sysadmin. I didn't do it myself because I don't have enough RAM to store the whole data directory (so it wouldn't work well for me) but I've met someone on IRC who claimed having done so with a getwork latency < 0.01s.

If someone can post instructions, I'll link to them.

Code:

mkdir -p /var/ramdrive
mount -t tmpfs -o size=10G,mode=0744 tmpfs /var/ramdrive

Tune it for you own mount location, desired size, and desired permissions. You may need to run the scone command as root, and if you do you'll need to chown the new mount point:

Code:

sudo chown user:user ~/ramdrive

now copy over your blocks to ~/ramdrive and it will be super fast. Note that you'll need > 7GB for your blockchain, I don't know how many consumer level machines are around with that much (but Sub's 64GB will rock)

You need to remount it every boot, or you can put the following at the end of your /etc/fstab

Code:

tmpfs /var/ramdrive tmpfs size=500M,mode=0777 0 0

it's going to be root owned, so you can tune the permissions as you wish

take from http://kvz.io/blog/2007/07/18/create-turbocharged-storage-using-tmpfs/

Great . I will try it on Monday  and  Report it.

[GernMiester]

Worked just fine but it was far from paying anywhere near what the PPS pool I left was making me even when it had donations out the wazoo. The hashrate is low and blocks are not solved often. You can go 1, 2 or even worse 3 days with zero payout.

I quit many moons ago due to horrible random payouts that never seem to be anywhere ear what any other pool will make you. Maybe I had it setup wrong or maybe it pays like crap.. It certainly paid me less than 1/3rd of what I could have mined at a PPS pool in the same time.  Its a great idea no one seems to care for and it seems mostly because it pays like crap.

[maqifrnswa]

Worked just fine but it was far from paying anywhere near what the PPS pool I left was making me even when it had donations out the wazoo. The hashrate is low and blocks are not solved often. You can go 1, 2 or even worse 3 days with zero payout.

I quit many moons ago due to horrible random payouts that never seem to be anywhere ear what any other pool will make you. Maybe I had it setup wrong or maybe it pays like crap.. It certainly paid me less than 1/3rd of what I could have mined at a PPS pool in the same time.  Its a great idea no one seems to care for and it seems mostly because it pays like crap.

The mathematical fact still remains that a well tuned p2pool will out pay any other pool. In fact, it will approach solo mining. If not enough people are mining on it, it will have huge variance. You were unlucky, but someone else who mined p2pool probably had inverse luck. For example, over the past 7 days, p2pool out paid PPS by 15% (including fees). Last week, people mining on p2pool were underpaid by 15% compared to PPS (including fees). Variance (luck) is a problem for all pools that are underpowered and doesn't mean that it "pays out crap."

If you solo mine for a month and don't find a block, you will think it pays out crap compared to PPS.

[gyverlb]

Worked just fine but it was far from paying anywhere near what the PPS pool I left was making me even when it had donations out the wazoo.

Apparently you didn't read the original post in details. Your post doesn't bring anything useful to the discussion if you:

• don't tell when you tried p2pool (was it before the orphan blocks problem was solved?)
• for how long you tried it: with the current hashrate you can get easily between 80 and 120% PPS for 30 days. If you tried it for less than 3 days you can even get between 0 and 200% PPS.

So nothing new here: you probably experienced variance and didn't like it. That's OK if you are looking for predictable payments and don't want to bet on p2pool's hashrate growing (and thus lowering variance) but I fail to see anything that would deter someone who would want to make the most of its miners in the long run...

[gyverlb]

Added advices for Avalon owners and general advice "Track your income" for everyone.

Edit: new general advice "Patience"

[gyverlb]

Added a TL;DR; chapter

Small precision about the whole network efficiency.

[gyverlb]

Linked makifrnswa's post in the guide for additional information on tmpfs-based bitcoind.

It's not a turnkey solution yet, but I'm not sure this optimization is worth taking the time redacting one: I believe it's a nice hack with some marginal benefits.

[gyverlb]

Added a FAQ entry for the stratum/scrypt problem between cgminer and P2Pool.

[zvs]

use ramfs, and it only needs to be 8GB for at least another couple weeks

you can have getwork be a couple ms, but only if you use a small blocksize.  at 50k, mine was usually around a second (ed: sorry, .01 seconds)

[gyverlb]

Added a link to the Consolidated Litecoin Mining Guide for 5xxx, 6xxx, and 7xxx GPUs, more information about mining with Avalon.

[Subo1977]

Tune bitcoind and P2Pool
If you can't use the methods above or they aren't enough you can limit the number of connections used by bitcoind and P2Pool.

For bitcoind, use the parameter maxconnections in bitcoin.conf

Code:

maxconnections=10 # 20 is the default

Dont set this to <=8   
Then p2pool cannot connect to the bitcoind.

[gyverlb]

Tune bitcoind and P2Pool
If you can't use the methods above or they aren't enough you can limit the number of connections used by bitcoind and P2Pool.

For bitcoind, use the parameter maxconnections in bitcoin.conf

Code:

maxconnections=10 # 20 is the default

Dont set this to <=8   
Then p2pool cannot connect to the bitcoind.

Hum, there can be problems with low maxconnections. If I understand correctly, this depends on how fast you start p2pool after bitcoind because once all the connection slots are taken it refuses p2pool's attempt to connect.
bitcoind probably establish the first connections quite fast because it tries a number of "probably good" nodes first and then a slower discovery process begins.

I'll add this to the guide, thanks.

[mdude77]

The mathematical fact still remains that a well tuned p2pool will out pay any other pool. In fact, it will approach solo mining. If not enough people are mining on it, it will have huge variance. You were unlucky, but someone else who mined p2pool probably had inverse luck. For example, over the past 7 days, p2pool out paid PPS by 15% (including fees). Last week, people mining on p2pool were underpaid by 15% compared to PPS (including fees). Variance (luck) is a problem for all pools that are underpowered and doesn't mean that it "pays out crap."

This isn't entirely true.  The last week has been very good for p2pool.  But the 3 months (not one week) has been awful.

M

[gyverlb]

The mathematical fact still remains that a well tuned p2pool will out pay any other pool. In fact, it will approach solo mining. If not enough people are mining on it, it will have huge variance. You were unlucky, but someone else who mined p2pool probably had inverse luck. For example, over the past 7 days, p2pool out paid PPS by 15% (including fees). Last week, people mining on p2pool were underpaid by 15% compared to PPS (including fees). Variance (luck) is a problem for all pools that are underpowered and doesn't mean that it "pays out crap."

This isn't entirely true.  The last week has been very good for p2pool.  But the 3 months (not one week) has been awful.

M

The very first post explains that this isn't the place to discuss this unless you have solid data showing that there is a bug somewhere: this thread is for discussions on how to optimize a P2Pool miner's setup not gut feelings.

Over the last 3 months I got 98% PPS with P2Pool. If you call that awful I suppose you can only mine on fee-free pools.

When I track my income over the last 6 months I get ~100.5% PPS.

I really wish people would stop with their gut-feeling and track what their real income is (or at least post such nonsense somewhere else).

[mdude77]

The mathematical fact still remains that a well tuned p2pool will out pay any other pool. In fact, it will approach solo mining. If not enough people are mining on it, it will have huge variance. You were unlucky, but someone else who mined p2pool probably had inverse luck. For example, over the past 7 days, p2pool out paid PPS by 15% (including fees). Last week, people mining on p2pool were underpaid by 15% compared to PPS (including fees). Variance (luck) is a problem for all pools that are underpowered and doesn't mean that it "pays out crap."

This isn't entirely true.  The last week has been very good for p2pool.  But the 3 months (not one week) has been awful.

M

The very first post explains that this isn't the place to discuss this unless you have solid data showing that there is a bug somewhere: this thread is for discussions on how to optimize a P2Pool miner's setup not gut feelings.

Over the last 3 months I got 98% PPS with P2Pool. If you call that awful I suppose you can only mine on fee-free pools.

When I track my income over the last 6 months I get ~100.5% PPS.

I really wish people would stop with their gut-feeling and track what their real income is (or at least post such nonsense somewhere else).

Solely looking at p2pool stats, not gut feeling.  You said a week was bad, on what basis do you make that statement? 

M

[gyverlb]

Solely looking at p2pool stats

Which ones? p2pool.info shows 95.9% for 90 days which is already as good as any PPS pool and it doesn't even include yesterday's donation to P2Pool miners from Gavin (for lost income during the fork). "awful" should mean far below standard pools, the numbers don't lie: we aren't far below standard pools. At 98% we are arguably above most of them.

, not gut feeling.  You said a week was bad, on what basis do you make that statement? 

You didn't read the first post or you wouldn't post this kind of question as I explained on what basis I study p2pool's luck.
Even if some weeks are "bad", I never commented on one in particular here.

So your question is bogus and even if it weren't you should already have the answer.

Obviously you aren't here to discuss the subject and instead wish to spread FUD. Please do it elsewhere.

[eleuthria]

Solely looking at p2pool stats

Which ones? p2pool.info shows 95.9% for 90 days which is already as good as any PPS pool and it doesn't even include yesterday's donation to P2Pool miners from Gavin (for lost income during the fork). "awful" should mean far below standard pools, the numbers don't lie: we aren't far below standard pools. At 98% we are arguably above most of them.

To be fair, it only very recently hit 95.9%.  For quite some time it was in the upper 80s/low 90s, which is likely what most recent luck posts were using as their basis.  Yes, that's how luck works, and at p2pool's size it's perfectly within expected variance.  Unfortunately, most miners do not like (or understand) bad luck, especially over a long period of time.  Now we're seeing the opposite.  At p2pool's size, it only takes a week of good luck to completely recover from a bad 90-day downtrend.

[mdude77]

Obviously you aren't here to discuss the subject and instead wish to spread FUD. Please do it elsewhere.

I am not asking a question, or spreading FUD.  Simply correcting your erroneous statement of "last week was bad".  The last 90+ days prior to this week were bad, according to the p2pool stats page.  Now if that stats page is faulty, I sit corrected.

M

[gyverlb]

If you pick the worst 90-day window you can find in p2pool's history, you may get a 85% luck. Which doesn't mean much (all pools with low hashrate exhibit high variance) and isn't the subject we don't study low hashrate and its consequences but how to make the most of P2Pool.

[gyverlb]

Obviously you aren't here to discuss the subject and instead wish to spread FUD. Please do it elsewhere.

I am not asking a question, or spreading FUD.  Simply correcting your erroneous statement of "last week was bad".

You keep referring to something I didn't write. I hate that: you are really trying my patience.

  The last 90+ days prior to this week were bad, according to the p2pool stats page.  Now if that stats page is faulty, I sit corrected.

The stats page is indeed certainly missing a block which was found during the fork so it's faulty. But even then you didn't say that the luck was "slightly bad" (4.1% below average) but you said "awful". This, by definition, is FUD: you are exaggerating the bad luck which is mostly harmless (4% is within the normal fee range on most pools) to make P2Pool look bad.

And worst of all: you keep coming back on this subject on a thread which doesn't address it and explicitly says so in the first post.

[maqifrnswa]

Solely looking at p2pool stats, not gut feeling.  You said a week was bad, on what basis do you make that statement?  

M

I said last week was bad based on the 7 day sliding average data presented on p2pool. I was comparing data from Sunday the 17th (the original date it was posted) GMT to data from the Thursday the 14th GMT. It's semantics and counterproductive to discuss what dates were chosen for the illustration.

What you're nitpicking really doesn't matter at all, this is not a discussion of whether or not we are lucky. I was just illustrating that people confuse "luck" with "it's broken." And I gave an example how over the course of one week we switched from "it's crap" to "it's the best pool in the history of the universe."

The mathematical fact still remains that a well tuned p2pool will out pay any other pool. In fact, it will approach solo mining. If not enough people are mining on it, it will have huge variance. You were unlucky, but someone else who mined p2pool probably had inverse luck. For example, over the past 7 days (March 22), p2pool paid you 185% of what you would have gotten from PPS (including fees). Last week (March 15th), people mining on p2pool were only paid 85% compared to PPS (including fees). Variance (luck) is a problem for all pools that are underpowered and doesn't mean that it "pays out crap."

[gyverlb]

Scrypt+Stratum fix is in, git users should pull. Others should block stratum by using "--fix-protocol" in cgminer/bfgminer until a new official release comes out.

As always try to keep an eye on new miner and p2pool releases.

[mdude77]

You keep referring to something I didn't write. I hate that: you are really trying my patience.

Sorry, I'm not good with names.  No offense intended.  

What you're nitpicking really doesn't matter at all, this is not a discussion of whether or not we are lucky. I was just illustrating that people confuse "luck" with "it's broken." And I gave an example how over the course of one week we switched from "it's crap" to "it's the best pool in the history of the universe."

The mathematical fact still remains that a well tuned p2pool will out pay any other pool. In fact, it will approach solo mining. If not enough people are mining on it, it will have huge variance. You were unlucky, but someone else who mined p2pool probably had inverse luck. For example, over the past 7 days (March 22), p2pool paid you 185% of what you would have gotten from PPS (including fees). Last week (March 15th), people mining on p2pool were only paid 85% compared to PPS (including fees). Variance (luck) is a problem for all pools that are underpowered and doesn't mean that it "pays out crap."

I wouldn't call it nitpicking.  The fact is under a week ago, 90+ day performance was < 90%.  That is awful in my book.  Is it really luck that suddenly changed this last week?  While I find that hard to believe (and I'm not convinced), I'll defer to the mathematical experts who claim it's all variance and shut up.

M

[organofcorti]

You keep referring to something I didn't write. I hate that: you are really trying my patience.

Sorry, I'm not good with names.  No offense intended.  

What you're nitpicking really doesn't matter at all, this is not a discussion of whether or not we are lucky. I was just illustrating that people confuse "luck" with "it's broken." And I gave an example how over the course of one week we switched from "it's crap" to "it's the best pool in the history of the universe."

The mathematical fact still remains that a well tuned p2pool will out pay any other pool. In fact, it will approach solo mining. If not enough people are mining on it, it will have huge variance. You were unlucky, but someone else who mined p2pool probably had inverse luck. For example, over the past 7 days (March 22), p2pool paid you 185% of what you would have gotten from PPS (including fees). Last week (March 15th), people mining on p2pool were only paid 85% compared to PPS (including fees). Variance (luck) is a problem for all pools that are underpowered and doesn't mean that it "pays out crap."

I wouldn't call it nitpicking.  The fact is under a week ago, 90+ day performance was < 90%.  That is awful in my book.  Is it really luck that suddenly changed this last week?  While I find that hard to believe (and I'm not convinced), I'll defer to the mathematical experts who claim it's all variance and shut up.

M

Oh dear. I come to this thread to read about how to optimise p2Pool. I don't understand the optimisations very well - I just don't have sufficient geek, or a sufficiently stable / low latency network. But it is an interesting read none-the-less.

What aren't interesting reads are the continual claims that something is wrong with the pool, and causing it "bad luck". Here are a few things which anyone should consider when making a "luck" claim one way or the other:

1. Talking about average "luck" over a number of days leads to claims that bad luck periods go for a long time, and good luck for only short periods. This is because when fewer blocks are solved by the pool, the "bad luck" stretches in time. If you instead look at a graph of average luck per block, or better yet the boxplots I posted, you can see that the recent "bad luck" is a small deviation that has actually been shorter than some other deviations. I'll just bold that: Average luck per time period is misleading.

2. This is something Meni Rosenfeld brought up when I was first analysing p2Pool's luck - how could a period of "bad luck" be a problem with the pool? I don't see anyone proposing any mechanisms.

3. The published stats are going to be a little inaccurate. If anonymised earnings per hashrate for a large number of miners could be posted somewhere I think the "luck" discussion would end for all time.

[maqifrnswa]

I wouldn't call it nitpicking.  The fact is under a week ago, 90+ day performance was < 90%.  That is awful in my book.  Is it really luck that suddenly changed this last week?  While I find that hard to believe (and I'm not convinced), I'll defer to the mathematical experts who claim it's all variance and shut up.

M

I am a mathematical expert. If your hash rate solves 2 blocks every day over 90 days, there is a 9.4% chance that in any given 90 day period you'll have < 90% "luck"

If your hash rate solves 1 block every day, there is a 19% chance that you will have less than <90% luck in a 90 day window.

So when p2pool's hash rate was low the pool was more likely to have < 90% luck over 3 months than someone throwing a 6 on a 6 sided dice.

My point is that I'm kind of surprised people think something that has between a 1/10 and 1/5 chance of occurring is a sign it is broken.

[zvs]

i guess i'll say it again, since it's still on there

the statement:

The best results (but probably by a negligible amount) can be obtained when the bitcoind data directory is on tmpfs

is incorrect.  one can make a tmpfs drive that runs "low" on memory ("low" default being 50%?), in which case it'll start using swap space, slowing bitcoind down

with ramfs you have total control over how much RAM to use on the drive and that's all it'll ever use.  it's not too hard to tell how large you should make a ramfs drive.  at this moment, around 8.5gb

[gyverlb]

i guess i'll say it again, since it's still on there

the statement:

The best results (but probably by a negligible amount) can be obtained when the bitcoind data directory is on tmpfs

is incorrect.  one can make a tmpfs drive that runs "low" on memory ("low" default being 50%?), in which case it'll start using swap space, slowing bitcoind down

with ramfs you have total control over how much RAM to use on the drive and that's all it'll ever use.  it's not too hard to tell how large you should make a ramfs drive.  at this moment, around 8.5gb

There are 2 problems with your arguments.

• I use "can be obtained" because it involves more than simply using tmpfs. If you have enough RAM, you indeed can obtain the best results. It's left to the system administrator to find out how to tune and monitor a system using tmpfs.
• tmpfs can indeed use swap, but unlike you wrote last time I checked ramfs isn't bounded. So if your RAM isn't large enough to fit your tmpfs system at least you can set a boundary and avoid unpredictable behaviour. If you use ramfs and bitcoind's data directory grows to a point where it fills your whole RAM it will put everything else in swap and eventually trigger the kernel OOM killer. What will be killed then can only be guessed.

So ramfs isn't a clear-cut better solution here: it depends on how the system admin is configuring the whole setup. Anyway this is for advanced admins: people shouldn't follow a guide for this but fully understand the implications themselves. I wouldn't recommend it but I'll add ramfs as an option in the guide.

To check what I just wrote about ramfs:

Code:

mkdir /mnt/t
mount -t ramfs -o size=20m ramfs /mnt/t
dd if=/dev/zero of=/mnt/t/a bs=1M count=30

You can write 30M to a 20M ramfs (at least on a 3.7.9 kernel)...

Edit: man mount clearly shows that there's no options for the ramfs filesystem. So "-o size=20m" isn't even an initial value or a hint, it's completely ignored.

[brox]

To be fair, the only bad thing about p2pool is Python language. Which makes it completely useless on low-end PCs.
Hope some day p2pool will be integrated efficiently into bitcoind; reserved my donations for that...

[dooferorg]

Scrypt+Stratum fix is in, git users should pull. Others should block stratum by using "--fix-protocol" in cgminer/bfgminer until a new official release comes out.

As always try to keep an eye on new miner and p2pool releases.

Question.. in the OP it didn't mention about setting up a stratum proxy so that miners futher away from your p2pool instance can connect via stratum. How would I do that? I know how to set up a proxy for local getworks TO a stratum receiver, but it's the setting up of a stratum receive to p2pool I don't understand yet.

[gyverlb]

Scrypt+Stratum fix is in, git users should pull. Others should block stratum by using "--fix-protocol" in cgminer/bfgminer until a new official release comes out.

As always try to keep an eye on new miner and p2pool releases.

Question.. in the OP it didn't mention about setting up a stratum proxy so that miners futher away from your p2pool instance can connect via stratum. How would I do that? I know how to set up a proxy for local getworks TO a stratum receiver, but it's the setting up of a stratum receive to p2pool I don't understand yet.

I'm not sure I understand the question. Why do you need a proxy? Do you have a firewall blocking access to your P2Pool node? P2Pool supports both direct getwork and stratum connexions from miners so you shouldn't need a proxy at all.

[davidkassa]

This a great guide - thanks!

I have a couple of questions.

This thread, and others, have said:

The mathematical fact still remains that a well tuned p2pool will out pay any other pool. In fact, it will approach solo mining.

I'm new to bitcoin (as my rep will tell you), but I understand the concept of luck and variance. How specifically does p2pool "out pay" others? I currently mine on a no-fee (keep trans fees) PPLNS pool. My analysis shows that the trans fees are ~1% so p2pool will out pay there. How else? Is there some sort of reduced latency bonus? Or just a "no-downtime" gain? I read somewhere that >100% efficiencies are "stealing" somehow gaining from others with low pool efficiency by getting their hash power but not always giving credit -- or something.

Also, this guide mentions using:

Code:

-Q 0 -g 1 --intensity d --gpu-dyninterval 50

Can you elaborate? the -g sets the miner to a single thread (opposed to 3 on my machine). Isn't that going to reduce my hashrate? the -Q 0 seems inefficient too but I assume that I'm missing something. The --gpu-dyninterval default is 7 but you recommend 50. I don't understand why. These setting seem really important so I really want to understand.

Finally, how is difficultly handled? Hosted pools can auto-adjust this "magically". How can I tell what I should set mine to (or leave it at) and how do I do it?

[organofcorti]

This a great guide - thanks!

I have a couple of questions.

This thread, and others, have said:

The mathematical fact still remains that a well tuned p2pool will out pay any other pool. In fact, it will approach solo mining.

I'm new to bitcoin (as my rep will tell you), but I understand the concept of luck and variance. How specifically does p2pool "out pay" others? I currently mine on a no-fee (keep trans fees) PPS pool. My analysis shows that the trans fees are ~1% so p2pool will out pay there. How else? [....]

Which fee free PPS pool is that? Are there any left? Mining at a fee-free PPS pool might cost less now, but the risks of the pool failing are high so the cost may be more than you imagine.

[davidkassa]

Which fee free PPS pool is that? Are there any left? Mining at a fee-free PPS pool might cost less now, but the risks of the pool failing are high so the cost may be more than you imagine.

Eligius - It's actually CPPSRB - Capped Pay Per Share with Recent Backpay

I understand the value of p2pool but I don't think that a failing pool is all that costly. If you have a failover you shouldn't have any issues when the primary is down. Worst case is that you'd lose out on anything that wasn't distributed to you yet - hopefully < 0.2

[organofcorti]

Which fee free PPS pool is that? Are there any left? Mining at a fee-free PPS pool might cost less now, but the risks of the pool failing are high so the cost may be more than you imagine.

Eligius - It's actually CPPSRB - Capped Pay Per Share with Recent Backpay

I understand the value of p2pool but I don't think that a failing pool is all that costly. If you have a failover you shouldn't have any issues when the primary is down. Worst case is that you'd lose out on anything that wasn't distributed to you yet - hopefully < 0.2

Yes, Eligius is not actually a PPS pool and so my comments don't really apply to it. In general however, I was referring to the risks PPS pools take and the chances of them going into bankruptcy owing you coins. That is costly and has happened, and has more of a chance happening in a fee-free PPS pool, since a long negative buffer will probably wipe them out.

[gyverlb]

This a great guide - thanks!

I have a couple of questions.

This thread, and others, have said:

The mathematical fact still remains that a well tuned p2pool will out pay any other pool. In fact, it will approach solo mining.

I'm new to bitcoin (as my rep will tell you), but I understand the concept of luck and variance. How specifically does p2pool "out pay" others? I currently mine on a no-fee (keep trans fees) PPLNS pool. My analysis shows that the trans fees are ~1% so p2pool will out pay there. How else? Is there some sort of reduced latency bonus? Or just a "no-downtime" gain? I read somewhere that >100% efficiencies are "stealing" somehow gaining from others with low pool efficiency by getting their hash power but not always giving credit -- or something.

Among p2pool users there's indeed a competition for the best efficiency. It shouldn't be a problem though: people with really bad efficiency unable to make it better shouldn't mine on p2pool leaving only the most efficient ones (which will bring them closer to 100% efficiency). This is assuming their goal is maximum rewards, you can mine on p2pool for other reasons (you like the concept or find it a better solution for Bitcoin's overall health/robustness).

The advantage of p2pool vs classic pools is stated in the guide: it should have less orphans than classic pools because it's better connected to the Bitcoin network and thus should propagate blocks faster (this is a theoretical advantage, I'm not aware of anyone having measured it).

One thing I didn't write yet is the ability of merged mining. If you have moderately high hashpower (currently ~5GH/s) it should bring you additional coins. Namecoin has been between 5 and 13% as profitable as Bitcoin recently, being able to merge-mine it (Devcoin and Ixcoin are possible too) is an additional bonus. For example I set NMC merged-mining up early just to tinker with it (it wasn't really worth my time) and found a quite nice surprise when looking at my NMC wallet last month: 1000+ NMC where waiting there...

Also, this guide mentions using:

Code:

-Q 0 -g 1 --intensity d --gpu-dyninterval 50

Can you elaborate? the -g sets the miner to a single thread (opposed to 3 on my machine). Isn't that going to reduce my hashrate?

It depends on your setup, but I didn't measure any speedup with -g 2 on mine. The higher the number of threads and the higher your latency is, so if it doesn't bring any measurable benefit, you should keep it down.

I'm not sure about --gpu-dyninterval default value but the goal is to keep the GPU latency low without sacrificing too much hashrate. I've measured a ~0.3% lower hashrate when going from 250ms to 50ms but the amount of stales/doa was much lower too. Going lower was eating too much hashrate and I believe 50ms to be much lower than most people latencies with the P2Pool network.

These are good starting point, but if you want to grab a 1% worth of Bitcoin more you might want to study the impact of modifying them by comparing the <hashrate>*<efficiency> (which is what matters for your p2pool's income) value for long runs (at least 24h).

the -Q 0 seems inefficient too

This is what is advised by p2pool. It seemed inefficient to me too, but I couldn't measure any impact vs -Q 1.

Finally, how is difficultly handled? Hosted pools can auto-adjust this "magically". How can I tell what I should set mine to (or leave it at) and how do I do it?

Difficulty is auto-adjusted automatically so that your miners keep submitting ~1 share every second (to avoid too much traffic and load and still get a good estimate of your hashrate).

[davidkassa]

Great! I think I'm going to try p2pool this weekend and keep Eligius as my backup.

Interesting that you mentioned merged mining because I just asked this question on StackExchange today too:
http://bitcoin.stackexchange.com/questions/9999/merged-mining-disadvantages

[mdude77]

Great! I think I'm going to try p2pool this weekend and keep Eligius as my backup.

Interesting that you mentioned merged mining because I just asked this question on StackExchange today too:
http://bitcoin.stackexchange.com/questions/9999/merged-mining-disadvantages

Note: if you use cgminer, and probably bfgminer, you don't want to mix p2pool and "conventional" pools.  They don't mix well.

M

[davidkassa]

hmmm, can you elaborate? if my p2pool process falls over what will behave differently with my backup server? I know that I lowered my queue and thread count slightly, but inefficient hashing is better than downtime, right? TIA.

[gyverlb]

Great! I think I'm going to try p2pool this weekend and keep Eligius as my backup.

Interesting that you mentioned merged mining because I just asked this question on StackExchange today too:
http://bitcoin.stackexchange.com/questions/9999/merged-mining-disadvantages

Note: if you use cgminer, and probably bfgminer, you don't want to mix p2pool and "conventional" pools.  They don't mix well.

M

They do. I've seen my rigs fallback to backup pools without problems when I stopped my p2pool node on numerous occasions.

[mdude77]

Great! I think I'm going to try p2pool this weekend and keep Eligius as my backup.

Interesting that you mentioned merged mining because I just asked this question on StackExchange today too:
http://bitcoin.stackexchange.com/questions/9999/merged-mining-disadvantages

Note: if you use cgminer, and probably bfgminer, you don't want to mix p2pool and "conventional" pools.  They don't mix well.

M

They do. I've seen my rigs fallback to backup pools without problems when I stopped my p2pool node on numerous occasions.

I'm just going by what the cgminer authors have said.  cgminer goes into different logic for p2pool than it does for conventional pools.  I believe the words were "do so at your own risk".

M

[-ck]

p2pool is effectively a different block chain and cgminer stores a database of blocks as they come out so it would confuse it to run p2pool and regular btc mining. Provided p2pool is the primary pool, and you set failover-only it still should be okay.

[gyverlb]

p2pool is effectively a different block chain and cgminer stores a database of blocks as they come out so it would confuse it to run p2pool and regular btc mining. Provided p2pool is the primary pool, and you set failover-only it still should be okay.

It seems it works fine without failover-only and the latest cgminer versions on my setup: as long as the P2Pool node is fast enough I guess you don't need failover-only (it may be a worthwhile precaution to add it though).

[gyverlb]

Updated guide: --failover-only recommended.

[Amph]

hopefully, i'm fine without tweaking anything, 121 efficiency here, but it still say orphaned 0, is this a problem?
another problem is that the last version of p2pool don't work for me, it say:"error bitcoin version to old, upgrade to 0.5 or newer!", but i have already 0.8.1 version...

btw, i'm mining the same amount of BTC guild for now, i hope i can make more

[zvs]

hopefully, i'm fine without tweaking anything, 121 efficiency here, but it still say orphaned 0, is this a problem?
another problem is that the last version of p2pool don't work for me, it say:"error bitcoin version to old, upgrade to 0.5 or newer!", but i have already 0.8.1 version...

btw, i'm mining the same amount of BTC guild for now, i hope i can make more

litecoin?  it said the same thing to me when i spent some time with the litecoin p2pool.  i just removed the thing about upgrading from the source

[Amph]

no, no litecoin here, how can i run the 3.1 without the error, saying that i have a old version?

[gyverlb]

You should probably ask questions about errors in log in the P2Pool thread

[Amph]

dead link

[gyverlb]

dead link

Fixed, the forum doesn't like quotes around an URL?!

[Searinox]

With bfgminer: does --dyn-gpuinterval <number> override --intensity? Is dyngpu the equivalent of saying "i want my desktop to have no less than 1000/<number> frames per second"? I set the option to the recommended 50 and it felt like everything onscreen was lagging. Intuitively I put it at 20fps and figured out it may be that. So then I changed the interval to 16(which is the rounded result for 60fps) and everything went back to normal. How does this impact my mining though?

[gyverlb]

With bfgminer: does --dyn-gpuinterval <number> override --intensity? Is dyngpu the equivalent of saying "i want my desktop to have no less than 1000/<number> frames per second"? I set the option to the recommended 50 and it felt like everything onscreen was lagging. Intuitively I put it at 20fps and figured out it may be that. So then I changed the interval to 16(which is the rounded result for 60fps) and everything went back to normal. How does this impact my mining though?

The lower dyn-gpuinterval is, the more often your system must submit work to the GPU. There is a performance penalty but it depends on your actual setup (GPU performance, CPU speed, system load, OS, ...), you'll have to let it run for a while undisturbed and check the hashrate averages to see at which point it becomes noticeable for you.

[Searinox]

I always find it weird how my P2Pool hashrate keeps fluctuating even in idle, sometimes reaching as high as 280Mh/s or dropping as low as 110Mh/s. I have my miner set up as recommended for my card. Is there anything I can do about it or is this not the miner/setup's fault and rather p2pool's?

[gyverlb]

I always find it weird how my P2Pool hashrate keeps fluctuating even in idle, sometimes reaching as high as 280Mh/s or dropping as low as 110Mh/s. I have my miner set up as recommended for my card. Is there anything I can do about it or is this not the miner/setup's fault and rather p2pool's?

This is a question for the main P2Pool thread.

[Amph]

what this line really do? what is the benefit?
-Q 0 -g 1 --intensity d --gpu-dyninterval 50

with this line, my intensity is set to 9, but i found that intensity 7 is the best for 7950

[gyverlb]

what this line really do? what is the benefit?
-Q 0 -g 1 --intensity d --gpu-dyninterval 50

with this line, my intensity is set to 9, but i found that intensity 7 is the best for 7950

The cgminer's README explains all these values. It's surprising that a lower intensity is better on a 7950, if your card behaves this way, you can lower the gpu-dyninterval value. Assuming the system is dedicated to mining, each time it's halved the intensity should be reduced by 1.

[Amph]

with intensity 7 i mine 575 mh, instead with int 9 only 550

above 9 nothing change, the max is still 575

[gyverlb]

Fixed a typo in the guide, the bitcoin P2P port is 8333 not 8332, if you setup QoS with high priority for port 8332, you should change it to 8333.

Updated the Avalon section with suggestions. There's no documented way to configure Avalon for P2Pool properly, but there have been partial reports. If you have Avalon(s) please report your success/failures with P2Pool here.

[gyverlb]

Given the extreme bitcoind tunings seen in the P2Pool thread that would hurt everyone's income I added a more detailed bitcoind tuning guide designed to give optimal getblocktemplate latencies.

[gyverlb]

Updated the guide with latest test results with bitcoind-git (with performance patch). bitcoind-0.8.2rc3 behaves the same.

Conclusion: it's time to upgrade bitcoind and tune bitcoin.conf to get more fees out of each block. You can probably stop worrying about high getblocktemplate latencies too (see the guide itself for details).

[gyverlb]

Update: new FAQ entry for low memory (~1GB) server.

[gyverlb]

Update: include report of a remote node with RTT between remote node and miners up to 32ms and latency >110%.

Mining on a remote node should be doable with a RTT <40ms. I'd welcome reports on efficiency with RTT>40ms (please include your configuration details).

[gyverlb]

BFL SC (ASIC) have huge latencies making them unsuitable for P2Pool mining. Guide updated.

[grue]

any updates with avalon? are they suitable for p2pool?

[-ck]

any updates with avalon? are they suitable for p2pool?

No

[PatMan]

I hear gpu's with getwork are stable.......

[zvs]

Update: include report of a remote node with RTT between remote node and miners up to 32ms and latency >110%.

Mining on a remote node should be doable with a RTT <40ms. I'd welcome reports on efficiency with RTT>40ms (please include your configuration details).

sure, I mine on a remote node at 200ms

my DSL alone has base latency of 35ms

ed: ok, more like 30-32ms

oh, it also gets like this in the evenings:

[gyverlb]

Update: include report of a remote node with RTT between remote node and miners up to 32ms and latency >110%.

Mining on a remote node should be doable with a RTT <40ms. I'd welcome reports on efficiency with RTT>40ms (please include your configuration details).

sure, I mine on a remote node at 200ms

my DSL alone has base latency of 35ms

Can you share the efficiency you reach with your bitcoind version and settings (if not default ones) and p2pool settings if tuned?

[zvs]

Update: include report of a remote node with RTT between remote node and miners up to 32ms and latency >110%.

Mining on a remote node should be doable with a RTT <40ms. I'd welcome reports on efficiency with RTT>40ms (please include your configuration details).

sure, I mine on a remote node at 200ms

my DSL alone has base latency of 35ms

Can you share the efficiency you reach with your bitcoind version and settings (if not default ones) and p2pool settings if tuned?

well, if you include the evenings of 500ms ping times and the packetloss, it averages out to around 5-6% DOA (weekends are worse than weekdays), add in 2-3% worth of orphans and so then theoretically efficiency would be anywhere from 110-117.  (this would have p2pool as a whole ranging from 18 to 25% doa/orphans)

it's hard to say what mine is exactly, since i have multiple people using my pool.  the 108% right now is worse than normal, but that's because 2 out of the first 5 were DOA.  i reset it this morning at 300 shares, 4 orphans, and like 50 DOA.   the DOA mostly from ASIC not working properly with p2pool

theoretically with a 1 second delay, you should only get 10% DOA?  if you're mining on a european node with plenty of bandwidth that's set up properly, you shouldn't get more than 2-3% orphans.   so, you'd still have higher than 100% efficiency

i use maxblocksize 5000, but i restarted this morning to experiment with 3000.

i run p2pool with about 60 nodes added as --p2pool-node and allow another 20 outgoing and 10 incoming

[gyverlb]

i use maxblocksize 5000, but i restarted this morning to experiment with 3000.

i run p2pool with about 60 nodes added as --p2pool-node and allow another 20 outgoing and 10 incoming

It's the complete opposite of what I advise to do.
I have the same efficiency you have (between 110 and 115%), with nearly 10x less connections and 2000 times more maxblocksize. What makes you thing reducing maxblocksize help your efficiency? Or are you trying to solve another problem?

[zvs]

i use maxblocksize 5000, but i restarted this morning to experiment with 3000.

i run p2pool with about 60 nodes added as --p2pool-node and allow another 20 outgoing and 10 incoming

It's the complete opposite of what I advise to do.
I have the same efficiency you have (between 110 and 115%), with nearly 10x less connections and 2000 times more maxblocksize. What makes you thing reducing maxblocksize help your efficiency? Or are you trying to solve another problem?

what makes you think you know the answer to everything?

you state here you have the same efficiency as I do, yet you mention something earlier to the effect of not mining on a node that has >40ms latency?

how about this (ed: consolidated into one image):



Go ahead and get 115% efficiency with 500k blocksize on that, chief

that's called oversold DSL bandwidth and sunday afternoon/evening... the last hour is called game of thrones

[gyverlb]

what makes you think you know the answer to everything?

I don't: this is why I ask questions. That's called the scientific method: I make an hypothesis and try to find out if it matches reality.

you state here you have the same efficiency as I do, yet you mention something earlier to the effect of not mining on a node that has >40ms latency?

No: in the guide IIRC (didn't reread myself) I say it's safe below 40ms because I had reports up to 40ms. My questions are meant to find out if I can advise people with larger latencies to use a remote node too (without hurting their income in the process).

how about this (ed: consolidated into one image):



Go ahead and get 115% efficiency with 500k blocksize on that, chief

What's that? Your DSL latency with a random host? with your P2Pool node? Your P2Pool node latency with a random host?
Seriously, if you want to tell me I'm over my head, at least try to present your case clearly: depending on which latency you are showing me my answers/questions will be totally different.

[zvs]

Hop 1 is to my router which is <1ms and I've removed.  Hop 2 would be my DSL latency, the last hop is the latency to the IP running p2pool.

Here is a log of my shares from roughly 4:00PM central time onwards:

log:2013-06-11 16:15:59.144244 GOT SHARE! MrT bab783a2 prev 92e2927f age 2.89s
log:2013-06-11 16:51:13.272338 GOT SHARE! Pandaemonium a6d3cf72 prev 0b640f2b age 1.66s
log:2013-06-11 17:16:53.168319 GOT SHARE! Pandaemonium c2aed4f2 prev 60efa42f age 16.31s
log:2013-06-11 17:25:01.871837 GOT SHARE! Altgard b0c4413f prev ea8fd70e age 2.77s
log:2013-06-11 17:25:36.690128 GOT SHARE! Altgard 5f0dfbfc prev 4ededa38 age 21.35s
log:2013-06-11 17:27:45.292548 GOT SHARE! MrT badbc46c prev bb3fe3aa age 4.02s
log:2013-06-11 17:48:34.515212 GOT SHARE! Pandaemonium fcd0270f prev e5bb6882 age 1.12s
log:2013-06-11 17:51:26.236705 GOT SHARE! Pandaemonium 018c1e21 prev 0b9a5cfc age 9.90s
log:2013-06-11 18:20:53.325194 GOT SHARE! Altgard 748c3653 prev ef7d5934 age 2.62s
log:2013-06-11 18:31:44.319511 GOT SHARE! MrT 69a9e53d prev 24e36d6e age 3.19s
log:2013-06-11 18:39:11.042228 GOT SHARE! Brusthonin 07d7bf61 prev e53450f7 age 15.11s
log:2013-06-11 18:46:31.711466 GOT SHARE! Altgard 31b3c8dd prev bd8899a2 age 7.47s
log:2013-06-11 18:54:19.677511 GOT SHARE! Brusthonin 23a09aac prev ea2c121a age 11.17s DEAD ON ARRIVAL
log:2013-06-11 19:10:09.639655 GOT SHARE! MrT 3cfea1bc prev da6f80d3 age 4.88s DEAD ON ARRIVAL
log:2013-06-11 19:15:58.787474 GOT SHARE! Pandaemonium cf3a066f prev 6704c588 age 6.58s
log:2013-06-11 19:34:18.549763 GOT SHARE! Pandaemonium 49edf44c prev 69f93d41 age 3.59s
log:2013-06-11 19:36:24.742229 GOT SHARE! Brusthonin af01fd65 prev ba206f9c age 1.38s
log:2013-06-11 19:45:09.319976 GOT SHARE! Pandaemonium b5cdefd9 prev adeef95e age 42.91s
log:2013-06-11 19:54:32.633016 GOT SHARE! Pandaemonium 12c9a260 prev aa6e334a age 20.10s
log:2013-06-11 19:55:14.390967 GOT SHARE! MrT a04f910d prev 0188a750 age 3.51s DEAD ON ARRIVAL
log:2013-06-11 19:58:04.727155 GOT SHARE! Pandaemonium bef8f8e9 prev a93386e1 age 7.55s
log:2013-06-11 20:24:09.943406 GOT SHARE! Pandaemonium bbd76a15 prev 0ff6593f age 12.61s
log:2013-06-11 20:36:33.468076 GOT SHARE! MrT 999e3378 prev 5d842f0d age 4.39s DEAD ON ARRIVAL
log:2013-06-11 20:51:52.202080 GOT SHARE! Altgard 6f508a8b prev 4f2ccadc age 7.23s
log:2013-06-11 21:14:23.426968 GOT SHARE! Altgard 16814b6a prev f0105104 age 25.33s
log:2013-06-11 21:37:40.949988 GOT SHARE! Pandaemonium 327e8884 prev 813d06be age 5.36s
log:2013-06-11 21:37:55.679323 GOT SHARE! Pandaemonium a55a51b9 prev 0048847b age 7.25s
log:2013-06-11 22:17:32.027947 GOT SHARE! Pandaemonium 01e23d8b prev dd322bbe age 3.29s
log:2013-06-11 22:21:09.732581 GOT SHARE! Brusthonin e61cad93 prev c7d57bc7 age 12.48s
log:2013-06-11 22:45:33.521705 GOT SHARE! Pandaemonium 89a2bc49 prev da8e5127 age 2.79s
log:2013-06-11 22:47:03.131315 GOT SHARE! MrT e675329d prev 1fabbb1a age 6.71s

4 DOAs in ~30 shares.  I'm showing 2 orphans out of 90 shares total.  I'm not sure which 2 were orphaned, but I guess you could say I had 4.33 DOA/orphaned in 30 shares...  that's still >100% efficiency at all times (I don't think I've ever seen p2pool under 13.5% orphan/DOA, at least in the last 6 months).  Not 110-115%, but a couple weeks ago I also wasn't dealing with oversold bandwidth.  4.33 out of 30 would probably usually be around 105% efficiency or so.

Here's what the link looked like for those times:



This is in response to the thing about latency needing to be under 45 or whatever.  With my normal latency (180ms, and much less packetloss), I get about 5% DOA, instead of 10-15%.....

basically my argument about why the most important thing in choosing a node is the node's orphan rate..  then you look at your latency and see how much DOA that should result in...  but I don't see any reason why someone should have <100% unless they're on a satellite connection or something

I should really just be mining on a normal pool until my link is fixed, just too lazy to change everything around

ed:  added two more, link is still crap, 500ms+...  this is worst time of day actually, it'll clear up in about 2 hours

ed2: well, more like 2 1/2 hrs.  my theory is summer break

[gyverlb]

I'm doing 13h work sessions interleaved with long commute times and sleep right now so don't have much energy left for anything else. My first quick reading makes me think I'll have to update the guide. I'll take the time to read your post more thoroughly later this week after resting a bit.

Thanks.

[zvs]

I'm at 32 shares, about 25 being my own, w/ 1 dead share, thru the early morning hours-4PM.  Now is when my link gets really crappy, so will probably be around 15-20% DOA from here on out.

Anyway, ^^ is luck.  But it's 10s per cycle, so 180ms latency shouldn't cause a whole lot of DOA.  Packetloss will.

[freshzive]

Is a Intel Atom D525 CPU (1.8 GHz, dual-core) processor just not enough to run p2pool/bitcoind?

I have one of these: http://www.amazon.com/ZOTAC-Intel-Barebone-Mini-PC-ZBOX-ID41-U/dp/B004WO8O9Y/ref=sr_1_sc_1?ie=UTF8&qid=1371350342&sr=8-1-spell&keywords=zotac+zebox with an SSD.

Loads are around 0.8 constantly on Ubuntu 12.04 x64 (the computer isnt used for anything else). My efficiency is shit (like ~75%). Tried setting up QoS and tuning with your guide, but it didn't seem to help I'm thinking maybe the computer simply isn't powerful enough to handle p2pool/bitcoind.

[gyverlb]

Is a Intel Atom D525 CPU (1.8 GHz, dual-core) processor just not enough to run p2pool/bitcoind?

I have one of these: http://www.amazon.com/ZOTAC-Intel-Barebone-Mini-PC-ZBOX-ID41-U/dp/B004WO8O9Y/ref=sr_1_sc_1?ie=UTF8&qid=1371350342&sr=8-1-spell&keywords=zotac+zebox with an SSD.

Loads are around 0.8 constantly on Ubuntu 12.04 x64 (the computer isnt used for anything else). My efficiency is shit (like ~75%). Tried setting up QoS and tuning with your guide, but it didn't seem to help I'm thinking maybe the computer simply isn't powerful enough to handle p2pool/bitcoind.

It may not be enough: these CPUs are weak.
How many shares did you get when your efficiency was 75%? With your efficiency if you didn't have at least 50 shares, the value is probably not reliable yet.

[gyverlb]

Just updated the guide with a reference to zvs results with 300-350ms latency between node and miners.

Added more details about what/how to tune and why instead of blindly lowering getblocklatency without understanding the consequences.

[zvs]

OK, so right now, my server is reading:

Node uptime: 3.124 days Peers: 73 out, 19 in

Shares: 256 total (3 orphaned, 14 dead) Efficiency: 116.2%

I started pinging the first hop (not counting my actual router) instead of the server, so the ping times are about 180ms lower than what I'd get to nogleg.com.  I set the packetloss scale to 10%, since local packetloss is rly, rly bad (a remote ping would show 10x as much packetloss).  Started doing this so I can give this info to ISP, which continues to deny bandwidth exhaust issue...

but, anyway:



Out of those 256 shares, about 85% are mine & the number of orphans/DOA from the other people wasn't disproportionate to my own.

So, now I'll set maxblocksize to 1000000 (!!), and restart the server.  Not a huge deal anymore since even with my 6.7c or so electricity, bitcoins are just marginal profit nowadays.  Don't mind a lot more DOA/orphans for the next day or two for the sake of showing that this setting kills.

I apologize to the other ppl that are pointed to my server atm.  Maybe come back in a few days?

[gyverlb]

So, now I'll set maxblocksize to 1000000 (!!), and restart the server.  Not a huge deal anymore since even with my 6.7c or so electricity, bitcoins are just marginal profit nowadays.  Don't mind a lot more DOA/orphans for the next day or two for the sake of showing that this setting kills.

I'm extremely curious about the results. If it indeed kills your efficiency, we'll have to understand why it happens on your setup and not mine (I even lowered mintxfee and minrelaytxfee to make it easier for bitcoind to fill the blocks). I'm still at 110+ efficiency with getmininginfo confirming that the block templates generated by bitcoind are indeed ~1MB.

I only know of 2 reasons why it could kill your efficiency:

• it generates too much traffic, filling your pipe (reduce your bitcoind and p2pool number of connections). It can happen even with large pipes if your hoster have some peering limitation.
• your CPU is maxed out (you should have one core free for P2Pool to be safe)

Maybe we will find another one to document in the guide.

[zvs]

So, now I'll set maxblocksize to 1000000 (!!), and restart the server.  Not a huge deal anymore since even with my 6.7c or so electricity, bitcoins are just marginal profit nowadays.  Don't mind a lot more DOA/orphans for the next day or two for the sake of showing that this setting kills.

I'm extremely curious about the results. If it indeed kills your efficiency, we'll have to understand why it happens on your setup and not mine (I even lowered mintxfee and minrelaytxfee to make it easier for bitcoind to fill the blocks). I'm still at 110+ efficiency with getmininginfo confirming that the block templates generated by bitcoind are indeed ~1MB.

I only know of 2 reasons why it could kill your efficiency:

• it generates too much traffic, filling your pipe (reduce your bitcoind and p2pool number of connections). It can happen even with large pipes if your hoster have some peering limitation.
• your CPU is maxed out (you should have one core free for P2Pool to be safe)

Maybe we will find another one to document in the guide.

Well, it's doing better ATM, with 19 shares and just 1 dead.

But, it's also adding a lot of load to the system and I can tell that if you took a large enough sample it'd be worse...    simply because (if nothing else):

2013-06-17 06:45:57.826722 New work for worker! Difficulty: 1.586613 Share difficulty: 1237.801257 Total block value: 25.956635 BTC including 1204 transactions
2013-06-17 06:45:57.914912 New work for worker! Difficulty: 1.586613 Share difficulty: 1237.801257 Total block value: 25.956635 BTC including 1204 transactions
2013-06-17 06:45:58.003061 New work for worker! Difficulty: 1.586613 Share difficulty: 1237.801257 Total block value: 25.956635 BTC including 1204 transactions
2013-06-17 06:45:58.091624 New work for worker! Difficulty: 1.586613 Share difficulty: 1237.801257 Total block value: 25.956635 BTC including 1204 transactions
2013-06-17 06:45:58.182583 New work for worker! Difficulty: 5.000000 Share difficulty: 1237.801257 Total block value: 25.956635 BTC including 1204 transactions

vs

2013-06-17 08:06:45.156392 New work for worker! Difficulty: 1.170742 Share difficulty: 1063.111336 Total block value: 25.207522 BTC including 280 transactions
2013-06-17 08:06:45.180769 New work for worker! Difficulty: 1.170742 Share difficulty: 1063.111336 Total block value: 25.207522 BTC including 280 transactions
2013-06-17 08:06:45.204890 New work for worker! Difficulty: 1.170742 Share difficulty: 1063.111336 Total block value: 25.207522 BTC including 280 transactions
2013-06-17 08:06:45.229186 New work for worker! Difficulty: 1.170742 Share difficulty: 1063.111336 Total block value: 25.207522 BTC including 280 transactions
2013-06-17 08:06:45.256788 New work for worker! Difficulty: 5.000000 Share difficulty: 1063.111336 Total block value: 25.207522 BTC including 280 transactions

vs

2013-06-17 09:22:29.858692 New work for worker! Difficulty: 1.203949 Share difficulty: 1063.354280 Total block value: 25.000000 BTC including 0 transactions
2013-06-17 09:22:29.862099 New work for worker! Difficulty: 1.203949 Share difficulty: 1063.354280 Total block value: 25.000000 BTC including 0 transactions
2013-06-17 09:22:29.865353 New work for worker! Difficulty: 1.203949 Share difficulty: 1063.354280 Total block value: 25.000000 BTC including 0 transactions
2013-06-17 09:22:29.868686 New work for worker! Difficulty: 1.203949 Share difficulty: 1063.354280 Total block value: 25.000000 BTC including 0 transactions
2013-06-17 09:22:29.874997 New work for worker! Difficulty: 5.000000 Share difficulty: 1063.354280 Total block value: 25.000000 BTC including 0 transactions

...  I dunno if it goes by the order it says, but if so, it generates my new work last, and the other four people on my pool before me.  With 1204 transactions, it takes 0.355861 seconds between #1 and #5, with 280 transactions it takes 0.100396 seconds, with 0 transactions it takes 0.016305 seconds.  More people mining at your pool = more pronounced effect.  If my pool was private w/ just myself on it, it'd still generate work, what, about ~.05s slower with all those transactions vs having 0 (though the lowest I'd drop my maxblocksize to would probably have a dozen or so).

In the 1204 case, that's adding 355ms to a 10s cycle, which should result in 3.5% more DOA

ed: didn't check to see whether it was based on # of transactions or size of total transactions.  also, it's adding like *340ms, not 355ms.  machine load could have affected times a bit, but there's still the trend that's plain to see.  not doing anything else on it atm besides running bitcoind and p2pool

ed2: there's also the bizarre thing where now i'm suddenly receiving more data than sending.   logically (to me at least) that seems like it'd result in more orphans?    what's up w/ that, anyway?  anyway, based simply on the ^^ up there that indicates i'm receiving work probably about 150ms slower on average, i'm going to cut this short and reduce my maxblocksize again.  even if you go with an extreme best case scenario and say I find a block w/ 1BTC in transaction fees...  when I receive less than 1/100th of the total pie, that isn't worth 1.5% more DOA..  

though I suppose one could make a case for going with 10000, 20000, or 30000 maxblocksize...  (or setting the minimum relay fee much higher, and then setting maxblocksize to 1000000)

ed3:  oh, and while I was typing ed2, I did just pick up an orphan.  heh.

ed4:  6 transactions

2013-06-17 10:17:59.878132 New work for worker! Difficulty: 1.589736 Share difficulty: 1259.470588 Total block value: 25.004000 BTC including 6 transactions
2013-06-17 10:17:59.881803 New work for worker! Difficulty: 1.589736 Share difficulty: 1259.470588 Total block value: 25.004000 BTC including 6 transactions
2013-06-17 10:17:59.885549 New work for worker! Difficulty: 1.589736 Share difficulty: 1259.470588 Total block value: 25.004000 BTC including 6 transactions
2013-06-17 10:17:59.891466 New work for worker! Difficulty: 1.589736 Share difficulty: 1259.470588 Total block value: 25.004000 BTC including 6 transactions
2013-06-17 10:17:59.898578 New work for worker! Difficulty: 5.000000 Share difficulty: 1259.470588 Total block value: 25.004000 BTC including 6 transactions

0.020446 seconds

2013-06-17 10:23:14.937386 New work for worker! Difficulty: 1.336302 Share difficulty: 1245.582868 Total block value: 25.045000 BTC including 6 transactions
2013-06-17 10:23:14.940579 New work for worker! Difficulty: 1.336302 Share difficulty: 1245.582868 Total block value: 25.045000 BTC including 6 transactions
2013-06-17 10:23:14.943615 New work for worker! Difficulty: 1.336302 Share difficulty: 1245.582868 Total block value: 25.045000 BTC including 6 transactions
2013-06-17 10:23:14.946616 New work for worker! Difficulty: 1.336302 Share difficulty: 1245.582868 Total block value: 25.045000 BTC including 6 transactions
2013-06-17 10:23:14.952521 New work for worker! Difficulty: 5.000000 Share difficulty: 1245.582868 Total block value: 25.045000 BTC including 6 transactions

0.015135 seconds..   0 transactions probably comes with some base amount, i doubt the 6 adds much time at all

[gyverlb]

Very interesting, we'll have to ask forrestv if there's something to be done.

I suspected CPU speed might be a factor, but not as much as that because I don't have a public node anymore: my node only generates work for a single payout address for all my miners (there's only one "New work for workers" line for each new share in my case). I don't know how much latency this is on my node but according to your log, if I were running it on your hardware it would be ~90ms (which isn't so bad: thats less than 1% of the average interval and less than other latencies).

So if we didn't miss something, for people hosting a public node P2Pool work generation is on average <n/2>x slower than private nodes where <n> is the number of payout addresses.

Not sure about why you are receiving more traffic than sending and how it could affect orphan shares.

I'll link your post in the main p2pool thread.

[GrapeApe]

I'm still trying to wrap my head around why having all of the outgoing nodes helps. I made some changes zvs suggested dialled back a little with 30 outgoing vs. 60 like him because of bandwidth limitations but I don't get it. I'm not disagreeing because so far so good on my end (still too soon for any real conclusion) but I'm definitely confused.

[gyverlb]

I'm still trying to wrap my head around why having all of the outgoing nodes helps. I made some changes zvs suggested dialled back a little with 30 outgoing vs. 60 like him because of bandwidth limitations but I don't get it. I'm not disagreeing because so far so good on my end (still too soon for any real conclusion) but I'm definitely confused.

If you are writing about the P2Pool outgoing connections, so many can only hurt. P2Pool is event based in a single thread: by raising the number of connections you raise the rate of events and the time it spends processing them and being unavailable to provide work for miners. It's probably not much time, but if there's no good reasons to have more connections you definitely want to avoid raising them.

As said in my latest update of the guide, raising the total number of connections above 12 (4 outgoing, 8 incoming) didn't raise my efficiency.

I suspect zvs initial tuning results have been collected with older bitcoin and P2Pool versions (zvs latest tests with 1MB block have shown inefficiencies, but AFAIK from his reaction not to the extent zvs expected them).
Different versions behave differently and tuning recommendations must be updated (for example I did witness bad efficiencies with old P2Pool version when getblocktemplate was >0.2s and can't reproduce it anymore even with 0.5s).
I try to explain the process I follow in the guide so that people can try to find their own settings by themselves if my recommendations aren't optimal for them.

[zvs]

I have tons of outgoing connections, I don't get many orphans.  That's the point of all the connections.

Right now I have 1 in 47, and that one occurred at the very end of that 1,000,000 blocksize test...  prior to that, I had the 3 orphaned out of 256...  

6 outgoing connections only certainly isnt optimal, especially if you aren't listening for incoming connections... but, then, I only have 11 so far after node being online for over 12hrs.   One of them connects within seconds (*cough* p2pool-node).  Relying on 6 random outgoing connections to not get orphans?   Some crap shoot


oh, here's a good example of why you should at least do like 2500 block size:

New work for worker! Difficulty: 5.000000 Share difficulty: 1218.324058 Total block value: 25.915000 BTC including 3 transactions

[gyverlb]

I have tons of outgoing connections, I don't get many orphans.  That's the point of all the connections.

Right now I have 1 in 47, and that one occurred at the very end of that 1,000,000 blocksize test...  prior to that, I had the 3 orphaned out of 256...  

6 outgoing connections only certainly isnt optimal, especially if you aren't listening for incoming connections... but, then, I only have 11 so far after node being online for over 12hrs.   One of them connects within seconds (*cough* p2pool-node).  Relying on 6 random outgoing connections to not get orphans?   Some crap shoot


oh, here's a good example of why you should at least do like 2500 block size:

New work for worker! Difficulty: 5.000000 Share difficulty: 1218.324058 Total block value: 25.915000 BTC including 3 transactions

zvs, you only work by feeling, not stats. Feelings aren't good advisors...

1/
I've studied "6 random connections" for weeks and got 105+ efficiency constantly and most of the time 110+. It works, there's nothing to discuss if you didn't test it and then got bad efficiency repeatedly for days. Nothing is set in stones and things may change in the future, but right now there's no reason to advise to use large amount of connections unless you have hard data showing meaningful efficiency differences. There's one obvious reason to advise against it : it uses bandwidth that is limited: you use a dedicated server where it could be OK (additional CPU usage might make it bad) but many like me use an ADSL connection where it would simply kill efficiency (tested).

2/
your example of 25.915BTC with 3 transactions is just that, an example. Unless things changed dramatically these past days, there's no way you will get this amount of fees constantly with only 2500 block size. And even if it was the case, you'll have to compare both efficiency and fees to what you get with blockmaxsize=1_000_000 and other values to decide if it's advisable to use such a low block size.

[zvs]

I have tons of outgoing connections, I don't get many orphans.  That's the point of all the connections.

Right now I have 1 in 47, and that one occurred at the very end of that 1,000,000 blocksize test...  prior to that, I had the 3 orphaned out of 256...  

6 outgoing connections only certainly isnt optimal, especially if you aren't listening for incoming connections... but, then, I only have 11 so far after node being online for over 12hrs.   One of them connects within seconds (*cough* p2pool-node).  Relying on 6 random outgoing connections to not get orphans?   Some crap shoot


oh, here's a good example of why you should at least do like 2500 block size:

New work for worker! Difficulty: 5.000000 Share difficulty: 1218.324058 Total block value: 25.915000 BTC including 3 transactions

zvs, you only work by feeling, not stats. Feelings aren't good advisors...

1/
I've studied "6 random connections" for weeks and got 105+ efficiency constantly and most of the time 110+. It works, there's nothing to discuss if you didn't test it and then got bad efficiency repeatedly for days. Nothing is set in stones and things may change in the future, but right now there's no reason to advise to use large amount of connections unless you have hard data showing meaningful efficiency differences. There's one obvious reason to advise against it : it uses bandwidth that is limited: you use a dedicated server where it could be OK (additional CPU usage might make it bad) but many like me use an ADSL connection where it would simply kill efficiency (tested).

2/
your example of 25.915BTC with 3 transactions is just that, an example. Unless things changed dramatically these past days, there's no way you will get this amount of fees constantly with only 2500 block size. And even if it was the case, you'll have to compare both efficiency and fees to what you get with blockmaxsize=1_000_000 and other values to decide if it's advisable to use such a low block size.

First off... no kidding, there usually isn't some 1 BTC fee transaction that's 250 bytes in size.  Sometimes there is.  Are you arguing that I drop that down to 1500?    1,000,000 obviously is detrimental to *my* income, so why would I use it?  

You need to do some more studying if you think 6 random connections will get "105+ efficiency constantly and most of the time 110+".  I could possibly see a modified source allowing 0 outgoing connections and then 6 chosen connections added via --p2pool-node getting a low # of orphans

i would like to see this mythical node of yours, it isnt listed on http://p2pool.hostv.pl/  for sure.

[gyverlb]

i would like to see this mythical node of yours, it isnt listed on http://p2pool.hostv.pl/  for sure.

You demonstrated that running a public node hurts efficiency by delaying work delivery to miners and you want me to do it?

The worker port is blocked by my firewall, I used to have a public node in 2012 but when I started studying how p2pool behaves in various conditions I blocked the port to avoid any unwanted perturbation (I was worried about bandwidth usage at the time and it seems I should have been worried about P2Pool process delays).

No need to take my word for it or doubt it, just test it yourself and publish your data here for everyone to see and try to reproduce. If your results don't match mine we'll have to find our why: your last test with 1MB blockmaxsize was enlightening and made me create a github issue.

My current configuration for BTC P2Pool is 10 connections (5+5). One month ago it was 6 (3+3). I see the current additional 4 as a safety margin in case P2Pool's behavior changes or my node connects to several "bad" nodes at the same time (6 has been enough and is the lowest I consider relatively safe, I'm advising to use slightly higher values if possible in the guide and follow my own advice and prefer to have a margin when I'm not actively collecting efficiency numbers).

I'm about to test a different setting: less outgoing and more incoming to help people behind firewalls who can't forward ports and see if it lowers my efficiency.

[zvs]

Just for the record, it did this again:

2013-06-19 19:14:17.235456  Shares: 117 (2 orphan, 3 dead) Stale rate: ~4.3% (1-10%) Efficiency: ~121.5% (114-125%) Current payout: 0.3549 BTC
2013-06-19 19:14:19.021332 Skipping from block a3c01ac1b7431fe4f3b141091650172a0ca3f147ad5472ebe8 to block 44635c8d256559a4bbd27e36c84c0b1349102cfc99fd5645c7!
2013-06-19 19:14:19.421899 Punishing share for 'Block-stale detected! a3c01ac1b7431fe4f3b141091650172a0ca3f147ad5472ebe8 < 44635c8d256559a4bbd27e36c84c0b1349102cfc99fd5645c7'! Jumping from 0ed16b1a to 68f2aca3!
2013-06-19 19:14:21.264227 GOT SHARE! Drizztztzzztztzzzzztzz b9803115 prev 0ed16b1a age 2.22s DEAD ON ARRIVAL
2013-06-19 19:14:27.240538  Shares: 118 (2 orphan, 3 dead) Stale rate: ~4.2% (1-10%) Efficiency: ~121.6% (114-125%) Current payout: 0.3576 BTC
2013-06-19 19:14:37.245425  Shares: 118 (2 orphan, 3 dead) Stale rate: ~4.2% (1-10%) Efficiency: ~121.3% (114-125%) Current payout: 0.3576 BTC


though that time it said DOA, but gave me credit for it.

so I guess maybe it's messed up sometimes when that's going on.  maybe in a few of those other cases the same thing happened

though I wonder what '68f2aca3' was. scratch.

[GrapeApe]

Both of you guys have been extremely helpful to me so I'm reluctant to get in the middle here but isn't that what happens when you submit work for an old block.I found this in my log...

[2013-06-19 19:14:18] Stratum from pool 0 detected new block

edit: I realize I could have nothing useful to add here you two obviously are in a different league than me.

edit2: I'm sorry I do see your point now what did happen to '68f2aca3'?

[zvs]

Both of you guys have been extremely helpful to me so I'm reluctant to get in the middle here but isn't that what happens when you submit work for an old block.I found this in my log...

[2013-06-19 19:14:18] Stratum from pool 0 detected new block

edit: I realize I could have nothing useful to add here you two obviously are in a different league than me.

edit2: I'm sorry I do see your point now what did happen to '68f2aca3'?

that's the big question 

i didn't build off of 68f2aca3...

[notme]

BFL: if you have a BFL Single, an early FPGA MiniRig (cgminer has a parameter for later ones to fix them, check its documentation) or a BFL SC (ASIC) don't waste their hashrate on P2Pool, they have huge latencies and can't perform well on P2Pool. Put them on a traditional pool.

Are you sure, or are you just going off the FUD on these forums?  Clearly the FPGA products have an issue, but these guys claim the ASICs blow through an entire nonce range in a few ms:
https://forums.butterflylabs.com/jalapeno-single-sc-support/3367-reducing-20%25-hash-rate-penalty-using-bfl-hardware-p2pool.html#post42224

It would be a pity if the p2pool guide was turning away major hashpower unnecessarily.  In fact, looking above the linked post, there is the exact quote from above used to justify not participating in p2pool.

[gyverlb]

BFL: if you have a BFL Single, an early FPGA MiniRig (cgminer has a parameter for later ones to fix them, check its documentation) or a BFL SC (ASIC) don't waste their hashrate on P2Pool, they have huge latencies and can't perform well on P2Pool. Put them on a traditional pool.

Are you sure, or are you just going off the FUD on these forums?  Clearly the FPGA products have an issue, but these guys claim the ASICs blow through an entire nonce range in a few ms:
https://forums.butterflylabs.com/jalapeno-single-sc-support/3367-reducing-20%25-hash-rate-penalty-using-bfl-hardware-p2pool.html#post42224

It would be a pity if the p2pool guide was turning away major hashpower unnecessarily.  In fact, looking above the linked post, there is the exact quote from above used to justify not participating in p2pool.

ckolivas and kano confirmed this. The instruction supposed to be implemented in the communication protocol by BFL to interrupt work doesn't work and BFL didn't answer when asked if/when it will be fixed.

I didn't read the link but a Jalapeno is supposed to have 2 chips for ~5GH/s a whole nonce range is 4GH (nonce is a 32 bit field), do the math...

[notme]

BFL: if you have a BFL Single, an early FPGA MiniRig (cgminer has a parameter for later ones to fix them, check its documentation) or a BFL SC (ASIC) don't waste their hashrate on P2Pool, they have huge latencies and can't perform well on P2Pool. Put them on a traditional pool.

Are you sure, or are you just going off the FUD on these forums?  Clearly the FPGA products have an issue, but these guys claim the ASICs blow through an entire nonce range in a few ms:
https://forums.butterflylabs.com/jalapeno-single-sc-support/3367-reducing-20%25-hash-rate-penalty-using-bfl-hardware-p2pool.html#post42224

It would be a pity if the p2pool guide was turning away major hashpower unnecessarily.  In fact, looking above the linked post, there is the exact quote from above used to justify not participating in p2pool.

ckolivas and kano confirmed this. The instruction supposed to be implemented in the communication protocol by BFL to interrupt work doesn't work and BFL didn't answer when asked if/when it will be fixed.

I didn't read the link but a Jalapeno is supposed to have 2 chips for ~5GH/s a whole nonce range is 4GH (nonce is a 32 bit field), do the math...

Well, in the link we have an example of a Jalapeno in the wild running on a p2pool instance with better 100% efficiency.  But thanks for ignoring it.

[gyverlb]

BFL: if you have a BFL Single, an early FPGA MiniRig (cgminer has a parameter for later ones to fix them, check its documentation) or a BFL SC (ASIC) don't waste their hashrate on P2Pool, they have huge latencies and can't perform well on P2Pool. Put them on a traditional pool.

Are you sure, or are you just going off the FUD on these forums?  Clearly the FPGA products have an issue, but these guys claim the ASICs blow through an entire nonce range in a few ms:
https://forums.butterflylabs.com/jalapeno-single-sc-support/3367-reducing-20%25-hash-rate-penalty-using-bfl-hardware-p2pool.html#post42224

It would be a pity if the p2pool guide was turning away major hashpower unnecessarily.  In fact, looking above the linked post, there is the exact quote from above used to justify not participating in p2pool.

ckolivas and kano confirmed this. The instruction supposed to be implemented in the communication protocol by BFL to interrupt work doesn't work and BFL didn't answer when asked if/when it will be fixed.

I didn't read the link but a Jalapeno is supposed to have 2 chips for ~5GH/s a whole nonce range is 4GH (nonce is a 32 bit field), do the math...

Well, in the link we have an example of a Jalapeno in the wild running on a p2pool instance with better 100% efficiency.  But thanks for ignoring it.

Don't post inaccurate information and I won't ignore it. You reference a post quoting an assertion that is clearly bullshit: "these guys claim the ASICs blow through an entire nonce range in a few ms". Why do you still expect me to waste my time with a post like this when I clearly explained it was impossible 2 posts earlier?

Now a newbie user (seems to be the same) claimed in the P2Pool thread that he got 106% efficiency after enough shares that it shouldn't be a fluke so I'll update my guide to reflect that. But I certainly won't write that BFL Asics are working properly, only that they might: between a newbie report I don't know at all and ckolivas' report there's clearly a difference in trust.
This would change if for example ckolivas confirmed that his device is working properly and he made a mistake in his earlier tests, there's a new firmware for BFL ASICs solving early problems or there are some other trusted user reporting good efficiency.
Currently I have conflicting reports with the most trusted user claiming it doesn't work properly with p2pool and a newbie I don't know claiming otherwise, like I said in my earlier post... do the math!

If I were in your shoes, I'll look for an explanation for why ckolivas' ASIC didn't work like it should or find trusted members of the forum to verify the newbie's claim. I'm only collecting information here, if there isn't enough information I can't do much.

[bitpop]

I too got 106% efficiency, without jalapeno 115. Using slush to be safe for now hoping for a fix. I'll be back either way.

Many many rejects but I guess it didn't matter

http://imgur.com/EOVlFrm

Im wrong, it was skewed by 10ghs of other miners. Only 10/20ghs was jalapeno.

[gyverlb]

Guide updated for conflicting reports about BFL ASICs and one success report for ASICMINER Block Erupter blades.

[gigq]

Guide updated for conflicting reports about BFL ASICs and one success report for ASICMINER Block Erupter blades.

Hi, I'm the newbie mentioned.  Thanks for updating the guide with my findings.  Hopefully more users will try their BFL ASICs on P2Pool as they get them and we can get more evidence either way.

FWIW my local DOA rate is high (Local rate: 5.64GH/s (22% DOA) Expected time to share: 0.206 hours) but my efficiency has been fine (Shares: 43 total (3 orphaned, 3 dead) Efficiency: 105.6%).  The only change I have done over stock cgminer is I run it with username/6000 to increase the share difficulty.  This was suggested by a user on the BFL forums.

If you have any questions or want me to share anymore information I'd be happy to.

[notme]

BFL: if you have a BFL Single, an early FPGA MiniRig (cgminer has a parameter for later ones to fix them, check its documentation) or a BFL SC (ASIC) don't waste their hashrate on P2Pool, they have huge latencies and can't perform well on P2Pool. Put them on a traditional pool.

Are you sure, or are you just going off the FUD on these forums?  Clearly the FPGA products have an issue, but these guys claim the ASICs blow through an entire nonce range in a few ms:
https://forums.butterflylabs.com/jalapeno-single-sc-support/3367-reducing-20%25-hash-rate-penalty-using-bfl-hardware-p2pool.html#post42224

It would be a pity if the p2pool guide was turning away major hashpower unnecessarily.  In fact, looking above the linked post, there is the exact quote from above used to justify not participating in p2pool.

ckolivas and kano confirmed this. The instruction supposed to be implemented in the communication protocol by BFL to interrupt work doesn't work and BFL didn't answer when asked if/when it will be fixed.

I didn't read the link but a Jalapeno is supposed to have 2 chips for ~5GH/s a whole nonce range is 4GH (nonce is a 32 bit field), do the math...

Well, in the link we have an example of a Jalapeno in the wild running on a p2pool instance with better 100% efficiency.  But thanks for ignoring it.

Don't post inaccurate information and I won't ignore it. You reference a post quoting an assertion that is clearly bullshit: "these guys claim the ASICs blow through an entire nonce range in a few ms". Why do you still expect me to waste my time with a post like this when I clearly explained it was impossible 2 posts earlier?

Now a newbie user (seems to be the same) claimed in the P2Pool thread that he got 106% efficiency after enough shares that it shouldn't be a fluke so I'll update my guide to reflect that. But I certainly won't write that BFL Asics are working properly, only that they might: between a newbie report I don't know at all and ckolivas' report there's clearly a difference in trust.
This would change if for example ckolivas confirmed that his device is working properly and he made a mistake in his earlier tests, there's a new firmware for BFL ASICs solving early problems or there are some other trusted user reporting good efficiency.
Currently I have conflicting reports with the most trusted user claiming it doesn't work properly with p2pool and a newbie I don't know claiming otherwise, like I said in my earlier post... do the math!

If I were in your shoes, I'll look for an explanation for why ckolivas' ASIC didn't work like it should or find trusted members of the forum to verify the newbie's claim. I'm only collecting information here, if there isn't enough information I can't do much.

I'm sorry I didn't do the digging to figure it out for you.  It appears it is raising the share difficulty that saves your efficiency.  I just figured you were the expert and could figure it out easier.  Sorry for wasting your time.  I clearly keyed in on an incorrect statement, which caused you to dismiss everything I had to say.

[gigq]

Here are some screen shots of my P2Pool and cgminer output if they help:

http://imgur.com/a/cfqgK

[zvs]

Here are some screen shots of my P2Pool and cgminer output if they help:

http://imgur.com/a/cfqgK

do you have to use stratum?   it has some 1/2 second delay or so for me

it looks like whatever you're using has 1500-2000ms latency.  so we'll be optimistic and consider that 15% DOA.     now, can you set up your pool so you have 5% or less orphans?  probably not with 6 outgoing connections and 0 incoming

i don't understand why people run pools locally when they'd be better off using a remote server.  i ran mine locally for about 2 days

[gyverlb]

Here are some screen shots of my P2Pool and cgminer output if they help:

http://imgur.com/a/cfqgK

do you have to use stratum?   it has some 1/2 second delay or so for me

it looks like whatever you're using has 1500-2000ms latency.  so we'll be optimistic and consider that 15% DOA.     now, can you set up your pool so you have 5% or less orphans?  probably not with 6 outgoing connections and 0 incoming

i don't understand why people run pools locally when they'd be better off using a remote server.  i ran mine locally for about 2 days

zvs, your experience is only showing what works for you and may not apply to others, it must be compared to other results to be meaningful.

Based on what we already know, the right choice depends on what your options are and is a bit difficult to find: by moving the node to a remote server you save on the bandwidth used on your local connection (miner <-> node traffic is very low compared to node <-> P2Pool network traffic) but you may add a bit of latency to your setup (miner <-> P2Pool network traffic is routed through the remote host you choose).

If you don't have any local bandwidth problems, using a remote node adds latency to your setup. That said if you chose the remote node right this additional latency might be negligible and even be compensated by other gains. For example if your remote node has more CPU power available for bitcoind and P2Pool you can get an advantage there.

If you have local bandwidth problems, using a remote node might be a safe bet, but using a public node will either decrease the fees P2Pool users get or add latency. The best solution then is a dedicated node (until there's a fix for the high latencies with multi-payout addresses on a single node case).

[gyverlb]

Guide updated for conflicting reports about BFL ASICs and one success report for ASICMINER Block Erupter blades.

Hi, I'm the newbie mentioned.  Thanks for updating the guide with my findings.  Hopefully more users will try their BFL ASICs on P2Pool as they get them and we can get more evidence either way.

Hope so, sorry if I look paranoid, but it seems that sockpuppetting is an official bitcointalk sport now and there's big money involved: if a vendor looks bad on P2Pool even if we aren't a big pool it probably can reflect on sales.

FWIW my local DOA rate is high (Local rate: 5.64GH/s (22% DOA) Expected time to share: 0.206 hours) but my efficiency has been fine (Shares: 43 total (3 orphaned, 3 dead) Efficiency: 105.6%).  The only change I have done over stock cgminer is I run it with username/6000 to increase the share difficulty.  This was suggested by a user on the BFL forums.

If you have any questions or want me to share anymore information I'd be happy to.

Hum, are you sure you changed your share difficulty in the screenshots you published? Your expected share interval doesn't match a 6000 difficulty with a 5.5GH/s device but matches the current ~1000 difficulty.
43 shares isn't bad for estimating efficiency, but 100 would be better (the confidence interval is still 89-115 in your screenshot). With your hashrate, waiting for one or 2 whole days instead of ~10 hours would help estimate your actual efficiency.

[gyverlb]

I'm sorry I didn't do the digging to figure it out for you.  It appears it is raising the share difficulty that saves your efficiency.  I just figured you were the expert and could figure it out easier.  Sorry for wasting your time.  I clearly keyed in on an incorrect statement, which caused you to dismiss everything I had to say.

Sorry if I look a bit harsh, but I don't spend much time on bitcointalk right now: I have a lot of work currently and I'm slowly recovering from a broken back at the same time so if I even suspect I won't find useful information I don't dig to save time.
The meds I take may not help either: they are known to have several side effects on the mood and short-temper is one (I may be predisposed for this one...).

Raising share difficulty may not be the solution: as I wrote in the previous post the published results match a configuration with standard share difficulty.

[bitpop]

Hard fork coming!
https://bitcointalk.org/index.php?topic=18313.msg2562076#msg2562076

[notme]

I'm sorry I didn't do the digging to figure it out for you.  It appears it is raising the share difficulty that saves your efficiency.  I just figured you were the expert and could figure it out easier.  Sorry for wasting your time.  I clearly keyed in on an incorrect statement, which caused you to dismiss everything I had to say.

Sorry if I look a bit harsh, but I don't spend much time on bitcointalk right now: I have a lot of work currently and I'm slowly recovering from a broken back at the same time so if I even suspect I won't find useful information I don't dig to save time.
The meds I take may not help either: they are known to have several side effects on the mood and short-temper is one (I may be predisposed for this one...).

Raising share difficulty may not be the solution: as I wrote in the previous post the published results match a configuration with standard share difficulty.

I'm sorry to hear that.  I truly wish you have a speedy recovery.  Thank you for updating the guide to be less discouraging for BFL owners.  P2Pool is experiencing very long block times and if BFL hardware can potentially help with that we should certainly admit it is complicated, but not actively discourage them from trying.

[maqifrnswa]

Re: p2pool and BFL SCs

There appears to have been a recent change to the firmware from one job per board to one job per chip
https://forums.butterflylabs.com/announcements/692-bfl-asic-status-3.html#post43041

They claim, "This has fixed a lot of the latency issues we were experiencing with the early firmware."

jalepenos only have 2 chips, so at best this is a factor of 2...

Anyways, the new p2pool release should help a bit too.

[gyverlb]

Future changes will indeed be a game-changer for miners with high latencies (mainly Avalon and BFL ASICs).

If you read this and are/were discouraged by low Avalon or BFL efficiency, please watch this thread and/or the main P2Pool thread to be notified when the fork becomes active, testing P2Pool after that will probably change your results for the better.

[gyverlb]

Re: p2pool and BFL SCs

There appears to have been a recent change to the firmware from one job per board to one job per chip
https://forums.butterflylabs.com/announcements/692-bfl-asic-status-3.html#post43041

They claim, "This has fixed a lot of the latency issues we were experiencing with the early firmware."

jalepenos only have 2 chips, so at best this is a factor of 2...

Anyways, the new p2pool release should help a bit too.

Does not compute in our case. If you suppose you can't interrupt a job, having one per board is better as it finishes faster.

So either Josh didn't understand at all and the switch was from one per chip to one per board (which would be good for P2Pool) or they solved a problem completely different from what was spotted by ckolivas (and it's probably bad for P2Pool, you might not want to update your firmware unless you can downgrade it later).

[notme]

Re: p2pool and BFL SCs

There appears to have been a recent change to the firmware from one job per board to one job per chip
https://forums.butterflylabs.com/announcements/692-bfl-asic-status-3.html#post43041

They claim, "This has fixed a lot of the latency issues we were experiencing with the early firmware."

jalepenos only have 2 chips, so at best this is a factor of 2...

Anyways, the new p2pool release should help a bit too.

Does not compute in our case. If you suppose you can't interrupt a job, having one per board is better as it finishes faster.

So either Josh didn't understand at all and the switch was from one per chip to one per board (which would be good for P2Pool) or they solved a problem completely different from what was spotted by ckolivas (and it's probably bad for P2Pool, you might not want to update your firmware unless you can downgrade it later).

EDIT: Come to think of it, you are probably right since the chips should compute nonce ranges in very close to the same amount of time, so I'm happy if you ignore this.  I'll just post in case anyone else has a similar objection.

Are you sure about that?  Needing to reset work is a stochastic event and thus each chip will be somewhere in the range from just starting to almost done.  You are very clearly right if all chips are synchronized, but I'm not sure they are.  I'm a bit weak on stats, so I'm not sure here.  I could probably review a proof, but if I had to prove it either way myself, I would probably just do a monte carlo simulation.

[daemondazz]

It would be a maximum of twice as responsive for the jallies, assuming each chip starts work 180 degrees from each other.

[notme]

It would be a maximum of twice as responsive for the jallies, assuming each chip starts work 180 degrees from each other.

And potentially much better with the rigs with higher chip counts, but in practice they would likely be fairly close to synced, so the improvement would be small if it even surpassed the extra overhead.

[Mr. Jinx]

I have a question about DOA's and efficiency.

With p2pool scrypt-mining (ltc) I get a local rate of 2MH/s with 20% DOA. This is with intensity in cgminer set at 20.
If I lower intensity to 17, the local rate drops to 1.8MH/s with DOA 3%.
In both cases, efficiency is 100%+

Which one is better, 2MH/s with 20% DOA, or 1.8MH/s with 3% DOA?

[bitpop]

1.8MH/s with 3% DOA

[daemondazz]

Which one is better, 2MH/s with 20% DOA, or 1.8MH/s with 3% DOA?

The math is pretty simple:

2MH/s - 20% = 1.6MH/s effective
1.8MH/s - 3% = 1.747MH/s effective

[gyverlb]

Which one is better, 2MH/s with 20% DOA, or 1.8MH/s with 3% DOA?

The math is pretty simple:

2MH/s - 20% = 1.6MH/s effective
1.8MH/s - 3% = 1.747MH/s effective

The OP on this particular subject should do the math for intensity 18 and 19 too. I'll guesstimate that 19 should be the right spot.

Edit: BTW, as soon as the P2Pool network you are on switch to a 30s block interval (BTC and LTC will) all these computations will have to be done again.

[Mr. Jinx]

Thanks for clarifying! There was some confusion in this thread where someone said DOA's are not wasted work and can still payout.

[maqifrnswa]

I have a question about DOA's and efficiency.

With p2pool scrypt-mining (ltc) I get a local rate of 2MH/s with 20% DOA. This is with intensity in cgminer set at 20.
If I lower intensity to 17, the local rate drops to 1.8MH/s with DOA 3%.
In both cases, efficiency is 100%+

Which one is better, 2MH/s with 20% DOA, or 1.8MH/s with 3% DOA?

DOA shares do payout and don't necessarily negatively affect payout (as long as you have < average DOA) but in the case of a difference of 3% and 20% - that should affect payout.

In both cases efficiency is > 100%, but were they the same?

Please correct me if I'm wrong, but shouldn't the real calculation be:

2MH/s x efficiency = effective rate
1.8MH/s x efficiency = effective rate

Not
MH/s - doa% = effective rate

[gyverlb]

Thanks for clarifying! There was some confusion in this thread where someone said DOA's are not wasted work and can still payout.

DOAs aren't wasted work and can still generate a valid block which would pay everyone.

However DOAs aren't used to compute the share of a miner in the payouts, only shared accepted in the sharechain. This is explained in more details in the original post of this thread.

[abbeytim]

hi I have a question p2pool is sending my miner diff 1 shares and I want it to send the p2pool diff


now somewhere I read you could put /1000 next to the miners name so I tried user/1000 and its still getting diff 1 shares from p2pool

[gyverlb]

hi I have a question p2pool is sending my miner diff 1 shares and I want it to send the p2pool diff


now somewhere I read you could put /1000 next to the miners name so I tried user/1000 and its still getting diff 1 shares from p2pool

This is a question better asked in the main P2Pool thread (see first post for a link).

[gyverlb]

Just updated the guide as there was a second detailed report in the main P2Pool thread here. Please include cgminer's API output when reporting results with BFL Asics, it might help pinpoint which firmwares and/or configurations work best with P2Pool.

[gyverlb]

Just updated the guide to account for the new BTC 30 second interval, the current hashrate and the upcoming Avalon fix(es).

TL;DR;:

• more hardware should work efficiently (Avalon is still not working correctly but should be shortly),
• most setup should be good enough on P2Pool now without tuning,
• tuning should still squeeze some extra income.

[Krellan]

Nice guide!

Just read it, glad to see it's been updated for the new fork (30 second share clock, instead of 10 second).

I don't think I have a problem with latency.  Had a big problem with total bandwidth consumption, though.  My cable ISP doesn't like large users of bandwidth.  So, I'm glad I keep a backup DSL line.  Ports 8333 and 9333 now go there.  Works great, my DSL is ideal for continuous P2P background traffic like this: it has a slow top speed, because it's DSL, but it has good response time, and it's unmetered.

Thanks for the tip about tuning the bitcoin.conf settings, so that bitcoind is more generous about the transactions it accepts.  It was worth a Bitcoin restart, so I did that.  Also gave me the chance to test my restart scripts.  I rather like how P2Pool does true mining (your node gets to dictate the contents of the block if you win).

Here's my stats (don't laugh):

Code:

Pool rate: 1.43TH/s (13% DOA+orphan) Share difficulty: 7300
Node uptime: 5.309 days Peers: 11 out, 5 in
Local rate: 308MH/s (9.3% DOA) Expected time to share: 28.3 hours
Shares: 14 total (3 orphaned, 0 dead) Efficiency: 89.92%

Josh

[zvs]

Tune bitcoind and P2Pool
If you can't use the methods above or they aren't enough you can limit the number of connections used by bitcoind and P2Pool.

For bitcoind, use the parameter maxconnections in bitcoin.conf

Code:

maxconnections=10 # 125 is the default, don't go below 8

There's a compromise here: the more connections, the faster your node will be notified of new blocks and avoid wasting work, the faster it can include transactions with fees in the coinbase and the faster it will propagate a P2Pool block minimizing chances it would become orphan.
But the less connections, the less bandwidth used and the lower the latency.

More than 20 for maxconnections is probably overkill: from my experience (trying various values from 6 to 100) it seems there's not much gain to have past this value (and if you don't have enough WAN bandwidth it can hurt your latencies by queuing transfers between P2Pool nodes during peaks).
Note that this may change in the future if the behavior of bitcoind/P2Pool network changes: when in doubt, monitor your interface(s) bandwidth usage and raise this value when most peaks are below your link capacity.

If your orphan rate is fine, don't tempt the devil and try tuning maxconnections below 20: you may reduce your income more than you increase it...

Warning: P2Pool needs one connection to bitcoind and bitcoind tries to fill all the allowed connections after startup. If you start P2Pool just after bitcoind (or before, it will repeatedly try to connect), it shouldn't have problem connecting because bitcoind will still have connection slots available. If you set maxconnections too low P2Pool might not succeed connecting.

For P2Pool, you can do the same by passing parameters to P2Pool:

Code:

--max-conns 8 --outgoing-conns 4

Note: orphans will quickly rise if you have very few connections (they are the means to be notified of other shares after all). I would prefer reducing bitcoind connections before P2Pool's.

In my experience you can get as low as 6 total connections (3 in, 3 out) without noticeable efficiency changes. The default values seem overkill (6 outgoing, 40 incoming). The large number of incoming connections (--max-conns) is designed to help the whole network (some nodes are behind firewalls that don't allow incoming connections). You probably should allow more incoming connections (and check that your network setup allows incoming connections) to do your part in helping the network.

i started local node again about a week ago and haven't had any problems with maxconnections=2, port=(non-standard, or you can just firewall all but the one IP from the bitcoind port).  then i just use connect=5.9.24.81.  the 2nd connection is used by p2pool.  so essentially it just introduces a maximum 175ms delay on new transactions or blocks (the average would be much less).

(it's possible now since p2pool doesnt consume nearly as much bandwidth with just 2 works per minute instead of 6)

[DopeLabs]

Known bugs/issues

Q: Why do I get lots of "Worker <name> submitted share with hash > target:" in my P2Pool logs? It seems to put a large CPU load on P2Pool.
A: If you use cgminer, scrypt and stratum, this is because cgminer and p2pool disagree on how to represent difficulty targets on stratum. p2pool seems to use a sane definition of target difficulty, unfortunately most other pools didn't establishing a de-facto standard that cgminer follows. Current solution: use the "--fix-protocol" parameter of cgminer. It will force it to use getwork (instead of stratum) where both agree on how to communicate difficulty targets.

one of my miners is an ASICMiner Eruptor Blade, which i believe uses getwork, but i am still seeing the hash > target msgs on the cli fly by...

any idea as to why it would still be doing this considering its using getwork? and is there anything that can be done to fix?

[gyverlb]

Known bugs/issues

Q: Why do I get lots of "Worker <name> submitted share with hash > target:" in my P2Pool logs? It seems to put a large CPU load on P2Pool.
A: If you use cgminer, scrypt and stratum, this is because cgminer and p2pool disagree on how to represent difficulty targets on stratum. p2pool seems to use a sane definition of target difficulty, unfortunately most other pools didn't establishing a de-facto standard that cgminer follows. Current solution: use the "--fix-protocol" parameter of cgminer. It will force it to use getwork (instead of stratum) where both agree on how to communicate difficulty targets.

one of my miners is an ASICMiner Eruptor Blade, which i believe uses getwork, but i am still seeing the hash > target msgs on the cli fly by...

any idea as to why it would still be doing this considering its using getwork? and is there anything that can be done to fix?

Does the Eruptor Blade support variable difficulty? If not then these messages are normal. You might want to ask ASICMINER about how their miner software reacts with difficulties different than 1.

[-ck]

Known bugs/issues

Q: Why do I get lots of "Worker <name> submitted share with hash > target:" in my P2Pool logs? It seems to put a large CPU load on P2Pool.
A: If you use cgminer, scrypt and stratum, this is because cgminer and p2pool disagree on how to represent difficulty targets on stratum. p2pool seems to use a sane definition of target difficulty, unfortunately most other pools didn't establishing a de-facto standard that cgminer follows. Current solution: use the "--fix-protocol" parameter of cgminer. It will force it to use getwork (instead of stratum) where both agree on how to communicate difficulty targets.

one of my miners is an ASICMiner Eruptor Blade, which i believe uses getwork, but i am still seeing the hash > target msgs on the cli fly by...

any idea as to why it would still be doing this considering its using getwork? and is there anything that can be done to fix?

Notice that says scrypt with cgminer which does not apply to bitcoin. Eruptors don't have any way to set difficulty, they have extremely simple mining software built in that only does diff 1. You could probably use the stratum proxy by slush between the blades and your p2pool software to get rid of the message, but not sure if that really gains you anything but adds another layer ...

[gyverlb]

Notice that says scrypt with cgminer which does not apply to bitcoin. Eruptors don't have any way to set difficulty, they have extremely simple mining software built in that only does diff 1. You could probably use the stratum proxy by slush between the blades and your p2pool software to get rid of the message, but not sure if that really gains you anything but adds another layer ...

And this is a problem which has been solved long ago (p2pool is using the same protocol than other pools for quite some time).

I changed the FAQ entry and suggested using stratum-proxy when it becomes a problem (might help by distributing the load across CPU cores or handling share submissions more efficiently than p2pool).

[DopeLabs]

ive tried using the stratum proxy but for some reason when i have it connected to p2pool the AM Blade just doesnt connect and start hashing... it works on btcguild... but not p2pool for some reason...

[DopeLabs]

so on the wiki it states that setting the username with an appended '+1" will make P2Pool always give your miners work with a difficulty of 1...

will this have any negative effect?

[gyverlb]

The last questions should probably be asked in the main p2pool thread

This guide is for information related to mining efficiently on p2pool, it shouldn't duplicate information on how to use p2pool or stratum-proxy (the guide is already too long to my taste). That said, I've never used stratum-proxy, if someone find out there are specific configuration options to use to make it efficient with p2pool and some hardware, I'd gladly add them to the guide.

[jimsonunique]

when i first tried p2pool all i did was point my miner at p2pool.org. After a while my graph was showing hashrate + payout.

now if i try it my graph shows hashrate but never get payout. i never knew about setting up p2pool before hand i just pointed miner at it.

is it even possible to use p2pool that way? or do you HAVE to run bit coin/p2pool aswell?

[rav3n_pl]

No, when you using "outside" node you not have to run bitcoin nor p2pool, only miner.
How much power you have? BTC share diff is about 22`500 now.

[zvs]

when i first tried p2pool all i did was point my miner at p2pool.org. After a while my graph was showing hashrate + payout.

now if i try it my graph shows hashrate but never get payout. i never knew about setting up p2pool before hand i just pointed miner at it.

is it even possible to use p2pool that way? or do you HAVE to run bit coin/p2pool aswell?

p2pool.org was on the wrong chain for several weeks, but it's been v13 for at least the last 10 days

1ghash averages a share every 24hrs or so at current hash rate

and don't use p2pool.org,

go to http://p2pool-nodes.info/ or http://p2pool.hostv.pl/     and find something better

[jimsonunique]

when i first tried p2pool all i did was point my miner at p2pool.org. After a while my graph was showing hashrate + payout.

now if i try it my graph shows hashrate but never get payout. i never knew about setting up p2pool before hand i just pointed miner at it.

is it even possible to use p2pool that way? or do you HAVE to run bit coin/p2pool aswell?

p2pool.org was on the wrong chain for several weeks, but it's been v13 for at least the last 10 days

1ghash averages a share every 24hrs or so at current hash rate

and don't use p2pool.org,

go to http://p2pool-nodes.info/ or http://p2pool.hostv.pl/     and find something better

why do the graphs never show any payout, even if i left it on for over 24 hours. But the first time i ever used p2pool it was showing payout within a couple of hours ?!

[notme]

when i first tried p2pool all i did was point my miner at p2pool.org. After a while my graph was showing hashrate + payout.

now if i try it my graph shows hashrate but never get payout. i never knew about setting up p2pool before hand i just pointed miner at it.

is it even possible to use p2pool that way? or do you HAVE to run bit coin/p2pool aswell?

p2pool.org was on the wrong chain for several weeks, but it's been v13 for at least the last 10 days

1ghash averages a share every 24hrs or so at current hash rate

and don't use p2pool.org,

go to http://p2pool-nodes.info/ or http://p2pool.hostv.pl/     and find something better

why do the graphs never show any payout, even if i left it on for over 24 hours. But the first time i ever used p2pool it was showing payout within a couple of hours ?!

Share difficulty has increased dramatically in the last few months.  Also, 24 hours for 1gh/s is an average.  Variance can potentially widen the window before you hit for you first share to 2 days, but over time it will average out.

[nibor]

Just to say I followed this advice and have a Bitforce-SC 60Ghash running perfectly.

See cross post https://bitcointalk.org/index.php?topic=18313.msg3007436#msg3007436 for details.

Thanks for the great advice.

[ylame]

I'm trying to use ASICMiner erupter blade, which only supports getwork with p2pool. I can't get it to work.

When I have the blade connected directly to p2pool, I see lot's of
Worker <name> submitted share with hash > target:" in my P2Pool logs

So I setup a stratum proxy which work fine with 50btc.com but when I use it with the p2pool, the blades get no work. It sit's ideal.

What am I missing? Are there any specific version's that should be using?

[DopeLabs]

I'm trying to use ASICMiner erupter blade, which only supports getwork with p2pool. I can't get it to work.

When I have the blade connected directly to p2pool, I see lot's of
Worker <name> submitted share with hash > target:" in my P2Pool logs

So I setup a stratum proxy which work fine with 50btc.com but when I use it with the p2pool, the blades get no work. It sit's ideal.

What am I missing? Are there any specific version's that should be using?

this is a normal message when using blades. what you want to do is add: +1 to the end of your username on the blade web interface. this will force p2pool to always give the blade diff1 work, since it only knows diff 1 anyways. this will stop those log messages. you might see one or two here or there..... also the blades dont seem to work with p2pool via stratum mining proxy.

[ylame]

I'm trying to use ASICMiner erupter blade, which only supports getwork with p2pool. I can't get it to work.

When I have the blade connected directly to p2pool, I see lot's of
Worker <name> submitted share with hash > target:" in my P2Pool logs

So I setup a stratum proxy which work fine with 50btc.com but when I use it with the p2pool, the blades get no work. It sit's ideal.

What am I missing? Are there any specific version's that should be using?

this is a normal message when using blades. what you want to do is add: +1 to the end of your username on the blade web interface. this will force p2pool to always give the blade diff1 work, since it only knows diff 1 anyways. this will stop those log messages. you might see one or two here or there..... also the blades dont seem to work with p2pool via stratum mining proxy.

Thank you, this seems to have reduced the number of errors in the log. I still see couple of them, but much less. I don't have QoS set on my network but the p2pool and the blade are on the same LAN. Would it be of any help to setup QoS?

Thank you

[gyverlb]

[...]
I don't have QoS set on my network but the p2pool and the blade are on the same LAN. Would it be of any help to setup QoS?

Thank you

Between miners and p2pool on a LAN it would probably not help at all. QoS is useful on links were saturation occurs, typically the WAN links.

[semaster]

Hi. Would like to ask about latency
Why going below 0.2s will hurt your income and everyone else's on P2Pool. ?
What is the reason of that?

[HellDiverUK]

Hi. Would like to ask about latency
Why going below 0.2s will hurt your income and everyone else's on P2Pool. ?
What is the reason of that?

It doesn't.

[gyverlb]

Hi. Would like to ask about latency
Why going below 0.2s will hurt your income and everyone else's on P2Pool. ?
What is the reason of that?

It doesn't.

It does because lowering the getblocktemplate latency is a tradeoff.
As explained in the guide with current bitcoind version reducing this latency is done by reducing the number of transactions you include in the template. Doing so you reduce the fees included in the blocks you find : you reduce your own income and everyone else's when this happens.

Today this latency has only a negative effect when a new block is found by the whole network (every ~10 minutes) unless you have a very weak CPU (where CPU usage by bitcoind can slow down P2Pool).
This is the same effect for P2Pool and every other pool : until a getblocktemplate returns a result after a new block, the pool can only work on an empty template (no transaction). Going below 0.2s only tries to reduce this 0.2/600 = 0.03% negative impact on the fees income (the block reward isn't impacted) : including more transactions (which amounts to ~1% of the average block value) simply brings more income to everyone including yourself.

[semaster]

Is there a way to restart p2pool node and to save local shares statistic?

[gyverlb]

Is there a way to restart p2pool node and to save local shares statistic?

I'm not sure I understand the question but it's probably more suited for the main thread.

[smoothrunnings]

Wow this is a great thread!

[cr1776]

Just in case you weren't aware, it appears in the first post on the first page, the link here:

P2Pool's page on the Bitcoin Wiki
is

Code:

http://"https://en.bitcoin.it/wiki/P2Pool"

so it does not work.  This has been an interesting read btw.  ;-)

[roy7]

Now that Amazon has EC2 instances that can use SSD for disk, I keep thinking how cool it'd be to run a p2pool node + bitcoind in a really high performance way. However is the speed savings from SSD just a waste of extra cost? It seems the low latencies people get from proper tuning are off of normal disk. (EC2 SSD is also "instance" storage, so it doesn't persist if the instance is stopped, which adds some complexity to back up the block chain and p2pool stats in a way you can restore late.)

Just wondering if my idle thinking about an all-SSD setup is a waste of time?

[smoothrunnings]

Now that Amazon has EC2 instances that can use SSD for disk, I keep thinking how cool it'd be to run a p2pool node + bitcoind in a really high performance way. However is the speed savings from SSD just a waste of extra cost? It seems the low latencies people get from proper tuning are off of normal disk. (EC2 SSD is also "instance" storage, so it doesn't persist if the instance is stopped, which adds some complexity to back up the block chain and p2pool stats in a way you can restore late.)

Just wondering if my idle thinking about an all-SSD setup is a waste of time?

Most of the latency in p2pool miners are from the  pool owners own internet connection. It looks like P2Pool needs at least 800KB/s bi-directional. So if you have an internet connection with 800KB or 1Meg upload you should invest in a faster connection.

I stopped running my P2Pool on my Xi3 Z3RO Pro (www.xi3.com) 4GB DDR3, and 120GB mSATA because of the other latency issues, so now I have it running on my ESXi 5.5 server in it's own guest VM, it runs a lot better. My ESXi server is an IBM xSeries server, with RAID, and 12/24 cores, etc.

But I have found the internet is really the key to reducing the latency. 

[kevintmckay]

Thanks for this guide,

I am wondering if the tuning perimeters below from your guide are applicable to litecoin and other script currencies as well?

I ready through all 8 pages and did not see any mention of this sorry if I missed it.

Thanks

blockmaxsize=1000000
mintxfee=0.00001
minrelaytxfee=0.00001

maxconnections=10 # 125 is the default, don't go below 8

--max-conns 8 --outgoing-conns 4


blockmaxsize=250000 #default is 500000
If you don't have this problem, you should raise the blockmaxsize value instead to get more income:
Code:
blockmaxsize=1000000 #default is 500000

# default is 500000, 1000000 is the maximum allowed and will fit more transactions (more fees)
blockmaxsize=1000000
#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.00001
# Same but for relaying the tx to our peers
minrelaytxfee=0.00001

[roy7]

Most of the latency in p2pool miners are from the  pool owners own internet connection. It looks like P2Pool needs at least 800KB/s bi-directional. So if you have an internet connection with 800KB or 1Meg upload you should invest in a faster connection.

Hmm I thought p2pool was supposed to be fairly light weight on bandwidth usage?

http://82.196.8.44:9332/static/graphs.html?Day

That's the biggest public node, with a mean of 10.4kB/s.

[smoothrunnings]

FYI, QOS only works on OUTGOING traffic only your LAN, doesn't work on traffic coming back into your network from your WAN port.

So shaping the outgoing traffic is only good if you are running a porn site on the same network as your P2Pool!

[smoothrunnings]

Figuring this is a bitcoin forum its more than likely the OP is talking about Bitcoin only.

Thanks for this guide,

I am wondering if the tuning perimeters below from your guide are applicable to litecoin and other script currencies as well?

I ready through all 8 pages and did not see any mention of this sorry if I missed it.

Thanks

blockmaxsize=1000000
mintxfee=0.00001
minrelaytxfee=0.00001

maxconnections=10 # 125 is the default, don't go below 8

--max-conns 8 --outgoing-conns 4


blockmaxsize=250000 #default is 500000
If you don't have this problem, you should raise the blockmaxsize value instead to get more income:
Code:
blockmaxsize=1000000 #default is 500000

# default is 500000, 1000000 is the maximum allowed and will fit more transactions (more fees)
blockmaxsize=1000000
#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.00001
# Same but for relaying the tx to our peers
minrelaytxfee=0.00001

[jedimstr]

FYI, QOS only works on OUTGOING traffic only your LAN, doesn't work on traffic coming back into your network from your WAN port.

So shaping the outgoing traffic is only good if you are running a porn site on the same network as your P2Pool!

Not true... Depends on the features of your router.

Mine allows detailed QoS priority settings for Outgoing and Incoming connections separately across the WAN <-> LAN and can also limit settings across various LAN IPs.

If your router only supports outgoing QoS, it's a shitty router/switch.

[bitpop]

FYI, QOS only works on OUTGOING traffic only your LAN, doesn't work on traffic coming back into your network from your WAN port.

So shaping the outgoing traffic is only good if you are running a porn site on the same network as your P2Pool!

Not true... Depends on the features of your router.

Mine allows detailed QoS priority settings for Outgoing and Incoming connections separately across the WAN <-> LAN and can also limit settings across various LAN IPs.

If your router only supports outgoing QoS, it's a shitty router/switch.

I think it depends on if you set it using a port or mac. Also, your router can't really control the next router.

[smoothrunnings]

FYI, QOS only works on OUTGOING traffic only your LAN, doesn't work on traffic coming back into your network from your WAN port.

So shaping the outgoing traffic is only good if you are running a porn site on the same network as your P2Pool!

Not true... Depends on the features of your router.

Mine allows detailed QoS priority settings for Outgoing and Incoming connections separately across the WAN <-> LAN and can also limit settings across various LAN IPs.

If your router only supports outgoing QoS, it's a shitty router/switch.

I think it depends on if you set it using a port or mac. Also, your router can't really control the next router.

This true, you can't control the ISP's router which sending you the traffic which might explain why the only routers I have seen that provide inbound WAN are enterprise level ones that ISP's would use. I doubt any bitcoin miner would want to become an ISP just so they can have QOS WAN inbound working properly.

Enterprise = products from RiverBed and Cisco. 

[jedimstr]

FYI, QOS only works on OUTGOING traffic only your LAN, doesn't work on traffic coming back into your network from your WAN port.

So shaping the outgoing traffic is only good if you are running a porn site on the same network as your P2Pool!

Not true... Depends on the features of your router.

Mine allows detailed QoS priority settings for Outgoing and Incoming connections separately across the WAN <-> LAN and can also limit settings across various LAN IPs.

If your router only supports outgoing QoS, it's a shitty router/switch.

I think it depends on if you set it using a port or mac. Also, your router can't really control the next router.

This true, you can't control the ISP's router which sending you the traffic which might explain why the only routers I have seen that provide inbound WAN are enterprise level ones that ISP's would use. I doubt any bitcoin miner would want to become an ISP just so they can have QOS WAN inbound working properly.

Enterprise = products from RiverBed and Cisco.  

I have the somewhat crappy consumer Router that Verizon FioS customers get and like I said above, it supports Inbound and Outbound QoS settings tied to Port, IP, MAC, etc.   You can also get pretty granular with your priority tiers and how it manages them.


Note: this is not my setup...just using an example image from the 'net.  My settings are actually a bit more elaborate for my various development services, mining related stuff (bitciond, namecoind, p2pool, stratum proxy etc) and my media stuff.

And that's not even going into the settings for Traffic Shaping, DSCP, 802.1p, etc.

And this router is hardly Enterprise Class.

[smoothrunnings]

FYI, QOS only works on OUTGOING traffic only your LAN, doesn't work on traffic coming back into your network from your WAN port.

So shaping the outgoing traffic is only good if you are running a porn site on the same network as your P2Pool!

Not true... Depends on the features of your router.

Mine allows detailed QoS priority settings for Outgoing and Incoming connections separately across the WAN <-> LAN and can also limit settings across various LAN IPs.

If your router only supports outgoing QoS, it's a shitty router/switch.

I think it depends on if you set it using a port or mac. Also, your router can't really control the next router.

This true, you can't control the ISP's router which sending you the traffic which might explain why the only routers I have seen that provide inbound WAN are enterprise level ones that ISP's would use. I doubt any bitcoin miner would want to become an ISP just so they can have QOS WAN inbound working properly.

Enterprise = products from RiverBed and Cisco.  

I have the somewhat crappy consumer Router that Verizon FioS customers get and like I said above, it supports Inbound and Outbound QoS settings tied to Port, IP, MAC, etc.   You can also get pretty granular with your priority tiers and how it manages them.


Note: this is not my setup...just using an example image from the 'net.  My settings are actually a bit more elaborate for my various development services, mining related stuff (bitciond, namecoind, p2pool, stratum proxy etc) and my media stuff.

And that's not even going into the settings for Traffic Shaping, DSCP, 802.1p, etc.

And this router is hardly Enterprise Class.

In short; there is a lot of delicate information on this topic.

You can't directly QoS traffic coming inbound. When the traffic reaches your router, there's little you can do about it. What you do, is slow the rate of TCP replies, or start dropping packets to limit a certain type, say HTTP traffic, inbound. So, those settings he sees is the router trying to QoS traffic inbound indirectly.

It may work, it may not. Ultimately you're at the mercy of whoever is sending you traffic, because once traffic has arrived at your router to QoS, there's nothing that you can do at that point; it's already gone over your internet connection to reach your router, taking up your bandwidth. And even then, the indirect QoS can only work on TCP traffic. UDP traffic is connectionless, and no amount of dropped packets will slow it down. anything will send UDP traffic as fast as it can.

You see, when applying QoS to traffic, you put certain types of traffic (HTTP, HTTPS, etc.) into different priority queues (High, medium, and low in this case). The router only applies those queues when sending traffic outbound, because it can't do anything directly to traffic inbound.

So, as an example:

HTTP traffic is to be put in a low priority queue. Coming inbound, it would traverse your internet connection, and arrive at your router. Then, your router would apply the QoS policy to put it in a low priority queue, which would send it out to your LAN after higher priority traffic, say your bitcoin miner and vice versa when going outbound. Your router can try to drop packets to stem the flow of traffic, hoping that TCP's algorithms take hold and slow down traffic once the other end realizes that traffic is being dropped. But then you end up with dropped packets, etc. in short, your router cannot QoS traffic directly that has not arrived at it yet.


   

   

[smoothrunnings]

Does anyone use cable internet 35/4Meg, or anything close to it? I just wonder what your maxconnections is set to?

Thanks,

[jedimstr]

Hi. Would like to ask about latency
Why going below 0.2s will hurt your income and everyone else's on P2Pool. ?
What is the reason of that?

It doesn't.

It does because lowering the getblocktemplate latency is a tradeoff.
As explained in the guide with current bitcoind version reducing this latency is done by reducing the number of transactions you include in the template. Doing so you reduce the fees included in the blocks you find : you reduce your own income and everyone else's when this happens.

Today this latency has only a negative effect when a new block is found by the whole network (every ~10 minutes) unless you have a very weak CPU (where CPU usage by bitcoind can slow down P2Pool).
This is the same effect for P2Pool and every other pool : until a getblocktemplate returns a result after a new block, the pool can only work on an empty template (no transaction). Going below 0.2s only tries to reduce this 0.2/600 = 0.03% negative impact on the fees income (the block reward isn't impacted) : including more transactions (which amounts to ~1% of the average block value) simply brings more income to everyone including yourself.

Continuing the discussion about the getBlockTemplate latency...

I see quite a few public nodes have getBlockTemplate latencies approaching that magic 0.2 mark... but I've always struggled.

My p2pool node used to be in the 1.5 to 2.0 range until about a month ago when I tweaked it further per your guide and other suggestions on the net.  That brought it down to the 0.5 to 0.7 range while trying to retain a high blockmaxsize for greater income.
Lately (or it seems right when the whole Bitcoin DDOS started happening in the last week), my latencies have bumped back up to the 1.0 range with occasional spikes much higher.  So let's discount that bump up for now.

My real question is the efficacy of the dbcache and datadir settings.  I've upped my dbcache from the default 25 to 1000.  I have quite a bit of free memory to use, but not quite enough to host the entire Blockchain on a ramdrive, so datadir is probably out.  Will I see any gains on getBlockTemplate Latency from upping dbcache further to lets say 2000, 3000, or even 5000 megabytes?

The Blockchain (as well as the OS and Apps) are all on an SSD already, running OSX Mavericks and using the Bitcoin-QT OMG10 0.8.5 client (waiting for the official 0.9 client to be out before I upgrade since OMG10 already has most of what went into 0.8.6 and I can't find a binary download for the Mac version of the 0.9 preview release) with wallet disabled.

Connection is over Verizon FiOS 75/35 and the Mac Pro is connected to my managed switch with dual gigabit ethernet with Link Aggregation.

Here's my bitcoin.conf (with certain parameters redacted of course):

Code:

rpcuser=XXXXREDACTEDXXXX
rpcpassword=XXXXREDACTEDXXXX
server=1
rpcport=8332
disablewallet=1
dbcache=1000
maxconnections=26
blockmaxsize=1000000
mintxfee=0.00001
minrelaytxfee=0.00001
addnode=67.186.224.85
addnode=88.198.58.172

[smoothrunnings]

Hi. Would like to ask about latency
Why going below 0.2s will hurt your income and everyone else's on P2Pool. ?
What is the reason of that?

It doesn't.

It does because lowering the getblocktemplate latency is a tradeoff.
As explained in the guide with current bitcoind version reducing this latency is done by reducing the number of transactions you include in the template. Doing so you reduce the fees included in the blocks you find : you reduce your own income and everyone else's when this happens.

Today this latency has only a negative effect when a new block is found by the whole network (every ~10 minutes) unless you have a very weak CPU (where CPU usage by bitcoind can slow down P2Pool).
This is the same effect for P2Pool and every other pool : until a getblocktemplate returns a result after a new block, the pool can only work on an empty template (no transaction). Going below 0.2s only tries to reduce this 0.2/600 = 0.03% negative impact on the fees income (the block reward isn't impacted) : including more transactions (which amounts to ~1% of the average block value) simply brings more income to everyone including yourself.

Continuing the discussion about the getBlockTemplate latency...

I see quite a few public nodes have getBlockTemplate latencies approaching that magic 0.2 mark... but I've always struggled.

My p2pool node used to be in the 1.5 to 2.0 range until about a month ago when I tweaked it further per your guide and other suggestions on the net.  That brought it down to the 0.5 to 0.7 range while trying to retain a high blockmaxsize for greater income.
Lately (or it seems right when the whole Bitcoin DDOS started happening in the last week), my latencies have bumped back up to the 1.0 range with occasional spikes much higher.  So let's discount that bump up for now.

My real question is the efficacy of the dbcache and datadir settings.  I've upped my dbcache from the default 25 to 1000.  I have quite a bit of free memory to use, but not quite enough to host the entire Blockchain on a ramdrive, so datadir is probably out.  Will I see any gains on getBlockTemplate Latency from upping dbcache further to lets say 2000, 3000, or even 5000 megabytes?

The Blockchain (as well as the OS and Apps) are all on an SSD already, running OSX Mavericks and using the Bitcoin-QT OMG10 0.8.5 client (waiting for the official 0.9 client to be out before I upgrade since OMG10 already has most of what went into 0.8.6 and I can't find a binary download for the Mac version of the 0.9 preview release) with wallet disabled.

Connection is over Verizon FiOS 75/35 and the Mac Pro is connected to my managed switch with dual gigabit ethernet with Link Aggregation.

Here's my bitcoin.conf (with certain parameters redacted of course):

Code:

rpcuser=XXXXREDACTEDXXXX
rpcpassword=XXXXREDACTEDXXXX
server=1
rpcport=8332
disablewallet=1
dbcache=1000
maxconnections=26
blockmaxsize=1000000
mintxfee=0.00001
minrelaytxfee=0.00001
addnode=67.186.224.85
addnode=88.198.58.172

What do you expect to get out of a dual Gbit connection when your internet is only 75/35Mbit/s? Your internet isn't anywhere near 1GbE so there no gain in what have have done.

Download the source for Bitcoin-QT and compile it on your mac.

[jedimstr]

What do you expect to get out of a dual Gbit connection when your internet is only 75/35Mbit/s? Your internet isn't anywhere near 1GbE so there no gain in what have have done.

The dual Link Aggregated Connection has nothing to do with my WAN bandwidth. It was to solve the following performance issues I was having:

1. Connection Starvation: My MacPro serves up multiple services on my LAN with p2pool, Bitcoin node, Namecoin Node, Stratum Proxy for Scrypt Mining, individual miners connecting to it, Apache reverse proxy and gateway to outside access of my network, Media serving (large HD video and FLAC music), etc. Even maxing out custom TCP/IP settings for connections didn't fully solve the contention and queuing I was seeing. LAG solved all of it.

2. Round Robin / Load Balancing across ethernet connections: I'm now able to support the above service connections AND transcode video to my SAN box with no/little constraints.  Previously whenever I transcoded video, it ground everything else to a halt, which put a damper on my p2pool mining node.  And I do transcode video often. No more issues.

3. Internal LAN QoS is much easier with more connections available. I can manage my LAN latency-defeating rules for certain traffic in a more flexible way now that I have more paths available to my main Mac Pro server. I can set priorities for various connections across my LAN and not have to worry about the traffic jam that I used to get to my Mac's IP.

Link Aggregation is almost never about pure bandwidth.  It's about freeing up queues and load balancing socket contention so you can support more parallel services on a single server, especially ones that are latency adverse.

I'd still like to see someone else answer my original questions above regarding dbcache setting.  

[smoothrunnings]

What do you expect to get out of a dual Gbit connection when your internet is only 75/35Mbit/s? Your internet isn't anywhere near 1GbE so there no gain in what have have done.

The dual Link Aggregated Connection has nothing to do with my WAN bandwidth. It was to solve the following performance issues I was having:

1. Connection Starvation: My MacPro serves up multiple services on my LAN with p2pool, Bitcoin node, Namecoin Node, Stratum Proxy for Scrypt Mining, individual miners connecting to it, Apache reverse proxy and gateway to outside access of my network, Media serving (large HD video and FLAC music), etc. Even maxing out custom TCP/IP settings for connections didn't fully solve the contention and queuing I was seeing. LAG solved all of it.

2. Round Robin / Load Balancing across ethernet connections: I'm now able to support the above service connections AND transcode video to my SAN box with no/little constraints.  Previously whenever I transcoded video, it ground everything else to a halt, which put a damper on my p2pool mining node.  And I do transcode video often. No more issues.

3. Internal LAN QoS is much easier with more connections available. I can manage my LAN latency-defeating rules for certain traffic in a more flexible way now that I have more paths available to my main Mac Pro server. I can set priorities for various connections across my LAN and not have to worry about the traffic jam that I used to get to my Mac's IP.

Link Aggregation is almost never about pure bandwidth.  It's about freeing up queues and load balancing socket contention so you can support more parallel services on a single server, especially ones that are latency adverse.

I'd still like to see someone else answer my original questions above regarding dbcache setting.  

Thanks for the clarification, and good luck with that, but teaming as it's called shouldn't be required for you are doing if you have the right setup.

[gyverlb]

I'd still like to see someone else answer my original questions above regarding dbcache setting.  

I don't think the dbcache setting is interesting. Even when bitcoind/qt was purely BerkeleyDB I didn't see any performance gains with large cache values. Now bitcoind/qt rely on LevelDB for a large part of it's data so if dbcache is only related to the BerkeleyDB database it is probably even less effective.

0.2s for getblocktemplate isn't bad at all especially with the changes of last summer which made p2pool even less dependent on getblocktemplate latency.

If your efficiency is ~100%, I wouldn't change anything. If it's below I'd advise raising the mintxfee and minrelaytxfee every 24h (maybe double it on each change) until you either reach the default value of 0.0001 or reach the 100% efficiency level.

[jedimstr]

I'd still like to see someone else answer my original questions above regarding dbcache setting. 

I don't think the dbcache setting is interesting. Even when bitcoind/qt was purely BerkeleyDB I didn't see any performance gains with large cache values. Now bitcoind/qt rely on LevelDB for a large part of it's data so if dbcache is only related to the BerkeleyDB database it is probably even less effective.

0.2s for getblocktemplate isn't bad at all especially with the changes of last summer which made p2pool even less dependent on getblocktemplate latency.

If your efficiency is ~100%, I wouldn't change anything. If it's below I'd advise raising the mintxfee and minrelaytxfee every 24h (maybe double it on each change) until you either reach the default value of 0.0001 or reach the 100% efficiency level.

That's the thing.  I'd love a getBlockTemplate of 0.2s.  Unfortunately my node lately is above 1.0s. That's what I need help with (if it does help any).

[jedimstr]

What do you expect to get out of a dual Gbit connection when your internet is only 75/35Mbit/s? Your internet isn't anywhere near 1GbE so there no gain in what have have done.

The dual Link Aggregated Connection has nothing to do with my WAN bandwidth. It was to solve the following performance issues I was having:

1. Connection Starvation: My MacPro serves up multiple services on my LAN with p2pool, Bitcoin node, Namecoin Node, Stratum Proxy for Scrypt Mining, individual miners connecting to it, Apache reverse proxy and gateway to outside access of my network, Media serving (large HD video and FLAC music), etc. Even maxing out custom TCP/IP settings for connections didn't fully solve the contention and queuing I was seeing. LAG solved all of it.

2. Round Robin / Load Balancing across ethernet connections: I'm now able to support the above service connections AND transcode video to my SAN box with no/little constraints.  Previously whenever I transcoded video, it ground everything else to a halt, which put a damper on my p2pool mining node.  And I do transcode video often. No more issues.

3. Internal LAN QoS is much easier with more connections available. I can manage my LAN latency-defeating rules for certain traffic in a more flexible way now that I have more paths available to my main Mac Pro server. I can set priorities for various connections across my LAN and not have to worry about the traffic jam that I used to get to my Mac's IP.

Link Aggregation is almost never about pure bandwidth.  It's about freeing up queues and load balancing socket contention so you can support more parallel services on a single server, especially ones that are latency adverse.

I'd still like to see someone else answer my original questions above regarding dbcache setting.  

Thanks for the clarification, and good luck with that, but teaming as it's called shouldn't be required for you are doing if you have the right setup.

The "Right Setup" is exactly what this is.  Especially when dealing with multi stream uncompressed video to and from my SAN for edits. (#2 above)   .

Nevermind. Obviously you didn't read anything I wrote.  

[gyverlb]

That's the thing.  I'd love a getBlockTemplate of 0.2s.  Unfortunately my node lately is above 1.0s. That's what I need help with (if it does help any).

If you don't have low efficiency then getBlockTemplate being above 1.0s isn't a problem in itself.

The advice I gave above should lower your getBlockTemplate latency. The minimum fees are used to select which transactions are kept in your bitcoind's memory and which ones are included in the block template given to p2pool. If you raise these fees just a bit your node won't have to do as much work and your latency will lower. If you raise them to 0.0001 you can expect <0.2s according to the recent amount of txs.

Note that if you target a latency you'll have to change these values when more/less transactions are waiting to be included in a block (which is not doable as these changes happen unpredictably). This is why I advise to leave them alone if the efficiency is good: the target should be to get good income and good behavior on the network not reaching arbitrary latency targets.

[jedimstr]

That's the thing.  I'd love a getBlockTemplate of 0.2s.  Unfortunately my node lately is above 1.0s. That's what I need help with (if it does help any).

If you don't have low efficiency then getBlockTemplate being above 1.0s isn't a problem in itself.

The advice I gave above should lower your getBlockTemplate latency. The minimum fees are used to select which transactions are kept in your bitcoind's memory and which ones are included in the block template given to p2pool. If you raise these fees just a bit your node won't have to do as much work and your latency will lower. If you raise them to 0.0001 you can expect <0.2s according to the recent amount of txs.

Note that if you target a latency you'll have to change these values when more/less transactions are waiting to be included in a block (which is not doable as these changes happen unpredictably). This is why I advise to leave them alone if the efficiency is good: the target should be to get good income and good behavior on the network not reaching arbitrary latency targets.

Thanks. Efficiency has been bouncing around 100 but is 94 right now. Will try mintxfee and minrelaytxfee at 0.00006 and tweak from there.

[matthewh3]

Would this server cope well for a merged-mining P2Pool node - http://www.supermicro.com/products/system/1U/5018/SYS-5018A-FTN4.cfm - It's only Atom CPU based but it has eight cores.  So a core each for each of the five wallets, a core for P2Pool itself, a core for the OS and one spare core left over.

[bitpop]

Would this server cope well for a merged-mining P2Pool node - http://www.supermicro.com/products/system/1U/5018/SYS-5018A-FTN4.cfm - It's only Atom CPU based but it has eight cores.  So a core each for each of the five wallets, a core for P2Pool itself, a core for the OS and one spare core left over.

That's a nice cpu
Not the old atom

[smoothrunnings]

Would this server cope well for a merged-mining P2Pool node - http://www.supermicro.com/products/system/1U/5018/SYS-5018A-FTN4.cfm - It's only Atom CPU based but it has eight cores.  So a core each for each of the five wallets, a core for P2Pool itself, a core for the OS and one spare core left over.

Sorry how do you plan to assign which CPU gets what core?

[bitpop]

Would this server cope well for a merged-mining P2Pool node - http://www.supermicro.com/products/system/1U/5018/SYS-5018A-FTN4.cfm - It's only Atom CPU based but it has eight cores.  So a core each for each of the five wallets, a core for P2Pool itself, a core for the OS and one spare core left over.

Sorry how do you plan to assign which CPU gets what core?

I know in Windows you can but he probably meant hypothetically
Try it, cpu affinity

[smoothrunnings]

Would this server cope well for a merged-mining P2Pool node - http://www.supermicro.com/products/system/1U/5018/SYS-5018A-FTN4.cfm - It's only Atom CPU based but it has eight cores.  So a core each for each of the five wallets, a core for P2Pool itself, a core for the OS and one spare core left over.

Sorry how do you plan to assign which CPU gets what core?

I know in Windows you can but he probably meant hypothetically
Try it, cpu affinity

He probably would be better off installing ESXi like I have on my IBM System x3400 M3.

[matthewh3]

Actually with hindsight the "Avoton" maybe a better choice than the "Rangeley" - http://www.ebay.com/itm/Supermicro-SuperServer-SYS-5018A-TN4-Intel-Atom-C2750-200W-1U-Rackmount-Server-/321240339066

[CartmanSPC]

If you don't have this problem, you should raise the blockmaxsize value instead to get more income:

Code:

blockmaxsize=1000000 #default is 500000

This is the maximum value allowed by the Bitcoin protocol. There are lots of unconfirmed transactions with low fees just waiting for P2Pool users to mine them and get the benefits. You should only use lower values if all other means of saving bandwidth don't work without lowering your efficiency (lowering the number of connections from both bitcoind and P2Pool as shown above). Lowering this setting not only lowers your income, it lowers every other P2Pool user's income too.

Was looking into using blockmaxsize=1000000 and started digging into the source code for bitcoin to confirm it's benefits.

Found that in 0.9.0rc1 it is increasing the default -blockmaxsize to 750K and that it is the MAXIMUM size for mined blocks.

/** Default for -blockmaxsize, maximum size for mined blocks **/
static const unsigned int DEFAULT_BLOCK_MAX_SIZE = 750000;

The old version was:
-/** The maximum size for mined blocks */
-static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;   (500K)

Unless I'm missing something does this show that setting blockmaxsize=1000000 has no effect on mined blocks?

Source:
https://github.com/bitcoin/bitcoin/commit/ad898b40aaf06c1cc7ac12e953805720fc9217c0

[gyverlb]

Was looking into using blockmaxsize=1000000 and started digging into the source code for bitcoin to confirm it's benefits.

Found that in 0.9.0rc1 it is increasing the default -blockmaxsize to 750K and that it is the MAXIMUM size for mined blocks.

It's the *default* maximum, they can't change the protocol maximum without invalidating some previous blocks which would break the current blockchain.

[CartmanSPC]

Was looking into using blockmaxsize=1000000 and started digging into the source code for bitcoin to confirm it's benefits.

Found that in 0.9.0rc1 it is increasing the default -blockmaxsize to 750K and that it is the MAXIMUM size for mined blocks.

It's the *default* maximum, they can't change the protocol maximum without invalidating some previous blocks which would break the current blockchain.

Ok, thanks. It was late and I read the comment differently. It is slightly ambiguous especially right before bed 

[fruor]

someone mentioned here https://bitcointalk.org/index.php?topic=18313.msg5030281#msg5030281
that a possible solution to run p2pool with a low hashpower would be to mine to ADDR/0.0001

my question is: how do i add this running my own p2pool node using run_p2pool ?

[roy7]

someone mentioned here https://bitcointalk.org/index.php?topic=18313.msg5030281#msg5030281
that a possible solution to run p2pool with a low hashpower would be to mine to ADDR/0.0001

my question is: how do i add this running my own p2pool node using run_p2pool ?

My patch has no effect on running your own node. It's purpose is to let each miner on a public node get the share difficulty target they would get as if they were running their own node.

To control your miner's difficulty target put /DIFF after your username you are using to connect to your node with. If you use a tiny one it'll make sure you always find the smaller shares possible (whatever the pool's minimum share difficulty is for that time).

[CartmanSPC]

• raise mintxfee and minrelaytxfee back to defaults (0.0001)

Anyone know where (in the coin source) the default mins can be found? Searched but could not find it. Trying to see what would be good values for some altcoins.

[cr1776]

• raise mintxfee and minrelaytxfee back to defaults (0.0001)

Anyone know where (in the coin source) the default mins can be found? Searched but could not find it. Trying to see what would be good values for some altcoins.

Probably in  ~/.bitcoin/bitcoin.conf

e.g.

mintxfee=0.0001
minrelaytxfee=0.0001
blockprioritysize=8000
blockminsize=10000

Then your bitcoind will use those to construct the block.

In most alts it is in the same spot, with a different name.

Assuming I understood what you were asking.   :-)

[fruor]

someone mentioned here https://bitcointalk.org/index.php?topic=18313.msg5030281#msg5030281
that a possible solution to run p2pool with a low hashpower would be to mine to ADDR/0.0001

my question is: how do i add this running my own p2pool node using run_p2pool ?

My patch has no effect on running your own node. It's purpose is to let each miner on a public node get the share difficulty target they would get as if they were running their own node.

But if small mining rigs run their own node, it still seems impossible to get rewarded (my p2pool environment shows enough hashrate to at least find a block several times a day). If I understand it correctly you are forcing the node (not the pool) to give you a small share difficulty, but if you run your own node it will be using standard difficulties anyway?

roy7 you have my deepest respect for your efforts to make p2pool useable for small miners. However I still cannot follow how this can be achieved, I'm talking cpu-mining for scrypt coins. My current try is to setup a node on each cpu-machine and connect to their localhost using your hack /0.0001. Is this overkill?

BTW: I'm not aiming for botnets, they may be better off with centralized pools anyway, but for a build-in mining functionality in a coin wallet.

[roy7]

But if small mining rigs run their own node, it still seems impossible to get rewarded (my p2pool environment shows enough hashrate to at least find a block several times a day). If I understand it correctly you are forcing the node (not the pool) to give you a small share difficulty, but if you run your own node it will be using standard difficulties anyway?

roy7 you have my deepest respect for your efforts to make p2pool useable for small miners. However I still cannot follow how this can be achieved, I'm talking cpu-mining for scrypt coins. My current try is to setup a node on each cpu-machine and connect to their localhost using your hack /0.0001. Is this overkill?

The issue is that bigger miners are given higher share targets so they don't use up too much of the share chain themselves. p2pool is designed around the idea that each miner is running their own node. So a node = a miner. Thus, a node scales the difficulty for the workers connected to that node (all of your mining gear) to a higher level if you have a high combined speed.

This causes an issue for a public node with lots of small miners that the target share difficulty is being set to the combined total speed, not each miner's speed. So 100 people at 5GH will each be given a target share difficulty for a 500 GH miner. The same difficulty a 500 GH miner would have on his own private node. If these miners ran their own private node with just 5GH of speed, they'd have lower targets. So that is what my patch did, lower the target share difficulty for an address based only on the addresses' speed, not the node's total combined speed. This is also why the patch does nothing for a miner running his own private node, you already have a target based on your personal speed.

My patch changes the vardiff algorithm as above. If you set a target yourself with /DIFF, then the vardiff isn't used and my patch does nothing. /DIFF also overrides the dust prevention so you'll get the smallest shares you can no matter how little they pay. This can result in tx fees that cost more to spend the shares than they are worth. I don't think people should do that if they are mining long-term, but it's the easiest way to try and make "Why am I not getting paid" complaints go away.

No matter what vardiff does or what /DIFF you set, you will never get a share difficulty target below the minimum share difficulty for the network.

[fruor]

No matter what vardiff does or what /DIFF you set, you will never get a share difficulty target below the minimum share difficulty for the network.

so in the end there is no hope for small cpu miners using p2pool?
if your hack is not enough for them to get accepted shares, would a fork like the vertcoin one be?

http://www.reddit.com/r/vertcoin/comments/1xlp8i/attn_all_p2pool_operators_p2pool_update/

[roy7]

No matter what vardiff does or what /DIFF you set, you will never get a share difficulty target below the minimum share difficulty for the network.

so in the end there is no hope for small cpu miners using p2pool?
if your hack is not enough for them to get accepted shares, would a fork like the vertcoin one be?

http://www.reddit.com/r/vertcoin/comments/1xlp8i/attn_all_p2pool_operators_p2pool_update/

You could change networks.py to try and have a lower share difficulty but it'll go back up once more hash power joins the network. The way p2pool is designed, there is always going to be some level of hash power that is so small the variance is too high for people to stomach. For them it's probably better to use a proxypool like doge.st is designing.

[cr1776]

No matter what vardiff does or what /DIFF you set, you will never get a share difficulty target below the minimum share difficulty for the network.

so in the end there is no hope for small cpu miners using p2pool?
if your hack is not enough for them to get accepted shares, would a fork like the vertcoin one be?

http://www.reddit.com/r/vertcoin/comments/1xlp8i/attn_all_p2pool_operators_p2pool_update/

You could change networks.py to try and have a lower share difficulty but it'll go back up once more hash power joins the network. The way p2pool is designed, there is always going to be some level of hash power that is so small the variance is too high for people to stomach. For them it's probably better to use a proxypool like doge.st is designing.

vertcoind is running fine, and I was going to try running p2pool on VTC to try out your mod, but am getting an error:

exceptions.ImportError: No module named vtc_scrypt

Any suggestions one what dependencies on Ubuntu 13 are needed for p2pool?  I am using the donSchoe / p2pool-vtc fork from github.

:-)

[roy7]

vertcoind is running fine, and I was going to try running p2pool on VTC to try out your mod, but am getting an error:

exceptions.ImportError: No module named vtc_scrypt

Any suggestions one what dependencies on Ubuntu 13 are needed for p2pool?  I am using the donSchoe / p2pool-vtc fork from github.

:-)

Check the README file for instructions on installing the vertcoin_scrypt module.

[cr1776]

vertcoind is running fine, and I was going to try running p2pool on VTC to try out your mod, but am getting an error:

exceptions.ImportError: No module named vtc_scrypt

Any suggestions one what dependencies on Ubuntu 13 are needed for p2pool?  I am using the donSchoe / p2pool-vtc fork from github.

:-)

Check the README file for instructions on installing the vertcoin_scrypt module.

The subtly hidden readme.  ;-)  Usually they just say "see docs".  lol.

edit:  that did it.  Thanks for the pointer.  I'll check out your mod for it next.  ;-)

[roy7]

The subtly hidden readme.  ;-)  Usually they just say "see docs".  lol.

edit:  that did it.  Thanks for the pointer.  I'll check out your mod for it next.  ;-)

The p2pool-vtc repo already has my patch applied.

[CartmanSPC]

• raise mintxfee and minrelaytxfee back to defaults (0.0001)

Anyone know where (in the coin source) the default mins can be found? Searched but could not find it. Trying to see what would be good values for some altcoins.

Probably in  ~/.bitcoin/bitcoin.conf

Assuming I understood what you were asking.   :-)

where in the coin source (ex: https://github.com/bitcoin/bitcoin/tree/master/src). Different coins prob. have different default minimums.

[cr1776]

• raise mintxfee and minrelaytxfee back to defaults (0.0001)

Anyone know where (in the coin source) the default mins can be found? Searched but could not find it. Trying to see what would be good values for some altcoins.

Probably in  ~/.bitcoin/bitcoin.conf

Assuming I understood what you were asking.   :-)

where in the coin source (ex: https://github.com/bitcoin/bitcoin/tree/master/src). Different coins prob. have different default minimums.

I think this is what you are looking for around line 53-55:

main.cpp:
/** Fees smaller than this (in satoshi) are considered zero fee (for transaction creation) */
int64_t CTransaction::nMinTxFee = 10000;  // Override with -mintxfee
/** Fees smaller than this (in satoshi) are considered zero fee (for relaying) */
int64_t CTransaction::nMinRelayTxFee = 1000;



:-)

[CartmanSPC]

• raise mintxfee and minrelaytxfee back to defaults (0.0001)

Anyone know where (in the coin source) the default mins can be found? Searched but could not find it. Trying to see what would be good values for some altcoins.

Probably in  ~/.bitcoin/bitcoin.conf

Assuming I understood what you were asking.   :-)

where in the coin source (ex: https://github.com/bitcoin/bitcoin/tree/master/src). Different coins prob. have different default minimums.

I think this is what you are looking for around line 53-55:

main.cpp:
/** Fees smaller than this (in satoshi) are considered zero fee (for transaction creation) */
int64_t CTransaction::nMinTxFee = 10000;  // Override with -mintxfee
/** Fees smaller than this (in satoshi) are considered zero fee (for relaying) */
int64_t CTransaction::nMinRelayTxFee = 1000;

Thanks! That's it...actually now seeing it I remember where it was...man im loosing it lately...too much stuff going on..lack of sleep
At least now it's documented

[smooth]

I have blockprioritysize=0 and mintxfee=0.01 yet I'm still getting transactions with smaller fees. Does anyone know why before I start digging into the source code?

2014-02-28 14:48:26.238012 New work for worker! Difficulty: 156.935343 Share difficulty: 504240.247210 Total block value: 25.016500 BTC including 2 transactions

EDIT: Just a guess but maybe "per KB" is actually applied "per 1/2 KB"?

[cr1776]

The subtly hidden readme.  ;-)  Usually they just say "see docs".  lol.

edit:  that did it.  Thanks for the pointer.  I'll check out your mod for it next.  ;-)

The p2pool-vtc repo already has my patch applied.

Good to know.  It seems to be working perfectly.  I might have to try it on the btc side.
Thanks.

[gyverlb]

I have blockprioritysize=0 and mintxfee=0.01 yet I'm still getting transactions with smaller fees. Does anyone know why before I start digging into the source code?

2014-02-28 14:48:26.238012 New work for worker! Difficulty: 156.935343 Share difficulty: 504240.247210 Total block value: 25.016500 BTC including 2 transactions

EDIT: Just a guess but maybe "per KB" is actually applied "per 1/2 KB"?

Transactions can take less than a KB...

Why would you want to use such values (especially mintxfee=0.01)? And ask for directions in the thread where it's explained why you are not advised to (you are hurting your income and everyone else's)?

[smoothrunnings]

I have blockprioritysize=0 and mintxfee=0.01 yet I'm still getting transactions with smaller fees. Does anyone know why before I start digging into the source code?

2014-02-28 14:48:26.238012 New work for worker! Difficulty: 156.935343 Share difficulty: 504240.247210 Total block value: 25.016500 BTC including 2 transactions

EDIT: Just a guess but maybe "per KB" is actually applied "per 1/2 KB"?

Transactions can take less than a KB...

Why would you want to use such values (especially mintxfee=0.01)? And ask for directions in the thread where it's explained why you are not advised to (you are hurting your income and everyone else's)?

So even if mintxfee=0.00001? I am not sure why smooth put 0.01 when it doesn't clearly say that in the OP's post.

I am too not sure if the OP's post really helps everyone or only help people like him who don't use the settings possibly to gain more coins?

[smooth]

Transactions can take less than a KB...

I think I misinterpreted this statement about rounding up from https://en.bitcoin.it/wiki/Transaction_fees as applying to mintxfee. It probably doesn't (but I will look at the code soon).

"the reference implementation will round up the transaction size to the next thousand bytes and add a fee of 0.1 mBTC (0.0001 BTC) per thousand bytes"

Why would you want to use such values (especially mintxfee=0.01)? And ask for directions in the thread where it's explained why you are not advised to (you are hurting your income and everyone else's)?

I chose those values for testing purposes to simplify the collection of transactions (generally down to one or two) since I was seeing similarly confusing behavior with more reasonable settings.

[sshapiroNJ]

Now I got pros and cons of using P2Pool mining ! Thanks a lot for this guide-book! 

[smoothrunnings]

Just out of curiosity does anyone use the settings the OP posts about in this thread?

I he or she makes some recommendations that I would like know if people are using or if there is some other sweet spot such as maxconnections= in bitcoin.conf?

Thanks,

[smooth]

Just out of curiosity does anyone use the settings the OP posts about in this thread?

I he or she makes some recommendations that I would like know if people are using or if there is some other sweet spot such as maxconnections= in bitcoin.conf?

Unless you have a very fast internet connection (both up and down) without any hard or soft caps I recommend you just block incoming bitcoind connections at your firewall (i.e. don't forward port 8333) and rely on outgoing connections (the default 8 is fine -- no need to increase this). That will avoid a lot of your bandwidth being used up by people wanting to download the blockchain.

That alone should substantially increase the number of people who are able to successfully run a p2pool node.

[Tegija]

Just out of curiosity does anyone use the settings the OP posts about in this thread?

I he or she makes some recommendations that I would like know if people are using or if there is some other sweet spot such as maxconnections= in bitcoin.conf?

Thanks,

those settings are just basics. to find right settings for your node you just have to test a lot. i needed 3weeks to find optimal settings for my node and i am still not really ready. small changes i still have to make.

there are just to many factors which can influence efficiency of your node, so everybody has to test it out.

with mxconnections i was playing around pretty long too, but i did not really see big advantages by changing it as it is described here. many other things the same.

[uteroulin]

Thanks a lot for this guide thread! It has been written so clear and even such newbie as I am could understand it 

[gyverlb]

Thanks a lot for this guide thread! It has been written so clear and even such newbie as I am could understand it 

Glad to read it was understandable for new users, that was one of my main goals.

[silverfern]

Hi guys,

A new miner here. I am currently mining on a p2pool. I have two gaming computers mining to one address. When I check the p2pool hashrate adding the second computer doesn't do anything to my hashrate.

Am I doing something wrong? Are other people finding this as well?

Thank you in advance!

Edit: Second computer is at a different house, if that matters

[gyverlb]

Hi guys,

A new miner here. I am currently mining on a p2pool. I have two gaming computers mining to one address. When I check the p2pool hashrate adding the second computer doesn't do anything to my hashrate.

Am I doing something wrong? Are other people finding this as well?

Thank you in advance!

Edit: Second computer is at a different house, if that matters

That's more a question for the main P2Pool thread (and yes something is wrong):
https://bitcointalk.org/index.php?topic=18313.0

[silverfern]

Thank you,

I will post it there!

[BTCNU]

Regarding http://bitcoin.advmapper.com:9332/static/

1: How can I tell if people are using my P2Pool node?
2: If I don't mine, is there any reason to host a P2Pool node?
3: My GetBlockTemplate latency is never under 1 sec, even with just P2Pool and Bitcoind running. Why?
4: How do people find a P2Pool node to use, and what kinds of things helps them make the decision about which is best for them?

[gyverlb]

Regarding http://bitcoin.advmapper.com:9332/static/

1: How can I tell if people are using my P2Pool node?
2: If I don't mine, is there any reason to host a P2Pool node?
3: My GetBlockTemplate latency is never under 1 sec, even with just P2Pool and Bitcoind running. Why?
4: How do people find a P2Pool node to use, and what kinds of things helps them make the decision about which is best for them?

Most of these questions aren't related to this subject, please ask them on the main P2Pool thread:
https://bitcointalk.org/index.php?topic=18313.0

For you GetBlockTemplate latency question, please read the original post in this thread. What matters is the efficiency when miners are using your node. You don't have any miner yet on your node so efficiency will be unknown (and later unreliable) unless you mine a good amount of share (100 for a ~1% precision on the efficiency reported).

As you state on your p2pool server that your hardware only costs you $15/month, my first guess is that it is probably lacks power (not enough CPU/RAM/IO capacity/...) to reach the 0.2-0.3s you can easily get on a recent 3+GHz multi-core CPU with default settings for p2pool and bitcoind.

[smooth]

3: My GetBlockTemplate latency is never under 1 sec, even with just P2Pool and Bitcoind running. Why?

It takes that long to process the mempool to construct a block on the hardware you are using.

This may or may not be a problem, you have to see what your efficiency works out to be. If it is a problem you need to get faster hardware (I/O and/or CPU) or reduce your block size.

[BTCNU]

As you state on your p2pool server that your hardware only costs you $15/month, my first guess is that it is probably lacks power (not enough CPU/RAM/IO capacity/...) to reach the 0.2-0.3s you can easily get on a recent 3+GHz multi-core CPU with default settings for p2pool and bitcoind.

I have access to lots of CPU for brief computationally intensive tasks (4 cores, 3+ gHz), but I have maximums on system load. The server has a system load of 0.05. P2Pool never seems to get above 10% CPU. Disk is generally idle, and disks are SSDs, nothing appears to be swapping.

I will take my other off-topic questions to the main thread. Thanks.

[blade87]

Hey everyone I need some help. Is there any way I can easily obtain peer local hash rates over the past 24 hours in simple text format? All I am looking for in a text file is line by line "user, hash rate, dead hash rate" so I can setup a script export it as a csv regularly. Thanks.

The web-static graphs display this information but just aren't in that format I need being an entire webpage mainly in javascript.

[gyverlb]

Hey everyone I need some help. Is there any way I can easily obtain peer local hash rates over the past 24 hours in simple text format? All I am looking for in a text file is line by line "user, hash rate, dead hash rate" so I can setup a script export it as a csv regularly. Thanks.

The web-static graphs display this information but just aren't in that format I need being an entire webpage mainly in javascript.

I keep repeating myself...

https://bitcointalk.org/index.php?topic=18313.0

[GhostPlayer]

Quick questions, sorry if it has been addressesed.

1) does it matter what % of p2pool has rate in comparison to total hashrate affects earning in the long run, after ramp-up?

2) Can you point multiple miners from multiple IP's or same LAN, to the same p2pool using the same payout address?

[smooth]

Quick questions, sorry if it has been addressesed.

1) does it matter what % of p2pool has rate in comparison to total hashrate affects earning in the long run, after ramp-up?

It matters because you only get paid out when someone in p2pool finds a block. This doesn't not affect your expected (average) earnings but it does affect the frequency of your payouts and the variance of your earnings.

Happily, p2pool hash rate has increased a lot recently.

2) Can you point multiple miners from multiple IP's or same LAN, to the same p2pool using the same payout address?

Yss!

[Doom4535]

Does anyone know where you can find the default (and possibly max) block size for a coin in the wallet code?

[jonnybravo0311]

Does anyone know where you can find the default (and possibly max) block size for a coin in the wallet code?

While this has nothing to do with p2pool mining...

Look at the main.h for your coin:

static const unsigned int DEFAULT_BLOCK_MAX_SIZE

This can be overridden by passing -blockmaxsize to your *coind on startup, or by putting a value in *coin.conf files.

[Doom4535]

Does anyone know where you can find the default (and possibly max) block size for a coin in the wallet code?

While this has nothing to do with p2pool mining...

Look at the main.h for your coin:

static const unsigned int DEFAULT_BLOCK_MAX_SIZE

This can be overridden by passing -blockmaxsize to your *coind on startup, or by putting a value in *coin.conf files.

Thanks (I was thinking the question was relevant since the OP suggested tweaking the max blocksize to increase the amount of potential fees or to limit bandwidth).

[ScottWilson]

Has the advice at the beginning of this thread been updated to take into account current difficulty and network hashing power, and newer hardware?

Also, what is best practice for tacking "/2000+512" or whatever onto the end of your BTC address to set a higher share quality and manual difficulty?

I'm finding myself on a good network connection with low latency on good hardware and I suddenly have 2TH of miners on my node, but hardly anybody is getting shares.

Thanks In Advance

[zvs]

First off, re: this guide, this was on my DOGE pool, but since it's down now:

Since all the "guides" are wrong, I'll talk a little bit about latency when choosing a p2pool. This DOGE pool setup has 15s shares and 60s blocks, for five interruptions per minute. So assume you have a very high 200ms latency (and no packetloss, packetloss *IS* a big deal)... your system will continue working on an old share for 0.2s and it'll take an additional >0.2s for the server to send you out the new share information (well, plus 1-5ms overhead).... so, basically, 400ms per interruption is your DOA window.  5x400ms = 2s, 2 out of 60 = 3.33% DOA. For other coins it's even less of a factor (bitcoin with the 20s share times and the much longer block periods).  I found it wasn't worth mining on my machine locally since I ended up with tons more orphans.  European nodes in general will get less orphans & orphan rate should be the primary factor in determining the best pool. If you get 50ms latency to pool A and 200ms latency to pool B, then pool A would only be better if the orphan rate was an absolute ~2.5% or so lower than pool B.  If not, pool B is better... regardless of the DOAs looking bad on your miner or not...

Bitcoin share time is 30s, so that's even less interrupts.

Has the advice at the beginning of this thread been updated to take into account current difficulty and network hashing power, and newer hardware?

Also, what is best practice for tacking "/2000+512" or whatever onto the end of your BTC address to set a higher share quality and manual difficulty?

I'm finding myself on a good network connection with low latency on good hardware and I suddenly have 2TH of miners on my node, but hardly anybody is getting shares.

Thanks In Advance

I don't remember what the advice says at the beginning of this thread, but a lot of it has always been wrong.

I don't see a reason to set a higher share difficulty level unless you like gambling (the /2000 part)...  If you are on a pool that is 2TH, then that 512 will be lower than the default.  All it's used for is to calculate your hash rate and display it on the p2pool graphs.  The lower it is, the more data you'll transfer and the more accurate your hash rate graph will be.

Not sure how you can make a blanket statement about low latency, I mean, I'm sure lots of people in Europe have sub 50ms to my Hetzner server, but I don't.  re: 2TH and no shares, that's because the base p2pool code attempts to "equalize" the shares each pool gets.  I guess 2TH isn't a whole lot for bitcoins anymore, I have no clue.  For scrypt, let's say litecoin p2pools are at 5GH/s total, a node mining litecoins at 5MH/s will be at base share difficulty (the amt used to "attempt" to get one share every 30s network-wide), while a node at 200MH/s will have a share difficulty 20x + of the 5MH/s node.

[aboron]

I'm running my own p2pool for both bitcoin and litecoin.

I pulled the latest github master from today and I'm happily running away on the BTC instance.
My bitcoin asics are getting vardiff balanced out to around 250-400 depending on what kind they are.

The litecoin instance I ran from the same root folder.  (I didn't forget to compile the scrypt stuff first)
My scrypt asics are all coming in from one machine running cgminer 4.3.5 customized for zeus (but not by them).
This cgminer version works fine connecting to other external p2pools for litecoin.

However, when I connect locally to my p2pool for litecoin, it keeps telling the miners to set difficulty to 0.0 and it is creating havoc since my miners are backing up the usb buses trying to throw that many crappy little shares.
This has been going for 20 minutes and I only ever see messages from my p2pool for difficulty like:

Code:

 [2014-09-13 12:33:03] Pool 0 difficulty changed to 0.0

Nothing I add to the end of my litecoin address has any effect on initial or continuing vardiff, it just keeps sending me to 0.0.  Resulting in some very bad stats:

Code:

 cgminer version 4.3.5 - Started: [2014-09-13 12:42:56]
--------------------------------------------------------------------------------
 (5s):7.224M (1m):7.207M (5m):8.857M (15m):11.98M (avg):10.70Mh/s
 A:11441  R:21  HW:94363  WU:0.0/m
 Connected to 10.21.1.47 diff 0 with stratum as user L-removed-nnnnnnnnnn+128
 Block: 8a77fac5...  Diff:28.3K  Started: [13:04:13]  Best share: 22.8K

Does anyone has any ideas about how to fix this?

[aboron]

Since I'd rather be mining than screwing around, I ended up editing cgminer.c to check stratum for diff < 1 and forcing diff=256 to my asics.  This way I can still switch to a fallback pool and not lose anything.

[zvs]

Since I'd rather be mining than screwing around, I ended up editing cgminer.c to check stratum for diff < 1 and forcing diff=256 to my asics.  This way I can still switch to a fallback pool and not lose anything.

the same thing is happening to me, re: litecoin.  i didnt want to post here since i figured it was just something dumb i was doing.

in my case, it starts at 0 and slowly increases and then evens out around 0.002 difficulty,  which gets some godawful number of HW failures and about 1/2 hash rate.

"fix-protocol": true,

in the config file fixes this,  that is, using  longpolling instead of stratum

it's at nogleg.com:9326 atm.  tried setting up some stratum proxy that failed miserably too, hence the 9326 port.  no clue.  long polling works but it creates a ton of connections.  it also seems to get more DOA, but then, i usually don't get 16mhash from my X3

ed: i was running a doge scrypt p2pool like 3 days ago, w/o any problems.  i also need to fix my --p2pool-node list, but not until i get stratum working properly ^_^

[smoothrunnings]

Is latency on a P2Pool really only for when miners are connected to it from the outside or is it something more?

Thanks,

[zvs]

Latency is the time it takes for y to reach z.  I could run a local p2pool with 1ms local latency, but have some godawful amount of latency to all the other p2pool nodes, since I have jack shit for upstream.  Hence, it's better for me to use a remote server.

Since I'd rather be mining than screwing around, I ended up editing cgminer.c to check stratum for diff < 1 and forcing diff=256 to my asics.  This way I can still switch to a fallback pool and not lose anything.

I don't suppose you ever figured this out?  I'm still using --fix-protocol and longpolling.  Guess it's not a huge issue, seeing as how long polling is much faster, anyway ..  15.0 + 733, 15.733 MH/s... never saw those numbers with stratum.

though it would be nice for ppl to be able to randomly mine on my node without getting spammed out w/ the 0 difficulty shares.  

I guess I probably just need to change some minimal difficulty setting in the networks.py file, eh.  Oh, I'm finally done resetting server too, got p2pool-nodes set up nicely

ed: oh, with --fix-protocol (or "fix-protocol": true,  .. I think in .conf file) the difficulty setting works properly w/ longpolling, re: Litecoinaddress+0.05 or whatever.

[Nerull]

I just updated to the newest p2pool and for some reason my asic runs fun but if i just try to run a few gpu miners i just get continuous hw errors. I left 1mhs of gpu run like this all day and still got no shares. The older versions used to do that too, but only when initially starting up mining on the server.

Has anyone else had this problem?

[jontran]

========================
Security

Don't use the node's wallet, always configure p2pool to pay an address (use the "-a" parameter) you can secure appropriately (big fat wallets on a public server are not a good idea).
========================

What does it mean by "big fat wallets on a public server are not a good idea"?

I need some advice on rebuilding a node. I'm rebuilding my p2pool node, a home server. Can I point my asic miners at an public node to keep up with the shares with a same pay address until the home node completed? Is it a good idea to do?

Thanks,
J.

[jonnybravo0311]

It means don't run your public p2pool node on the same machine that holds your wallet.  For example I have bitcoind compiled and built without wallet functionality.  I connect my p2pool node to that daemon.  I start p2pool using

Code:

-a SOMEBTCADDRESS

My miners I point to a different address.  That way if my node gets compromised I won't lose any coin because there are none there.

[kano]

It means don't run your public p2pool node on the same machine that holds your wallet.  For example I have bitcoind compiled and built without wallet functionality.  I connect my p2pool node to that daemon.  I start p2pool using

Code:

-a SOMEBTCADDRESS

My miners I point to a different address.  That way if my node gets compromised I won't lose any coin because there are none there.

You start bitcoind with disablewallet=1 in the bitcoin.conf to have no wallet.

[jonnybravo0311]

It means don't run your public p2pool node on the same machine that holds your wallet.  For example I have bitcoind compiled and built without wallet functionality.  I connect my p2pool node to that daemon.  I start p2pool using

Code:

-a SOMEBTCADDRESS

My miners I point to a different address.  That way if my node gets compromised I won't lose any coin because there are none there.

You start bitcoind with disablewallet=1 in the bitcoin.conf to have no wallet.

I compiled it with no wallet   Pretty much negates the need for disablewallet

[luthermarcus]

Is there a way to set difficulty besides + / net to your address I set my difficulty for one of my miners to 2500 but sets at 1000. Can anyone tell me why? Or how should i set it?
bitcoinaddress+2500/2500
bitcoinaddress+2500
bitcoinaddress/2500

[roy7]

Is there a way to set difficulty besides + / net to your address I set my difficulty for one of my miners to 2500 but sets at 1000. Can anyone tell me why? Or how should i set it?
bitcoinaddress+2500/2500
bitcoinaddress+2500
bitcoinaddress/2500

kano replied to you in the other thread.

address/2500 will set your diff target to the minimum sharechain difficulty when submitting real shares, however it's so much higher than that, using / that low has no effect.

address+2500 will set your pseudo share target to that, for graphing purposes. No effect on actual shares that go on the sharechain for payouts.

[bobby88]

Hello guys ,
I make a noob experiment for p2pool , i rent miners 2 THs and point that to minefast ( which is the p2pool mining pool ) with user name my wallet add and pass x , in the other side i have miner that run on my own node (wallet) with user name and pass same with the miner that i rent ,  the target is i just want to know are the hashing power is miner rent + my miner or they run independently each other. The results of that noob experiment is each miner run independently . the question is how the p2pool networks identify each miner ? cause before i join minefast , i check my address wallet and its appear with the hashing of my own miners , after i join the minefast the hashing powers appear only the rent miner.

regards

[jonnybravo0311]

Hello guys ,
I make a noob experiment for p2pool , i rent miners 2 THs and point that to minefast ( which is the p2pool mining pool ) with user name my wallet add and pass x , in the other side i have miner that run on my own node (wallet) with user name and pass same with the miner that i rent ,  the target is i just want to know are the hashing power is miner rent + my miner or they run independently each other. The results of that noob experiment is each miner run independently . the question is how the p2pool networks identify each miner ? cause before i join minefast , i check my address wallet and its appear with the hashing of my own miners , after i join the minefast the hashing powers appear only the rent miner.

regards

Assuming I read your post correctly, you've got some hash rate (we'll call it X) pointed to one p2pool node using a BTC address (we'll call it A).  You've also got some other hash rate (Y) pointed to another p2pool node using the same address (A).

Each node will report only what the node sees for hash rate for the miners pointed to it.  So, on node 1 you'll see hash rate X.  On node 2, you'll see hash rate Y.  If the node tracks expected payouts, then you'll see the combined expected payout on each node.  This is because you're using the same address to mine to.  The p2pool network as a whole makes payouts to addresses that have valid shares on the share chain.  Since both sets of your miners (your own gear and rented gear) use the same address, p2pool itself knows of just the one address and the shares on the share chain for that address.

By the way, when you look at stats on coincadence, he guesses hash rate by address based on your expected payout.  So, in effect, you'll see about X+Y reported assuming of course you've got a full N value for your shares on the chain.

[igorwhite]

Hello!

Explain to me please:
install mintxfee=0.0005
         minrelaytxfee=0.0005
What doing bad these values?

Node getwork latency becomes  --- 50-120 ms

[rav3n_pl]

There: https://en.bitcoin.it/wiki/Transaction_fees

[igorwhite]

I already read this. I do not understand is bad for node - good for getwork latency?
Sorry for my bad English

[rav3n_pl]

Latency is less when when block created is smaller.
Setting higher fees you create smaller block because less transactions will meet restrictions.

[igorwhite]

Hello, rav3n_pl
You are a professional. Tell me please. What are the better value.
If I install:
mintxfee = 0.0001
minrelaytxfee = 0.0001

Node getwork latency= 450- 1000ms

[rav3n_pl]

On non-SSD 3GHz+ processor it is normal value.
You can limit size of block lowering maxblocksize and/or rising mintxfee.
minrealytxfee is not affecting GBT AFIK.

[tharani]

i started using p2p pool with my asic block erupter, and also i can see it connects , current reward for block's is 0 btc but after 24 hours mining it is 0.01 btc,

so does this mean that after 24 hours if i connect and and mine and find a block i will be paid 0.01.??

also the bfg miner is showing 0.00 btc/ hr

then it updated to 196nbtc/hr

1 nBTC = 0.000000001 BTC

after it started accepting so it means its mining 196nbtc now for a hour right.??

so how to i get paid and when and how can i see how much has the bfg miner mined.

there are lots of pools named p2pool

http://www.p2pool.com/

i am using this one , i don't know the pool mentioned here is the same one.

other places named p2pool

http://p2pool.in/

http://p2pool.org/

[in2tactics]

i started using p2p pool with my asic block erupter, and also i can see it connects , current reward for block's is 0 btc but after 24 hours mining it is 0.01 btc,

so does this mean that after 24 hours if i connect and and mine and find a block i will be paid 0.01.??

also the bfg miner is showing 0.00 btc/ hr

then it updated to 196nbtc/hr

1 nBTC = 0.000000001 BTC

after it started accepting so it means its mining 196nbtc now for a hour right.??

so how to i get paid and when and how can i see how much has the bfg miner mined.

there are lots of pools named p2pool

http://www.p2pool.com/

i am using this one , i don't know the pool mentioned here is the same one.

other places named p2pool

http://p2pool.in/

http://p2pool.org/

http://p2pool.in/ is the the official p2pool website.

You can follow the official p2pool thread here: https://bitcointalk.org/index.php?topic=18313.0

[tharani]

thanks i will meet you guys there.

[.m.]

Surprised it still works.
Well done !

[flameruk]

The contents of this thread have been invaluable.
Still very much up to date and working.
Carefully reading this thread got me a good working node and background knowledge of how it works.
Thanks people.

[in2tactics]

The contents of this thread have been invaluable.
Still very much up to date and working.
Carefully reading this thread got me a good working node and background knowledge of how it works.
Thanks people.

[pokapeski]

Hi there, I am newbiest newbie so be prevented 
I have been mining for almost 24 hours and there is something that escapes me.
I have this numbers now on the stats
Payout if a block were found NOW: 0.0136501 BTC. Expected after mining for 24 hours: 0.0752 BTC per block.

I understand that the money that I have actually made is 0.0136501 BTC
The 24hours mining estimation I take is just that, an estimation, however I noticed that it has always been much higher than the estimation I was making based on the shares found or the evolution of the confirmed payout (0.0136501 BTC).

Is the "Expected after mining for 24 hours" estimation something I should trust in the long run?

thanks

[in2tactics]

Hi there, I am newbiest newbie so be prevented 
I have been mining for almost 24 hours and there is something that escapes me.
I have this numbers now on the stats
Payout if a block were found NOW: 0.0136501 BTC. Expected after mining for 24 hours: 0.0752 BTC per block.

I understand that the money that I have actually made is 0.0136501 BTC
The 24hours mining estimation I take is just that, an estimation, however I noticed that it has always been much higher than the estimation I was making based on the shares found or the evolution of the confirmed payout (0.0136501 BTC).

Is the "Expected after mining for 24 hours" estimation something I should trust in the long run?

thanks

You have not made anything yet. The "payout if block found now" statement only tells you what you WOULD earn if a block was found right NOW based on your current shares on the sharechain. The "expected after mining for 24 hours" statement is a PREDICTION based on the current p2pool hashrate and your current hashrate.

[pokapeski]

yes, I meant, I trust the pool so that when the new block is found the payment will realize.
My concern was about the difference between the estimation and the first figure of payments that I understand will happen once a block is found.
I understand from your post then that in the long run the estimation should roughly be somewhat reliable (given the difference that I notice between my results so far and the expectation).

[in2tactics]

yes, I meant, I trust the pool so that when the new block is found the payment will realize.
My concern was about the difference between the estimation and the first figure of payments that I understand will happen once a block is found.
I understand from your post then that in the long run the estimation should roughly be somewhat reliable (given the difference that I notice between my results so far and the expectation).

It usually takes about 3 days for your 24 hour payout prediction and your payout now to normalize.

[pokapeski]

thanks for the clarification.
For the record; On the tests I made the income seems to have noticibly improved after I applied the changes indicated in the first post of this thread.

[in2tactics]

thanks for the clarification.
For the record; On the tests I made the income seems to have noticibly improved after I applied the changes indicated in the first post of this thread.

Good to hear!

[jonnybravo0311]

thanks for the clarification.
For the record; On the tests I made the income seems to have noticibly improved after I applied the changes indicated in the first post of this thread.

Unless your node is the one submitting the blocks, the changes in the first post have no bearing on your mining income, since it is somebody else's node that has created and submitted the block, and you have no control over whether or not that node has followed the recommendations.

What the first post states is simply that if you increase the transaction fee minimum for any transactions you include in blocks you create, and also increase the size of the blocks you create will translate into blocks containing more transactions with higher fees.  Again... just because you're doing it, doesn't mean anyone else is.

What really matters to you as a miner is that your shares are submitted and not DOA or orphaned.  That means having a well connected peer.  The faster you can get your shares out to the network, the less of a chance you have of them being orphaned.  The faster your own node processes shares, the less chance you have of them being DOA.