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

Quote from: mdude77 on July 05, 2014, 08:42:55 AM

At the moment my conclusion is a proxy isn't going to help getting S2s working with p2pool.

I believe the problem is the constant "drop EVERYTHING you are doing and restart" messages that p2pool sends every 30 seconds. Then it rejects all the old work coming p2pool leading to large DOA.

My recommendations for p2pool to become more S2 friendly:

1 - Sending new work every 30 seconds is fine. It's apparently not necessary to force the miner to restart "clean jobs" = true. It also needs to gracefully accept work from prior job IDs for a period of time like other pools do.

2 - Start at a higher pseudo difficulty than 1.

3 - Allow a higher pseudo difficulty than 1000.

4 - Send the actual errors back for rejected work, instead of just "false".

If I understood python I'd take a stab at 2 through 4. 1 might be a big deal.

Here are 2 patches for p2pool that address point 2 and 3 from your list.

First a simple patch that allow higher than 1000 pseudo-difficulty.
https://github.com/jaketri/p2pool/commit/05b630f2c8f93b78093043b28c0c543fafa0a856

And another patch that add "--min-difficulty" parameter to p2pool. For my setup I use 256 as start pseudo difficulty.

https://github.com/jaketri/p2pool/commit/5f02f893490f2b9bfa48926184c4b1329c4d1554

How do I apply those patches? GIT noob here...

You can cherry-pick (see "git help cherry-pick") the changes to your local git branch ...

... or you can manually apply the one line patch that allow higher than 1000 pseudo-difficulty and use "walletaddress+difficulty" as username to ask p2pool to disable dynamic pseud-difficulty and only use the requested difficulty.
For example to only receive jobs with pseudo-difficulty "2048" for your wallet-address "1Bitcoin552oR6LtAp55PMsfbEaFLjuTjg" you need to use as username "1Bitcoin552oR6LtAp55PMsfbEaFLjuTjg+2048"

You can use the stock p2pool without any patch if you need pseudo-difficulty of 1000 or less.

ceslick

full member

Activity: 161

Merit: 100

digging in the bits... now ant powered!

Quote from: mdude77 on July 05, 2014, 08:42:55 AM

At the moment my conclusion is a proxy isn't going to help getting S2s working with p2pool.

I believe the problem is the constant "drop EVERYTHING you are doing and restart" messages that p2pool sends every 30 seconds. Then it rejects all the old work coming p2pool leading to large DOA.

My recommendations for p2pool to become more S2 friendly:

1 - Sending new work every 30 seconds is fine. It's apparently not necessary to force the miner to restart "clean jobs" = true. It also needs to gracefully accept work from prior job IDs for a period of time like other pools do.

2 - Start at a higher pseudo difficulty than 1.

3 - Allow a higher pseudo difficulty than 1000.

4 - Send the actual errors back for rejected work, instead of just "false".

If I understood python I'd take a stab at 2 through 4. 1 might be a big deal.

Here are 2 patches for p2pool that address point 2 and 3 from your list.

First a simple patch that allow higher than 1000 pseudo-difficulty.
https://github.com/jaketri/p2pool/commit/05b630f2c8f93b78093043b28c0c543fafa0a856

And another patch that add "--min-difficulty" parameter to p2pool. For my setup I use 256 as start pseudo difficulty.

https://github.com/jaketri/p2pool/commit/5f02f893490f2b9bfa48926184c4b1329c4d1554

How do I apply those patches? GIT noob here...

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: -ck on July 06, 2014, 03:55:30 PM

Quote from: mdude77 on July 06, 2014, 03:28:32 PM

There's a unique ID # that's passed with each message from the miner to the pool. That number is incremented for each message. Each share is a message. So say the Ant sends message #122 and it's a share submission. If p2pool rejects it, the ID it uses on the reject is its own internal counter, so it could be #155. I'm not sure cgminer knows how to match that up.

cgminer sends a unique ID message with every share submitted It then locally adds a record of the submitted share to a database. When it gets responses from whatever the upstream server is (be it a pool or a proxy) it matches the return response based on the ID and looks it up in its database to determine what the "server" thought of its share submission. cgminer does not assume messages return synchronously and uses the ID to look up the response to its submissions. If the upstream server corrupts the share submission ID by changing its return submission ID, then that's a fault and it should not do that. As far as I'm aware, no functional pool/proxy/server changes the share submission ID to give a different ID in response.

That's how I interpreted that things should be working as well.

I just double checked my code, and it appears I misspoke. I was looking at the return message after I matched it up with the miner, so of course they would differ.

