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

jonnybravo0311

legendary

Activity: 1344

Merit: 1024

Mine at Jonny's Pool

Well would you look at that... 3 blocks so far today...

Meuh6879

legendary

Activity: 1512

Merit: 1012

Quote from: jonnybravo0311 on March 30, 2015, 10:58:32 AM

the reality is that this wasn't so bad in the grand scheme of things.

True.

Patience pay ... on P2Pool even with ultra-low power.

jonnybravo0311

legendary

Activity: 1344

Merit: 1024

Mine at Jonny's Pool

Quote from: Songminer on March 30, 2015, 08:25:00 AM

Block. Long time coming.

While it is always unpleasant to see a multi-day stretch of no block solves, the reality is that this wasn't so bad in the grand scheme of things. With the current difficulty level, and assuming p2pool averages 1.5PH/s, we can expect a block every 37 hours or so. This last one was about 78 hours - just over 200%... a CDF of about 0.89 or so.

Now we just need a few quick blocks

Songminer

member

Activity: 76

Merit: 10

Block. Long time coming.

MissouriMiner

sr. member

Activity: 312

Merit: 250

Quote from: kano on March 28, 2015, 06:22:13 PM

... don't forget that the share messages don't actually mean anything (unless they are share-chain shares)
They are just an attempt to divine your hash rate.

Oh good. Thanks.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

... don't forget that the share messages don't actually mean anything (unless they are share-chain shares)
They are just an attempt to divine your hash rate.

MissouriMiner

sr. member

Activity: 312

Merit: 250

Info and question regarding "Share above target" messages when mining with Antminer S5's. I also post this info in the AntMiner S5 forum.

Quote from: MissouriMiner on March 27, 2015, 12:41:18 PM

My S5's get a lot of "Share above target" messages. I'm mining with my own local Bitcoin P2Pool node. The node performance is fine, GWT Latency is fine (<300ms daily average). The share above target messages are only seen when I enable Verbose mode with cgminer. Hashrate and Work Utility stats seem fine. My question is, is this a problem? Thanks.

EDIT1: So far, I only see these messages with P2Pool. Manually setting pseudo share difficulty reduced the messages, as long as I didn't set the value too high, which I don't understand. I'm using BTCADDRESS+1024 Again, the share above target messages can only be seen if verbose mode is enabled. I don't know if this is a real issue or not. I tried other P2Pool nodes too, with the same result.

EDIT2: Some more detail. I get the same "Share above target" messages with both default Bitmain version of cgminer 4.8.0 and ckolivas version 4.9.0-150105. On the server side, I'm using Forrest's latest p2pool version 13.4-67-gbcd9a50, and bitcoind v10.

