[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 667.

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: rav3n_pl on July 14, 2012, 01:33:47 AM

P2pool software is updated, xrolll changed to 120 seconds and some other stuff. It should prevent all this dupe madness (unless you have over 35GH on one miner....).

I put one miner back on p2pool. I double checked my math and p2pool is pretty close to ozcoin.

I also changed my xroll to 120, and I'm still getting a lot of dupes. Sad

when you say "p2pool software is updated", what do you mean? I still show the official version as 3.1

M

RandomQ

hero member

Activity: 826

Merit: 500

p2pool official birthday?

June 17, 2011?

mid-July, 2011?

July 26, 2011?

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

... and if you look at the cgminer API 'stats' command it will tell you the network performance figures for each pool so you can compare them that way for active pools.
However, the actual non 'Pool' stats in there are really all that matter since as long as cgminer is getting work before it is needed that's all that matters.

rav3n_pl

legendary

Activity: 1361

Merit: 1003

Don`t panic! Organize!

UR correct.
Looks like I`m connected to very few European nodes, only 2-3 addresses under 100ms, on both LTC and BTC pool.

RandomQ

hero member

Activity: 826

Merit: 500

so I was looking at /pings I think this is ping time to other p2pool servers
IE "108.175.12.32:9333": 271.435022354126,

and /user_stales i think is a percent of stales?
IE "1GREEN1Q1iGnonZ5yBdFbxifYdwhbzNU1m": 0.056818181818181816

Any Ideas?

Using 3.1-29-gfc4ae93

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

We're still disagreeing about what the "expire=" means. cgminer can roll up to 7000 seconds into the future, but will only work on rolled work for $expire seconds before discarding it.

rav3n_pl

legendary

Activity: 1361

Merit: 1003

Don`t panic! Organize!

P2pool software is updated, xrolll changed to 120 seconds and some other stuff. It should prevent all this dupe madness (unless you have over 35GH on one miner....).

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: rav3n_pl on July 13, 2012, 08:21:31 AM

Quote from: -ck on July 13, 2012, 06:25:14 AM

I don't understand. If p2pool can roll the time locally fast enough, there should be no need to tell the mining software to roll the time at all. Alternatively, if you let the mining software roll the time, why should p2pool roll time at all? There's some kind of catch 22 thing going on here, and yet it should be very low overhead to roll the time. Something is missing in this equation. The mining software should report if it supports nrolltime in X-Mining-Extensions: "longpoll midstate rollntime submitold". If it supports rollntime then p2pool should not be rolling the time itself and allow the miner to do it by advertising X-Roll-Ntime (potentially with some expire= but just "Y" should suffice here). If it does not support rollntime, then p2pool should roll the time itself and not advertise X-Roll-Ntime.

Looks like killing rolltime line is best option if using cgminer then

I did that and it drove cgminer nuts. It complained non stop about the p2pool not supplying work fast enough and directed all the work to my backup pools.

Anyhow, I fixed mine. I directed all my workers to ozcoin again. Experiment is over (a week), things haven't changed, I still do better on 5% PPS on ozcoin than I do on p2pool.

M

tucenaber

sr. member

Activity: 337

Merit: 252

Quote from: Schleicher on July 13, 2012, 10:43:16 AM

Looks like these are the options we have:
1. recalculate the merkle root each time p2pool is going to send work to the miner

this will increase CPU load
the miner can roll the time

This is incorrect. We don't have to recalculate merkle-roots at every request. We only have to calculate once for each miner each time we get new work, compared to once for all miners as it is now.

For those that have only one miner connected there will be no difference.

Schleicher

hero member

Activity: 675

Merit: 514

Looks like these are the options we have:
1. recalculate the merkle root each time p2pool is going to send work to the miner

this will increase CPU load
the miner can roll the time

2. p2pool rolls the time, don't let the mining client do it

this will result in more getwork requests

rav3n_pl

legendary

Activity: 1361

Merit: 1003

Don`t panic! Organize!

Quote from: -ck on July 13, 2012, 06:25:14 AM

I don't understand. If p2pool can roll the time locally fast enough, there should be no need to tell the mining software to roll the time at all. Alternatively, if you let the mining software roll the time, why should p2pool roll time at all? There's some kind of catch 22 thing going on here, and yet it should be very low overhead to roll the time. Something is missing in this equation. The mining software should report if it supports nrolltime in X-Mining-Extensions: "longpoll midstate rollntime submitold". If it supports rollntime then p2pool should not be rolling the time itself and allow the miner to do it by advertising X-Roll-Ntime (potentially with some expire= but just "Y" should suffice here). If it does not support rollntime, then p2pool should roll the time itself and not advertise X-Roll-Ntime.

Looks like killing rolltime line is best option if using cgminer then

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

I don't understand. If p2pool can roll the time locally fast enough, there should be no need to tell the mining software to roll the time at all. Alternatively, if you let the mining software roll the time, why should p2pool roll time at all? There's some kind of catch 22 thing going on here, and yet it should be very low overhead to roll the time. Something is missing in this equation. The mining software should report if it supports nrolltime in X-Mining-Extensions: "longpoll midstate rollntime submitold". If it supports rollntime then p2pool should not be rolling the time itself and allow the miner to do it by advertising X-Roll-Ntime (potentially with some expire= but just "Y" should suffice here). If it does not support rollntime, then p2pool should roll the time itself and not advertise X-Roll-Ntime.

coinnewb

full member

Activity: 155

Merit: 100

Thanks for sharing the details, tucenaber!

I also changed mine to 100 but still see the warning message from time to time. Any idea on how to proceed?

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: forrestv on July 12, 2012, 10:03:48 AM

I think the best solution is increasing the increment that P2Pool does from 12 to something huge (100?) is best. Roll-Ntime helps a lot because it lets the mining software generate enough work to feed all the GPUs with the single long poll response that P2Pool sends. P2Pool rolling the timestamp itself also helps a lot because it lets P2Pool not regenerate the merkle root which (at least now) is relatively slow, so P2Pool can broadcast the same work to every miner daemon that you have without having to regenerate it, which especially helps latency on long polls.

I doubt that any miner is ever going to roll the timestamp more than 100 seconds (this would only happen if they have more than 100 GPUs, I think?), so this preserves the benefits of rolling the timestamp in both ways. Adding a sanity check that warns if miners are rolling >90 seconds would let us know if there's anything wrong with this.

I changed mine to 100. It significantly decreased the amount of dupe messages, but I still get them here and there.

M

forrestv

hero member

Activity: 516

Merit: 643

Quote from: tucenaber on July 12, 2012, 11:06:39 AM

Quote from: forrestv on July 12, 2012, 10:03:48 AM

I think the best solution is increasing the increment that P2Pool does from 12 to something huge (100?) is best. Roll-Ntime helps a lot because it lets the mining software generate enough work to feed all the GPUs with the single long poll response that P2Pool sends. P2Pool rolling the timestamp itself also helps a lot because it lets P2Pool not regenerate the merkle root which (at least now) is relatively slow, so P2Pool can broadcast the same work to every miner daemon that you have without having to regenerate it, which especially helps latency on long polls.

I doubt that any miner is ever going to roll the timestamp more than 100 seconds (this would only happen if they have more than 100 GPUs, I think?), so this preserves the benefits of rolling the timestamp in both ways. Adding a sanity check that warns if miners are rolling >90 seconds would let us know if there's anything wrong with this.

That sounds like a hack to me Wink

How about miner specific addresses? Would that solve the problem, and if so why is it a bad idea?
Wouldn't you want to distort the block timestamp as little as possible?

Having different addresses forces the generation transaction and merkle root to be regenerated, with all the latency that that creates. It's equivalent to simply removing P2Pool's timestamp rolling and leaving X-Roll-Ntime in.

The block timestamps aren't very important - as long as they're centered around the correct time and within the bounds of Bitcoin's protocol rules, you can change them as much as you like. They're only really used by Bitcoin to recalculate the difficulty every 2016 blocks, and small changes won't affect that.

tucenaber

sr. member

Activity: 337

Merit: 252

Quote from: forrestv on July 12, 2012, 10:03:48 AM

I think the best solution is increasing the increment that P2Pool does from 12 to something huge (100?) is best. Roll-Ntime helps a lot because it lets the mining software generate enough work to feed all the GPUs with the single long poll response that P2Pool sends. P2Pool rolling the timestamp itself also helps a lot because it lets P2Pool not regenerate the merkle root which (at least now) is relatively slow, so P2Pool can broadcast the same work to every miner daemon that you have without having to regenerate it, which especially helps latency on long polls.

I doubt that any miner is ever going to roll the timestamp more than 100 seconds (this would only happen if they have more than 100 GPUs, I think?), so this preserves the benefits of rolling the timestamp in both ways. Adding a sanity check that warns if miners are rolling >90 seconds would let us know if there's anything wrong with this.

That sounds like a hack to me Wink

How about miner specific addresses? Would that solve the problem, and if so why is it a bad idea?
Wouldn't you want to distort the block timestamp as little as possible?

forrestv

hero member

Activity: 516

Merit: 643

Quote from: tucenaber on July 12, 2012, 03:04:59 AM

Quote from: -ck on July 11, 2012, 09:45:42 PM

I would think you're better off making p2pool not roll ntime and leave it to the mining software.

I'm basically with this, but I'm not sure how to achieve it. There seem to be no consensus on what expire=10 actually means.

I guess (and it is just a guess after looking at the code) the reason p2pool does it this way is because two different miners must be given unique work, and the way it does it - since the merkle root is the same - is by giving 10 second timstamp intervals to work on, assuming the expire=10 makes the miner ask for more instead of rolling past 10 seconds. This assumption is false though, which is the problem.

Now with miners rolling on their own, the load on the server would be smaller but since each miner will be working on the exact same work, the clashes will return in a different form, if you have more than one miner connected. Not a good solution...

I think the best solution is increasing the increment that P2Pool does from 12 to something huge (100?) is best. Roll-Ntime helps a lot because it lets the mining software generate enough work to feed all the GPUs with the single long poll response that P2Pool sends. P2Pool rolling the timestamp itself also helps a lot because it lets P2Pool not regenerate the merkle root which (at least now) is relatively slow, so P2Pool can broadcast the same work to every miner daemon that you have without having to regenerate it, which especially helps latency on long polls.

I doubt that any miner is ever going to roll the timestamp more than 100 seconds (this would only happen if they have more than 100 GPUs, I think?), so this preserves the benefits of rolling the timestamp in both ways. Adding a sanity check that warns if miners are rolling >90 seconds would let us know if there's anything wrong with this.

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: kano on July 11, 2012, 10:28:33 PM

Quote from: mdude77 on July 11, 2012, 07:50:38 PM

Quote from: tucenaber on July 11, 2012, 07:45:07 AM

Anyhoooo...

Removing the header S-O-L-V-E-D it! Man, I'm sooo happy! Cheesy

I made your change to my side, installed python 2.7.3 64-bit (windows) and all the associated apps needed for p2pool and fired it up.

The dupe message is definitely gone.

Now, however, cgminer on my main miner (4x7870 = 2.6g/h) is complaining non stop about p2pool not providing work fast enough. I think if my phoenix miner (4x5870 = 1.6g/h) had a better UI, it would be complaining too.

I'm not sure this is an improvement. Sad

M

However, what this is saying is that your p2pool can't handle a local miner without roll-n-time
So I'd guess your p2pool setup is very slow or has poor network connectivity to your miner since it really should be a local miner talking to a local p2pool and that REALLY should be fast?!?

You'd think that's what it means, but I don't think it's hardware related. My local workstation is running at 2.2ghz with 8gig memory. Not low on resources, it doesn't thrash the swap file. Connected via 1gb switch, then to a 1mb switch. The "not providing work fast enough" comes after the "server requested work restart message". If there's a delay, it's p2pool getting work from somewhere, I don't think it's my workstation.

M

tucenaber

sr. member

Activity: 337

Merit: 252

Quote from: -ck on July 11, 2012, 09:45:42 PM

I would think you're better off making p2pool not roll ntime and leave it to the mining software.

I'm basically with this, but I'm not sure how to achieve it. There seem to be no consensus on what expire=10 actually means.

I guess (and it is just a guess after looking at the code) the reason p2pool does it this way is because two different miners must be given unique work, and the way it does it - since the merkle root is the same - is by giving 10 second timstamp intervals to work on, assuming the expire=10 makes the miner ask for more instead of rolling past 10 seconds. This assumption is false though, which is the problem.

Now with miners rolling on their own, the load on the server would be smaller but since each miner will be working on the exact same work, the clashes will return in a different form, if you have more than one miner connected. Not a good solution...

One simple way to avoid the latter is to have unique payment addresses for each miner. That would make the merkle roots diffferent, right? Then we could do it the ckolivas way and everybody lives happily ever after

Forrest can give a better explanation of this, tho.

rav3n_pl

legendary

Activity: 1361

Merit: 1003

Don`t panic! Organize!

Maybe make this time up to 30 or 60 sec instead of removing line?

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