Nevermind!

M

nreal

full member

Activity: 932

Merit: 100

arcs-chain.com

Quote from: mdude77 on July 06, 2014, 03:28:32 PM

Quote from: nreal on July 06, 2014, 10:51:51 AM

Quote from: mdude77 on July 06, 2014, 03:28:32 PM

What is the doa% with s2? on pool level its 13% now, so anything below 13 is just fine.

I believe it's much higher than that.

M

25% ?
Local dead on arrival: ~ =?

When I run it through my proxy, the Ants report in excess of 50% rejects. I'm not sure that number is right, but I haven't double checked it to confirm.

I'm suspecting that p2pool isn't properly returning matching reject messages, so the Ants don't really know the amount of rejects. I'm not 100% of this, as the stratum specs leave a lot to interpretation/figuring out on your own.

What I'm referring to is this.

There's a unique ID # that's passed with each message from the miner to the pool. That number is incremented for each message. Each share is a message. So say the Ant sends message #122 and it's a share submission. If p2pool rejects it, the ID it uses on the reject is its own internal counter, so it could be #155. I'm not sure cgminer knows how to match that up.

My proxy takes care of matching those up, so the message the Ant gets back from the proxy (Relayed from the pool) is the same # of the share from the Ant, in the example above, #122.

M

With walletadress/10000000 i can expect one share that pays in 20 h - with 4 ants1 pencil modded to 150gh - anything else is just waste of space. its the only 1 share in 20 h im interested here. if i get 2 of those in a day i call it a lucky day. The pool migth just be usable for s2s with similiar settings - some days you score bigtime some not so well. I think you are using those s2 with own walletaddress for each.

This is serious mining to go after bigger fishes. Im not worried about the variation - this is more fun than chase those smaller shares..

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

There's a unique ID # that's passed with each message from the miner to the pool. That number is incremented for each message. Each share is a message. So say the Ant sends message #122 and it's a share submission. If p2pool rejects it, the ID it uses on the reject is its own internal counter, so it could be #155. I'm not sure cgminer knows how to match that up.

cgminer sends a unique ID message with every share submitted It then locally adds a record of the submitted share to a database. When it gets responses from whatever the upstream server is (be it a pool or a proxy) it matches the return response based on the ID and looks it up in its database to determine what the "server" thought of its share submission. cgminer does not assume messages return synchronously and uses the ID to look up the response to its submissions. If the upstream server corrupts the share submission ID by changing its return submission ID, then that's a fault and it should not do that. As far as I'm aware, no functional pool/proxy/server changes the share submission ID to give a different ID in response.

raskul

sr. member

Activity: 434

Merit: 250

Quote from: MineForeman.com on July 06, 2014, 03:38:12 PM

Quote from: raskul on July 06, 2014, 06:16:49 AM

Yet another reason i like p2pool
I wouldn't imagine it possible to hide the fee is it?
In any case if the fee is hidden just don't use the node

Obviously you would not just hide the fee's, you would make it appear to be 0 while in reality you could set it to 1% or 5% or 100% (the user would work it out fairly quickly if it was 100% though).

Neil

yeah, but ye wouldnae. really?

MineForeman.com

legendary

Activity: 896

Merit: 1000

Quote from: raskul on July 06, 2014, 06:16:49 AM

Yet another reason i like p2pool
I wouldn't imagine it possible to hide the fee is it?
In any case if the fee is hidden just don't use the node

Obviously you would not just hide the fee's, you would make it appear to be 0 while in reality you could set it to 1% or 5% or 100% (the user would work it out fairly quickly if it was 100% though).

Neil

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: nreal on July 06, 2014, 10:51:51 AM

Quote from: nreal on July 06, 2014, 10:51:51 AM

What is the doa% with s2? on pool level its 13% now, so anything below 13 is just fine.

I believe it's much higher than that.

M

25% ?
Local dead on arrival: ~ =?

When I run it through my proxy, the Ants report in excess of 50% rejects. I'm not sure that number is right, but I haven't double checked it to confirm.

I'm suspecting that p2pool isn't properly returning matching reject messages, so the Ants don't really know the amount of rejects. I'm not 100% of this, as the stratum specs leave a lot to interpretation/figuring out on your own.

What I'm referring to is this.

There's a unique ID # that's passed with each message from the miner to the pool. That number is incremented for each message. Each share is a message. So say the Ant sends message #122 and it's a share submission. If p2pool rejects it, the ID it uses on the reject is its own internal counter, so it could be #155. I'm not sure cgminer knows how to match that up.