Example below from cgminer screen. These messages are from when I do not use +1024 to set pseudo share difficulty.
[2015-03-28 20:14:26] Accepted 420e19cc Diff 992/693 BTM 0 pool 0 [2015-03-28 20:14:29] BTM 0: Share above target [2015-03-28 20:14:26] Submitting share 00420e19 to pool 0 [2015-03-28 20:14:26] Accepted 420e19cc Diff 992/693 BTM 0 pool 0 [2015-03-28 20:14:29] BTM 0: Share above target [2015-03-28 20:14:31] BitMain RxStatus Token: v(0) chip_status_eft(0) detect_get(0) chip_address(00) reg_address(00) crc(ef82) [2015-03-28 20:14:31] BitMain RxStatus tmp :0x01 byte4 0x00 chip_value_eft 0 reserved 0 get_blk_num 0 [2015-03-28 20:14:31] bitmain_parse_results v=0 chain=2 fifo=1119 hwv1=3 hwv2=4 hwv3=3 hwv4=0 nerr=1-1 freq=350 chain info: [2015-03-28 20:14:31] bitmain_parse_results chain(0) asic_num=30 asic_status=oooooooo oooooooo oooooooo oooooo [2015-03-28 20:14:31] bitmain_parse_results chain(1) asic_num=30 asic_status=oooooooo oooooooo oooooooo oooooo [2015-03-28 20:14:31] BitMain: Fan1: 3600/m, Fan2: 0/m, Fan3: 0/m, Fan4: 0/m Temp1: 46C, Temp2: 52C, TempMAX: 52C [2015-03-28 20:14:31] (5s):1.350T (1m):726.8G (5m):634.6G (15m):376.5G (avg):1.126Th/s [2015-03-28 20:14:32] Submitting share 004bfbe4 to pool 0 [2015-03-28 20:14:32] Accepted 4bfbe476 Diff 862/693 BTM 0 pool 0 [2015-03-28 20:14:37] (5s):1.348T (1m):752.3G (5m):641.3G (15m):379.9G (avg):1.128Th/s [2015-03-28 20:14:37] Submitting share 002bbf14 to pool 0 [2015-03-28 20:14:37] Accepted 2bbf14b4 Diff 1.5K/693 BTM 0 pool 0 [2015-03-28 20:14:37] Submitting share 0022698b to pool 0 [2015-03-28 20:14:37] Accepted 22698bb1 Diff 1.9K/693 BTM 0 pool 0 [2015-03-28 20:14:38] BTM 0: Share above target [2015-03-28 20:14:38] Submitting share 005b0202 to pool 0 [2015-03-28 20:14:38] Accepted 5b0202ef Diff 720/693 BTM 0 pool 0 [2015-03-28 20:14:39] BTM 0: Share above target [2015-03-28 20:14:41] BTM 0: Share above target [2015-03-28 20:14:42] Submitting share 004065d4 to pool 0 [2015-03-28 20:14:42] Accepted 4065d40a Diff 1.02K/693 BTM 0 pool 0 [2015-03-28 20:14:42] (5s):1.380T (1m):760.7G (5m):643.3G (15m):380.8G (avg):1.129Th/s [2015-03-28 20:14:44] Submitting share 000f245c to pool 0 [2015-03-28 20:14:44] Accepted 0f245c1b Diff 4.33K/693 BTM 0 pool 0 [2015-03-28 20:14:44] Submitting share 001b406e to pool 0 [2015-03-28 20:14:44] Accepted 1b406edc Diff 2.4K/693 BTM 0 pool 0 [2015-03-28 20:14:45] BTM 0: Share above target [2015-03-28 20:14:45] Submitting share 00172458 to pool 0 [2015-03-28 20:14:45] Accepted 1724589d Diff 2.83K/693 BTM 0 pool 0 [2015-03-28 20:14:46] Submitting share 001d53b0 to pool 0 [2015-03-28 20:14:46] Accepted 1d53b0d9 Diff 2.23K/693 BTM 0 pool 0 [2015-03-28 20:14:46] Submitting share 000c9a25 to pool 0 [2015-03-28 20:14:46] Accepted 0c9a2573 Diff 5.2K/693 BTM 0 pool 0 [2015-03-28 20:14:47] BitMain RxStatus Token: v(0) chip_status_eft(0) detect_get(0) chip_address(00) reg_address(00) crc(ef82) [2015-03-28 20:14:47] BitMain RxStatus tmp :0x01 byte4 0x00 chip_value_eft 0 reserved 0 get_blk_num 0 [2015-03-28 20:14:47] bitmain_parse_results v=0 chain=2 fifo=364 hwv1=3 hwv2=4 hwv3=3 hwv4=0 nerr=1-1 freq=350 chain info: [2015-03-28 20:14:47] bitmain_parse_results chain(0) asic_num=30 asic_status=oooooooo oooooooo oooooooo oooooo [2015-03-28 20:14:47] bitmain_parse_results chain(1) asic_num=30 asic_status=oooooooo oooooooo oooooooo oooooo [2015-03-28 20:14:47] BitMain: Fan1: 3600/m, Fan2: 0/m, Fan3: 0/m, Fan4: 0/m Temp1: 46C, Temp2: 52C, TempMAX: 52C [2015-03-28 20:14:47] BTM 0: Share above target [2015-03-28 20:14:47] (5s):1.393T (1m):783.5G (5m):648.2G (15m):382.7G (avg):1.130Th/s [2015-03-28 20:14:47] Pool 0 difficulty changed to 692.5 [2015-03-28 20:14:47] Stratum from pool 0 requested work restart [2015-03-28 20:14:47] Work update message received [2015-03-28 20:14:47] bitmain_flush_work queued=0 array=4696

