Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 325. (Read 2591964 times)

And when you're running it on a different pool, it will hash at 2.8TH/s?  Unfortunately I just am not knowledgable enough with the KNC hardware to provide you with any kind of root cause analysis.  My suspicions are that if it hashes at 2.8TH/s on other pools, but only 2.35TH/s on p2pool, then it suffers the same problem as the S2 does.  If that's the case, then either one of the cgminer developers, or KNC themselves would have to provide an updated version of cgminer for the unit that is compatible with p2pool.

Here it is running for 9 hours on p2pool, Current firmware revision: neptune-1.00 (cgminer 4.4.1)

Hmmm... I wonder if they suffer the same problem the S2 from Bitmain did... S2 consistently reported / hashed at 10-15% lower on p2pool than on other pools.  Kano was working on a new cgminer build for a while, but not sure if he ever completed it.  I know KNC uses an older version of cgminer that they forked and customized with their own drivers.

Anyone else with the Neptunes on p2pool care to chime in here?

Neptune with 4 cubes (2.8 THS)

The biggest problem with this is as windpath points out, in addition to moving difficulty target and share weights.  All things being equal, you can easily calculate what the "ideal" value per share is.  P2pool pays out a block-finder's reward of 0.5% to the miner who found the block, and the remaining block reward to everyone else.  It pays 8640 shares as follows:

1 share (the miner who found the block) gets 0.125BTC which is 25*0.005
8639 shares split the remaining 24.875BTC, which is 0.00287938BTC per share

If the difficulty remained constant (which it does not), you could calculate how many shares you should have on the chain in the payout window (8640 shares, or about 3 days) knowing your hash rate:

Take the number of shares, multiply it by the reward per share and you've got your answer.  That answer, though, is really kind of irrelevant, since it doesn't take into account the variables.

Or, look at the "payout if block found now" stat, which will tell you exactly how many BTC you'll get should a block be found.

I suppose another way to get a gauge on how you're doing is to look at the current pool's hash rate vs your hash rate.  Then, take the blocks expected per day to give you an average expected daily payout.  Example you have 1TH/s and pool has 1000TH/s:

Not surprisingly, the number I ended up with is exactly what you'd expect any online calculator to give you for expected daily earnings with 1TH/s at current difficulty.  I could have simplified it considerably just by doing this:

Expected per-block earnings are then just:

So... at the end of all of that...

Look at the value given by "expected payout if block found now" and compare that to the "current block value" multiplied by "your hash rate" / "pool hash rate".

If your expected payout is bigger than the "current block value" multiplied by "your hash rate" / "pool hash rate" then you're doing better than expected (i.e. you've been lucky).  If your expected payout is smaller, you've been unlucky.

EDIT:
Most every p2pool front end will display your hash rate in a graph.  Take a look at windpath's node and you'll even see graphs of hash rate by mining address.

As for your hash rate always showing lower on p2pool... what's your hardware?

Thank you all for your attempts to help me.

So normally with a non p2pool pool, I can easily find issues  and see my earnings drop by seeing the live hashrate. (eligius has 1min 5min hashrate etc)

On p2pool it's very hard to know my actual hashrate. So if my miner has issues,or my nose has network issues,  and I am down 5-10% of my hashrate ,  it's hard to detect.

My hashrate always shows less on p2pool than  on a normal pool
Any suggestions?

This is an interesting proposition, the problem I see is in the big swing in hash rates as reported by the pool.

For example:

Today @ 10:52 EDT the pool was reporting 1.07PH/s

Today @ 11:16 EDT the pool was reporting 1.73PH/s

So in a span of 24 minutes there was a 660TH/s fluctuation that would have significantly impacted your earnings in any estimate, but would not have had much of an impact on your actual earnings had you been actively mining at that time.

I think a better solution would be to find a miner already on the pool who has a hashrate similar to yours and look at their recent payouts.

That would give you an idea of what to expect, however you still have to take into consideration that the given miner could currently be lucky/unlucky.

