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

I've just got a few S1's and are mining on my node, what does the update fix?

You assumed correctly my good fellow 

I assume that's what he meant, by saying individual addresses instead of individual names

If you name a miner anything other than a direct wallet address then it'll go to the default wallet

There's nothing wasteful with giving your workers individual addresses - and it's the easiest 

Make sure you're using Kano's cgminer patch for S1s.

M

Looks like my pool stats did report normally after a couple shares were submitted, and I was also paid the other missing shares after I had restarted p2pool.  Now I have a couple of questions maybe you can help me out with:

I would like to have each miner use a non wallet address rather than configure each miner with the same address for better individual tracking.  I figured this could happen a couple ways, 1 would be to create a new receiving address in the wallet for each miner, but that seems to wasteful.  2.  I was thinking to set the pool fee to 100% and set the -a payout address and then configure miners with any textual username I prefer.

How would one do this will the least amount of effort?

Keep persisting with it man. 

What's your orphan rate?

ed:  I just checked, it looks like they reset it just a little bit ago, so can't really tell atm.  It is showing 1 orphan out of 11 shares, if that was the norm, it'd be pretty crap..

read what mr. t says on nogleg.com:9555 ... the only change i'd make is that it's more like 7 interrupts per minute for DOGE.. p2pool *tries* to get a share every 15s, but it's faster than that in practice

i think bitcoin is supposed to be 30s shares, w/ the 10 min blocks (more like 8 minutes nowadays but w/e).  so would maybe call it like 3 interrupts a minute

Hello all.

I have been giving p2pool a chance, for over three weeks now and i've seen quite some shares and blocks coming in. The Antminer S1's doing well... Very low latency and DOA node (minehammer.com).

So far so good, but... the rewards are lower than any other pool i've tested so far! See attached image.

I am expecting at least 0.048 for my 800Gh/s.
Highest payout has been 0.041 (once), lowest 0.025

Tried setting pseudo-difficulty higher to 1k for another week with no difference.

Is this what i can expect from p2pool or will get things better over time? I can't imagine i've to be patient for weeks to have pplns to settle...

I'm using 4 x antminer S1 on one wallet address. Also tried splitting up w/o avail.

Thanks for any advice and input!    

Martin Beek.

http://www.provost-intel.nl/tmp/minehammer.jpg

Great questions, gigabitfx.  I'd like to add to the information that windpath has already provided:

1) Setting pseudo-share difficulty determines how many shares from your miner that the p2pool node evaluates.  In p2pool, your miners must submit a share of a given difficulty to be considered.  For example, if you set your pseudo-share difficulty to 1, every single share your miner finds will be considered.  It makes the graph look very smooth, but floods the node with useless traffic.  If you set the pseudo-share difficulty to 1024, then only shares that are greater than 1024 will be considered.  The graph looks very spiky, but the node doesn't have to deal with the extraneous traffic.

The p2pool node will assign pseudo-share difficulty automatically based upon the node's combined hash rate.  If you're running your own private node, you really don't need to bother setting either pseudo-share or share difficulty.  If you're mining on someone else's node, then you might want to set them if the hash rate you're contributing is significantly higher/lower than what the node currently has.

2) You won't lose shares if you restart your node.  Your shares are stored in the share chain.  The default behavior of p2pool does not persist your node's shares across restarts (windpath solved this by creating a database); however, rest assured that every share you've found is part of the share chain.

3) Your expected time to share is based upon your hash rate and the current difficulty target.  The formula is exactly the same as the expected time to find a block of BTC:
It has no bearing on whether the node has been running for a while or have any stats to work with.

4) This is kind of misleading since it isn't well explained.  This value is the expected payout to the NODE's wallet - not to your miner - UNLESS your miner is the same wallet as your node.  So, let's assume you have started your node as:
If you configure your miners with the user name "SOMEWALLETADDRESS" then that expected payout if block found now value will show what you expect.  If you configure your miners with the user name "ANOTHERWALLETADDRESS" then that expected payout value will show 0 (unless you charge a fee to mine on your node, in which case it would show whatever charges have been assessed to your miners).

5) I don't know of any advanced manuals.  The best information I've found is here on these forums, the p2pool wiki and through reading the p2pool code.  This thread is a great place to learn, although going through nearly 440 pages is kind of painful