My proxy takes care of matching those up, so the message the Ant gets back from the proxy (Relayed from the pool) is the same # of the share from the Ant, in the example above, #122.

M

EDIT: I was looking at the wrong thing.. the return message from p2pool matches the originated message.

sconklin321

sr. member

Activity: 543

Merit: 250

Orjinal üyelik ToRiKaN banlanalı asır ol

What is the doa% with s2? on pool level its 13% now, so anything below 13 is just fine.

I believe it's much higher than that.

M

25% ?
Local dead on arrival: ~ =?

I think the problem isn't just DOA. From what I've read, something appears to be slowing them down all around since, I believe stated earlier in the thread, even the Ants are showing the lower hashrate, not just p2pool.

nreal

full member

Activity: 932

Merit: 100

arcs-chain.com

What is the doa% with s2? on pool level its 13% now, so anything below 13 is just fine.

I believe it's much higher than that.

M

25% ?
Local dead on arrival: ~ =?

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: mdude77 on July 05, 2014, 08:39:25 PM

What is the doa% with s2? on pool level its 13% now, so anything below 13 is just fine.

I believe it's much higher than that.

M

nreal

full member

Activity: 932

Merit: 100

arcs-chain.com

What is the doa% with s2? on pool level its 13% now, so anything below 13 is just fine.

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: jonnybravo0311 on July 05, 2014, 02:11:39 PM

This may seem like a simplistic approach, but if you're getting a whole lot of work submitted after the pool says "drop everything", couldn't you mitigate that by setting the queue depth to 0 in cgminer on the S2?

Good idea. I haven't tried that yet. I think that's reachable via the api...

setconfig|queue,0

I just tried it. No difference. Still way too many rejects, because the Ant can't respond quick enough to job restarts.

I don't think p2pool can solve this without increasing the share time significantly. The Ants will still get rejects, but since there won't be as many restarts, the ratio will be lower.

Ultimately I believe the problem is in Bitmain's hands. (Or Kano, if he can rewrite the code to be more responsive.)

M

raskul

sr. member

Activity: 434

Merit: 250

Yet another reason i like p2pool
I wouldn't imagine it possible to hide the fee is it?
In any case if the fee is hidden just don't use the node

EU:

eu.centralcavern.uk:9332/fee

Quote from: sconklin321 on July 05, 2014, 06:03:04 PM

Quote from: MineForeman.com on July 05, 2014, 05:43:29 PM

Quote from: rav3n_pl on July 05, 2014, 05:27:18 PM

Only way is to change poll code and hide fee.
P2pool idea is to run own node and use it

Use others only as backup.

Not everyone can/want's to run their own node. It would be cool though if they could use someone else's but I was wondering if there is some way to prove that it is fair.

Neil

I don't know if there is anyway of proving any pool is really fair. To that end, what would stop a pool op from saying 0 fee or a 1% fee and then taking all the profits. In the end its all about what you feel comfortable with. If, say you wanted to see the true node fee (barring them changing the coding behind p2pool) you can go to the node/fee and it is published there. For example, the node I have setup, and will be returning to mining on once I get my two addresses into eligius's payout queue, is http://mine.njbtcmine.net:9332/fee.

FYI, that node is located in Newark, NJ if anyone is looking for a node to mine on.

Edit: Someone correct me if I'm wrong, but the fee to P2Pool is in shares too, isn't it? So you'd notice your estimated payout adversely effected if someone did edit the code to hide the fee and take 100%, or something stupid like that.

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: cathoderay on July 06, 2014, 06:04:07 AM

Quote from: mdude77 on July 05, 2014, 08:35:28 PM

Quote from: mdude77 on July 05, 2014, 08:35:28 PM

Here are 2 patches for p2pool that address point 2 and 3 from your list.

First a simple patch that allow higher than 1000 pseudo-difficulty.
https://github.com/jaketri/p2pool/commit/05b630f2c8f93b78093043b28c0c543fafa0a856

And another patch that add "--min-difficulty" parameter to p2pool. For my setup I use 256 as start pseudo difficulty.

https://github.com/jaketri/p2pool/commit/5f02f893490f2b9bfa48926184c4b1329c4d1554

Thanks, that's good. Now why isn't it in the main code?

M

Because that would require some kind of participation from the developer....

Talking of which, it's great to see him bouncing ideas off the community in an effort to help cure these issues isn't it?......... Roll Eyes

Good point.

Forks have their place. However my concern is if there isn't one main fork, the average user won't know what to use.

M

cathoderay

sr. member

Activity: 379

Merit: 250

Welcome to dogietalk.bs