TheAnalogKid

sr. member

Activity: 322

Merit: 250

Quote from: Songminer on March 26, 2015, 01:37:28 PM

Quote from: TheAnalogKid on March 26, 2015, 01:02:15 PM

Quote from: jonnybravo0311 on March 26, 2015, 10:45:13 AM

To put it simply, the larger the hash rate of the pool, the more difficult it becomes to find a share and get it on the chain for payout. It's precisely the opposite problem of your more traditional pool. The higher the difficulty, the more variance experienced by the smaller miner, which discourages smaller miners from mining here.

What he said.

A few months back when the pool was around 2PH the share difficulty for P2Pool rose to the point where more often than not if you were mining with less than the equivalent of an S1 (200GH/s) you wouldn't lodge a share within 1 day, which would mean all your effort for the day would end up not counting and you were essentially mining for nothing, and you wouldn't receive any credit towards the block rewards.

In addition, a single large miner could in effect swamp out all smaller miners on the node, because the larger miners would raise the share difficulty which was appropriate for the larger miner, but not good for the smaller miners. If the larger miner was not considerate or couldn't break up the hashrate into smaller chunks, it was bad for the rest of the miners on the node.

The higher the pool hashrate, the higher the share difficulty, the harder it is for small miners to solve shares and they lose out. Eventually you're talking about even an S3 not making any shares on the chain in time, which at this point there's still a ton of them deployed.

Is it as simple as sub-dividing the shares and/or reducing the time between shares? In concept, of course.

Unfortunately I don't believe it's that simple. I'm no developer, but from my understanding it's quite an involved issue within the code and not easily fixed. Hence the reason it's sat for so long like this... I'm sure there's capable devs who would have done it if it were not too involved already.

Songminer

member

Activity: 76

Merit: 10

Quote from: TheAnalogKid on March 26, 2015, 01:02:15 PM

Quote from: jonnybravo0311 on March 26, 2015, 10:45:13 AM

To put it simply, the larger the hash rate of the pool, the more difficult it becomes to find a share and get it on the chain for payout. It's precisely the opposite problem of your more traditional pool. The higher the difficulty, the more variance experienced by the smaller miner, which discourages smaller miners from mining here.

What he said.

A few months back when the pool was around 2PH the share difficulty for P2Pool rose to the point where more often than not if you were mining with less than the equivalent of an S1 (200GH/s) you wouldn't lodge a share within 1 day, which would mean all your effort for the day would end up not counting and you were essentially mining for nothing, and you wouldn't receive any credit towards the block rewards.

In addition, a single large miner could in effect swamp out all smaller miners on the node, because the larger miners would raise the share difficulty which was appropriate for the larger miner, but not good for the smaller miners. If the larger miner was not considerate or couldn't break up the hashrate into smaller chunks, it was bad for the rest of the miners on the node.

The higher the pool hashrate, the higher the share difficulty, the harder it is for small miners to solve shares and they lose out. Eventually you're talking about even an S3 not making any shares on the chain in time, which at this point there's still a ton of them deployed.

Is it as simple as sub-dividing the shares and/or reducing the time between shares? In concept, of course.

TheAnalogKid

sr. member

Activity: 322

Merit: 250

Quote from: jonnybravo0311 on March 26, 2015, 10:45:13 AM