Also to ensure the best estimate, you will want to make sure the miner you are looking at has been active for at least 3 days in the pool, wich can be ascertained by looking at their payouts over the last 3-4 days...

All of this can be found at the link below by clicking on the "Active Miners" tab and finding a few miners at or near your hashrate, and checking out their dashboards to see past payouts and expected payout.

http://minefast.coincadence.com/p2pool-stats.php

I must be misunderstanding what you are looking for...  Doesn't the bolded part above tell you exactly that?  I know it was fairly accurate at predicting my payouts when I was mining on P2Pool.

This will show me based on my effectual  hashrate ,  averaged over a 3 day PPLNS period,  your expected earnings are 0.xyz BTC per block.

This doesn't give me how much btc my  raw "abc"  hashrate (divide by current total pool speed) working in ideal perfect situation will give me if my miner continues to reliably hash at "abc"  hashrate

This will allow me to troubleshoot if I have network issues,  config issues,  or hardware issues...  That is my main concern

http://localhost:9332 will give you that information if you are running your own node.  The 1st page will tell you your current payout if a block is found now (based on shares actually found), and it also shows an estimate of what you should earn per block if you maintain your current hash rate for 24 hours.

I'm looking for a calculator,  something that takes into account the current p2pool hashrate and yours and gives you an accurate estimate per block  how much you should make,  so I can verify that my miner is working correctly and my payout makes sense

No.  Opening port 9332 just exposes your node to the outside world, so other miners could potentially connect and mine on it.  If by "helping the shares" you mean, "having a lower percentage of orphans" then you're best served by ensuring the nodes you connect to have low ping times.  Opening port 9333 will allow for connections to the p2pool network's peers - i.e. nodes can connect inbound to you.  If you're having problems with "dead" shares, ensure your miners are configured optimally, and that you have solid internal network connections.

Quick explanation for you:

Orphaned shares - you found a share and broadcast your copy of the share chain.  Unfortunately, somebody else's copy of the share chain was broadcast and accepted prior to yours.
Dead shares - you found a share, but it is not added to the chain or broadcast because by the time you found that share, the share chain had already been updated.

Hello all,
I know this has been asked.

If I open up my closed network and port forward 9332
to my p2pool machine.......
will this help
the shares???
Even if there is no one logging in and using my pool but me???

Thanks for any info on this....

I can't see how it could be.

M

Adjustment of scan time is from the CPU mining days. Adjustment of expiry time is from the pre-longpoll mining days (i.e. first getwork servers long before stratum). So neither of them have been helpful for over 2 years, not even for GPU mining. Most attempts at modifying them since then have been based on misinformation and mining solo to random altcoins.

They're pointless, but if you set expiry to 1 you may have some issues.

Was scan-time set to 1 and expiry set to 1 *ever* good?  I just did a quick google search and it looks like a lot of these GPU miner guides actually recommend that crap.  I always used a scan time of 30, expiry of 60 and queue of 1.  Was I wrong that whole time?  haha

Note that you can set most of these temporarily via API through SSH.  That'll allow you to test the changes before you make them permanent.

M

Yes, that's the summary.

Thanks for your help.  If I understand you correctly, the following are your recommendations:

• For p2pool, queue depth of 1.
• Certain hardware that uses their own customized fork of cgminer may have different queue depth requirements due to driver implementation
• Scan time and expiry settings are pointless on modern mining hardware

Your guidance is much appreciated.

I don't know what they did in their driver that needs such a large queue. I'd recommend a queue of 1 for every piece of hardware, always, on p2pool, unless there is some unique issue with the device that really needs it larger. S3 might fall into that category. Scan and expiry do nothing useful on today's hardware, today's stratum mining or with p2pool. All recommendations you may read are misguided. Bitmain really is using an older cgminer; they just kept working with the codebase they forked when they first created their own cgminer driver fork for S1.

EDIT: Virtually all manipulations of queue are also misguided, even if for other pools; the default is best there.