Hope this helps.

I'm actively developing the front end on my site, it's still in beta and requires PHP and a DB to be set up on the node.... It does address some of your concerns about not being able to see shares after a restart... I posted some of the preliminary code in this thread here if you want to check it out.

The expected time to share looks about right to me, here is one of my miners (2x S1), about double your speed, about 1/2 the expected time-to-share:

http://mining.coincadence.com/miner.php?id=13AxQAKFiy6Dks5Jwdbah3rhMJAJ9UzwHk

Can you share that frontend your using?  Im used to mining on slush's pool so I understand a little about variance.  mdude77 I do indeed have new cgminer for s1.

Im still confused about the data on the homepage and if my data is normal for a newly configured p2pool, or if i need to look further into it.  Here is the stats listed
http://s2.postimg.org/lh6uy5iqx/Capture.jpg

Is the "expected time to share" normal for my node uptime?  Ive seen others that show it down to an hour with similar pool speed as mine.  I suppose most of my confusion is that with slushs pool i see shares coming in from my miners much more frequently than this and of course they state the average btc for current round as well.  I feel im flying more blind with p2pool, especially with 0 as expected payout.  The vanilla p2pool interface showed an expected payout number, even when pool was freshly fired up and went up/down as data came through.

In case you missed it, make sure you update your S1 with the cgminer patch for p2pool.

https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

M

Hi Gigabit,

I'm by no means the expert, still studying the code and learning, but I'll give you my best advice and if I'm wrong, or there is a better solution hopefully someone will jump in...

1. It's constant.
2. Restarting will dump all your peers, and re-start many of the stats. Accepted shares will not be lost during a restart, but will not show on your stats page after, obviously shares submitted during a restart will be lost or stale by the time your node is back up. I try to limit restarts as much as possible.
3. Expected time to share is based on your ~estimated~ hash rate, is subject to your miners luck/variance, and can vary greatly.
4. Once you get some shares in the current block this will change, also subject to variance, some days will be higher and some lower.
5. I don't. There are some good tutorials for getting it up and running efficiently here on the forum, and on some alt-coin forums, but no definitive docs that I have found...

Here is an example of the variance/luck, the bottom 2 miners have both been consistently mining on p2pool, the bottom one is currently in a streak of good luck, while the middle one is in a streak of what I'd call less then ideal luck...



It all balances out over time, a key to successfully mining on p2pool is having the patience and consistency to stick with it until it does

Hi Windpath, thanks for the info here, im running some s1 and was having hard time with google on a definitive response to setting the pseudo share.

couple of questions
1. is 0.00000116 a static constant, or based off dynamic number?  Wondering if i need to redo the math periodically to keep my miners running efficiently.
2. do you know of any downsides to restarting p2pool, i noticed i lost a few shares once i had done so, but technically i dont understand why that would be.  i did however update the -a payout address, perhaps that restages the pool?
3. "expected time to share" seems to stay around 7-12hrs, im assuming its because the pool doesn't have any stats to work off of yet?
4. "payout if a block were found NOW" seems to remain at 0, any tips on that?
5. know of any p2pool advanced docs/manuals out there?

Thanks for any info

I'm showing 682TH/s on my node, a nice jump....

If you have some new miners hitting your node you may want to set your share diff and pseudo share diff on your miner....


If your running S1's set to 0 ("0" defaults to lowest p2pool diff, currently 1677854.73)

And to 220.4 (optimized for 190GH/s)

is calculated as your hash rate in KH/s times 0.00000116

i.e. 190,000,000 * 0.00000116 = 220.4

Here is an example for an ant S1:

Code:

19vXrwKGUhK4cCU8tA4kWZgbChcmh9a6qj/0+220.4

If you have a hash rate over 1TH/s you might consider upping your share diff to something higher then the p2pool minimum to reduce network traffic and increase the value of your shares...
[/quote]

awesome thanks!

Replacement updated version of CGMiner for the S1:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

whats the S1 miner tweaks he has done?

This is good news! Kano done a great job with the S1 miner tweaks - I use it on all my S1's with excellent results.

I will gladly donate to the development of an S2 equivalent - suggest everyone else do the same 

Peace.