To put it simply, the larger the hash rate of the pool, the more difficult it becomes to find a share and get it on the chain for payout. It's precisely the opposite problem of your more traditional pool. The higher the difficulty, the more variance experienced by the smaller miner, which discourages smaller miners from mining here.

What he said.

A few months back when the pool was around 2PH the share difficulty for P2Pool rose to the point where more often than not if you were mining with less than the equivalent of an S1 (200GH/s) you wouldn't lodge a share within 1 day, which would mean all your effort for the day would end up not counting and you were essentially mining for nothing, and you wouldn't receive any credit towards the block rewards.

In addition, a single large miner could in effect swamp out all smaller miners on the node, because the larger miners would raise the share difficulty which was appropriate for the larger miner, but not good for the smaller miners. If the larger miner was not considerate or couldn't break up the hashrate into smaller chunks, it was bad for the rest of the miners on the node.

The higher the pool hashrate, the higher the share difficulty, the harder it is for small miners to solve shares and they lose out. Eventually you're talking about even an S3 not making any shares on the chain in time, which at this point there's still a ton of them deployed.

jonnybravo0311

legendary

Activity: 1344

Merit: 1024

Mine at Jonny's Pool

Quote from: Songminer on March 26, 2015, 10:35:24 AM

Quote from: IYFTech on March 25, 2015, 12:47:10 PM

Quote from: windpath on March 25, 2015, 11:13:35 AM

Quote from: IYFTech on March 25, 2015, 10:41:46 AM

Holy moly - 3.5PH Huh

Far too much hash, diff through the roof - sorry guys, I'm off. I'll pop back when it's dropped again Sad

I'd like to see us around 4PH/s, 1% of network... Keep variance tolerable.

Well, it was ~4PH for most of November last year & it didn't help then. Nothing has changed since then apart from the higher diff, so I can't see 4PH making any difference now either. Same old story I guess...... Tongue

I'm trying to understand what is wrong with the code. What problems occur when the Hash rises. Would the pool not be doing ok at 3-4 PH/s? Wouldn't it not average a block per day, at that rate? And if so, would smaller miners be disadvantaged?

What needs to change in the code?

To put it simply, the larger the hash rate of the pool, the more difficult it becomes to find a share and get it on the chain for payout. It's precisely the opposite problem of your more traditional pool. The higher the difficulty, the more variance experienced by the smaller miner, which discourages smaller miners from mining here.

Songminer

member

Activity: 76

Merit: 10

Quote from: IYFTech on March 25, 2015, 12:47:10 PM

Quote from: windpath on March 25, 2015, 11:13:35 AM

Quote from: IYFTech on March 25, 2015, 10:41:46 AM

Holy moly - 3.5PH Huh

Far too much hash, diff through the roof - sorry guys, I'm off. I'll pop back when it's dropped again Sad

I'd like to see us around 4PH/s, 1% of network... Keep variance tolerable.

Well, it was ~4PH for most of November last year & it didn't help then. Nothing has changed since then apart from the higher diff, so I can't see 4PH making any difference now either. Same old story I guess...... Tongue

I'm trying to understand what is wrong with the code. What problems occur when the Hash rises. Would the pool not be doing ok at 3-4 PH/s? Wouldn't it not average a block per day, at that rate? And if so, would smaller miners be disadvantaged?

What needs to change in the code?

IYFTech

hero member

Activity: 686

Merit: 500

WANTED: Active dev to fix & re-write p2pool in C

Quote from: windpath on March 25, 2015, 11:13:35 AM

Quote from: IYFTech on March 25, 2015, 10:41:46 AM

Holy moly - 3.5PH Huh

Far too much hash, diff through the roof - sorry guys, I'm off. I'll pop back when it's dropped again Sad

I'd like to see us around 4PH/s, 1% of network... Keep variance tolerable.

Well, it was ~4PH for most of November last year & it didn't help then. Nothing has changed since then apart from the higher diff, so I can't see 4PH making any difference now either. Same old story I guess...... Tongue

windpath

legendary

Activity: 1258

Merit: 1027