.I'm only a small miner but I think many people think the same way.
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 662. (Read 2591920 times)
The only thing stopping me from mining on p2pool (except of some testing) is the constant bad luck. If that's solved and the 90 days luck factor keeps swinging around 100%, I'd love to switch to p2pool as p2pool basically is quite awesome .
I'm only a small miner but I think many people think the same way.
.I'm only a small miner but I think many people think the same way.
Now that our 90 day luck is above 100% (knock on wood), I propose we go on a p2pool membership drive.
I'd be willing to donate some coins through the pool in say 30 days if we could reach some sort of goal (increased # users? 500 GH/s?). I can't really decide on how the goal should be framed though, since it would be easy for a big miner to just split his hashing power across different addresses to simulate more users.
What do people think?
I'd be willing to donate some coins through the pool in say 30 days if we could reach some sort of goal (increased # users? 500 GH/s?). I can't really decide on how the goal should be framed though, since it would be easy for a big miner to just split his hashing power across different addresses to simulate more users.
What do people think?
I'm trying to start a conspiracy that doesn't involve Zhou Tong, could you at least understand even if you don't unignore me.
I have had an annoying hardware failure of one of the machines that provides data for p2pool.info behind the scenes. Until I can rebuild this machine, it means p2pool.info may be intermittently out of action or inaccurate.
Your not the only one to have a hardware failure related to p2pool.My hardware issue had nothing to do with p2pool. The motherboard and/or CPU of the host machine for my home web server's VM died. I haven't bothered to diagnose which failed--I just built a new host computer and moved the VM there.
This was a Windows Server 2008 R2 virtual machine that runs the web server and SQL server I use at home for managing my farm of mining rigs. It was also a convenient machine to run my internal caching DNS server on which meant when it died, none of my computers could resolve hostnames anymore. That is why p2pool.info was slightly affected (my p2pool nodes could not communicate to p2pool.info to send it data because they couldn't resolve the hostname). Neither p2pool nor bitcoin were running on this machine and could not have been associated with the hardware failure, so you'll have to look elsewhere for your conspiracy theories.
The fact that p2pool.info is experiencing an issue, makes it difficult to prove how profitable p2pool is compared to other pools. How convenient.
I knew there was a reason I ignored you. I should have trusted my instinct and not unignored you to see what you were asking. Fixed.
JayCoin --Attacker formatted HDD and stole ⊅ from his p2pool subpool.
That's not a hardware failure. 
I have had an annoying hardware failure of one of the machines that provides data for p2pool.info behind the scenes. Until I can rebuild this machine, it means p2pool.info may be intermittently out of action or inaccurate.
Your not the only one to have a hardware failure related to p2pool.Bitpop --Had a motherboard problem.
twmz --What was your issue?
JayCoin --Attacker formatted HDD and stole ⊅ from his p2pool subpool.
check_status (me) --Was connected to Jaycoins pool, after the attack my motherboard wouldn't POST with the HDD connected. Removed the HDD and the motherboard POSTs fine.
The fact that p2pool.info is experiencing an issue, makes it difficult to prove how profitable p2pool is compared to other pools. How convenient.
I have had an annoying hardware failure of one of the machines that provides data for p2pool.info behind the scenes. Until I can rebuild this machine, it means p2pool.info may be intermittently out of action or inaccurate.
It's fixed.
And no comment...
blocks solved by:
1PoNvnRhbvFE4xebEXjcVWfA3f2CGQkrCw
1MUfvW9osTXZgZdVSXyHSj7E4gousvnDyF
1PoNvnRhbvFE4xebEXjcVWfA3f2CGQkrCw (yes, two)
12AEGVu3PNJ37fVbMBnhL6mCv1YmTjF74z
huzzah
And 30days finally reach 100% 1PoNvnRhbvFE4xebEXjcVWfA3f2CGQkrCw
1MUfvW9osTXZgZdVSXyHSj7E4gousvnDyF
1PoNvnRhbvFE4xebEXjcVWfA3f2CGQkrCw (yes, two)
12AEGVu3PNJ37fVbMBnhL6mCv1YmTjF74z
huzzah
blocks solved by:
1PoNvnRhbvFE4xebEXjcVWfA3f2CGQkrCw
1MUfvW9osTXZgZdVSXyHSj7E4gousvnDyF
1PoNvnRhbvFE4xebEXjcVWfA3f2CGQkrCw (yes, two)
12AEGVu3PNJ37fVbMBnhL6mCv1YmTjF74z
huzzah
1PoNvnRhbvFE4xebEXjcVWfA3f2CGQkrCw
1MUfvW9osTXZgZdVSXyHSj7E4gousvnDyF
1PoNvnRhbvFE4xebEXjcVWfA3f2CGQkrCw (yes, two)
12AEGVu3PNJ37fVbMBnhL6mCv1YmTjF74z
huzzah
I have had an annoying hardware failure of one of the machines that provides data for p2pool.info behind the scenes. Until I can rebuild this machine, it means p2pool.info may be intermittently out of action or inaccurate.
Since it's the second time I've seen it and both times it occurred directly after a peer joined, I was thinking something along the lines of the peer passing along 'wrong' information. I don't think it was a deliberate attack, though.... since I imagine if that were to be the case, it'd happen far more often (twice in about 2 weeks so far for me -- I've got another screenshot posted farther up this thread, I believe).
I'm 99% sure it doesn't have to do with the # of connections, since at the time I was running with maxconn 900 in bitcoind, and I've had that up to >1000 before.
found it (was posted in the other p2pool thread): https://bitcointalk.org/index.php?topic=66182.msg992288#msg992288
both times after a peer disconnected then it (or a different one) connected shortly after
although I suppose someone could eventually find out how to 'make' it occur deliberately
I'm 99% sure it doesn't have to do with the # of connections, since at the time I was running with maxconn 900 in bitcoind, and I've had that up to >1000 before.
found it (was posted in the other p2pool thread): https://bitcointalk.org/index.php?topic=66182.msg992288#msg992288
both times after a peer disconnected then it (or a different one) connected shortly after
Quote
p2pool bug or attack?
i'm thinking bug, since like up above, i'd think it'd occur more often if it was deliberatealthough I suppose someone could eventually find out how to 'make' it occur deliberately
Aren't there only 2 reasons why a peer would pass the 'wrong' info? A bug, or an attack?
I have 3 miners. Why when it happens does it only affect one miner? And why wouldn't restarting that miner fix it, instead I have to restart p2pool?
Very perplexing.
M
i encountered the bizarre issue with all the DOA shares again after a peer joined:
I've observed this twice now as well, but I never figured out that it was related to a peer joining.
The first time, it caused one my cgminer instances to go beserk and submit endless stales.
Last time, just this morning, my phoenix instance did it.
Like you, restarting the miners and p2pool fixed it.
p2pool bug or attack?
M
I'm 99% sure it doesn't have to do with the # of connections, since at the time I was running with maxconn 900 in bitcoind, and I've had that up to >1000 before.
found it (was posted in the other p2pool thread): https://bitcointalk.org/index.php?topic=66182.msg992288#msg992288
both times after a peer disconnected then it (or a different one) connected shortly after
Quote
p2pool bug or attack?
i'm thinking bug, since like up above, i'd think it'd occur more often if it was deliberatealthough I suppose someone could eventually find out how to 'make' it occur deliberately
Limit connections to 30 or 20:
--max-conns 30
But there were about only 20 connections on his chart (10 outgoing and 10 incoming).--max-conns 30
It's got to be something else.
Limit connections to 30 or 20:
--max-conns 30
But there were about only 20 connections on his chart (10 outgoing and 10 incoming).--max-conns 30
It's got to be something else.
i encountered the bizarre issue with all the DOA shares again after a peer joined:
I've observed this twice now as well, but I never figured out that it was related to a peer joining.
The first time, it caused one my cgminer instances to go beserk and submit endless stales.
Last time, just this morning, my phoenix instance did it.
Like you, restarting the miners and p2pool fixed it.
p2pool bug or attack?
M
Limit connections to 30 or 20:
--max-conns 30
--max-conns 30
i encountered the bizarre issue with all the DOA shares again after a peer joined:
any clues? exact same thing that happened last time. closed + reopened and it fixed it.
any clues? exact same thing that happened last time. closed + reopened and it fixed it.
If one of the stats guys ... organofcorti? ... wants to actually work out the expected % and given confidence levels (say 99%, 99.9% or even 99.99%) accurately (and provide an equation) then we could see how reasonable what I suggest is
But your figures of a variance of over ~75% and ~35% for 24 hours at 200MH/s seem rather ... unlikely ... to be share variance
(since they are diff 1 shares)
... wants to actually work out the expected % and given confidence levels (say 99%, 99.9% or even 99.99%) accurately (and provide an equation) then we could see how reasonable what I suggest is But your figures of a variance of over ~75% and ~35% for 24 hours at 200MH/s seem rather ... unlikely ... to be share variance
(since they are diff 1 shares)
Just a quick response, and I could be wrong, but it seems to me that the number of shares accepted in a given time period is best described as a Poisson distributed variable.
At 200 Mhps, we expect to find the following number of shares:
D400 shares = 200 * 1e06 / 2^32 / 400 *3600 * 24 ~ 10
D400 shares = 200 * 1e06 / 2^32 / 400 *3600 * 24 ~ 6.7
So to find the probability 95% confidence intervals for the local hashrate (as calculated using R):
Code:
> qpois(0.025,6.7)*600*2^32/3600/24/1e06
[1] 59.65232
> qpois(0.925,6.7)*600*2^32/3600/24/1e06
[1] 328.0878
> qpois(0.025,10)*400*2^32/3600/24/1e06
[1] 79.53643
> qpois(0.925,10)*400*2^32/3600/24/1e06
[1] 298.2616
>
[1] 59.65232
> qpois(0.925,6.7)*600*2^32/3600/24/1e06
[1] 328.0878
> qpois(0.025,10)*400*2^32/3600/24/1e06
[1] 79.53643
> qpois(0.925,10)*400*2^32/3600/24/1e06
[1] 298.2616
>
So at D400, you'd expect to see a local hashrate between 59 and 328 Mhps with 95% confidence, and at D600 you'd expect to see a local hashrate between 79 and 298 Mhps. The standard deviation is about 63 Mhps at D400 and 77 Mhps at D600, with a mean and median of 200 Mhps.
There's much more variance than you might expect as you increase local D significantly compared to hashrate. The standard deviation varies with the square root of the mean submitted shares per day,so the higher the D, the lower the hashrate and the larger the square root of the hashrate (standard deviation) becomes closer to the mean.
tl;dr: The lower the local hashrate is for a given D, the larger the variability in local hashrate you'll see reported by the pool.
...
There's a huge variance involved when estimating your hashrate based on the number of p2pool shares you've produced in the last 24hrs. Yesterday my hashrate based on p2pool share production was 350mhs and today it's 129mh/s for a 5770 that cgminer says is averaging 200mh/s, I wouldn't rely on speed estimates based on p2pool share production unless it's over the last week or something. Also just looking at your stats page it says you have no incoming connections, you need to forward the p2pool port on your router to reduce stales.
Acutally, I've never seen it 'that' huge on any rig.There's a huge variance involved when estimating your hashrate based on the number of p2pool shares you've produced in the last 24hrs. Yesterday my hashrate based on p2pool share production was 350mhs and today it's 129mh/s for a 5770 that cgminer says is averaging 200mh/s, I wouldn't rely on speed estimates based on p2pool share production unless it's over the last week or something. Also just looking at your stats page it says you have no incoming connections, you need to forward the p2pool port on your router to reduce stales.
As I usually say regarding cgminer, given an hour and about 400-800 MH/s, you should be within about 10%
(I think I've only once ever seen close to 10% after an hour)
If one of the stats guys ... organofcorti?
... wants to actually work out the expected % and given confidence levels (say 99%, 99.9% or even 99.99%) accurately (and provide an equation) then we could see how reasonable what I suggest is But your figures of a variance of over ~75% and ~35% for 24 hours at 200MH/s seem rather ... unlikely ... to be share variance
(since they are diff 1 shares)
p2pool shares aren't diff 1 shares they're around 400-600.
I think the term used is psedo-shares.
"Local rate" is calculated form diff1 shares
"Local rate reflected in shares" is calculated from share chain shares
Miner is showing actual GPU rate.
There CAN be difference, all depends on LUCK.
If UR lucky you can have many diff1 shares and very few pool shares
If UR VERY lucky you will have lots of pool shares and calculated rate will be higher than real rate.
If UR really unlucky you will not have any share in 24hrs and get 0 btc each block
"Local rate reflected in shares" is calculated from share chain shares
Miner is showing actual GPU rate.
There CAN be difference, all depends on LUCK.
If UR lucky you can have many diff1 shares and very few pool shares
If UR VERY lucky you will have lots of pool shares and calculated rate will be higher than real rate.
If UR really unlucky you will not have any share in 24hrs and get 0 btc each block
Jump to: