Bitcoin Forum
December 05, 2016, 08:46:53 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 [196] 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2029827 times)
kano
Legendary
*
Online Online

Activity: 1918


Linux since 1997 RedHat 4


View Profile
November 17, 2012, 05:31:52 AM
 #3901

So - how is the pool hash rate calculated?
It includes orphans and dead on arrival shares as they are seen by every node.
Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion)
So it doesn't include all the 1-diff shares generated by the miner ... ?

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480927613
Hero Member
*
Offline Offline

Posts: 1480927613

View Profile Personal Message (Offline)

Ignore
1480927613
Reply with quote  #2

1480927613
Report to moderator
1480927613
Hero Member
*
Offline Offline

Posts: 1480927613

View Profile Personal Message (Offline)

Ignore
1480927613
Reply with quote  #2

1480927613
Report to moderator
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
November 17, 2012, 05:59:24 AM
 #3902

So - how is the pool hash rate calculated?
It includes orphans and dead on arrival shares as they are seen by every node.
Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion)
So it doesn't include all the 1-diff shares generated by the miner ... ?

No... pool hash rate is only determined by actual shares, which is accurate enough.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
kano
Legendary
*
Online Online

Activity: 1918


Linux since 1997 RedHat 4


View Profile
November 17, 2012, 06:20:18 AM
 #3903

So - how is the pool hash rate calculated?
It includes orphans and dead on arrival shares as they are seen by every node.
Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion)
So it doesn't include all the 1-diff shares generated by the miner ... ?

No... pool hash rate is only determined by actual shares, which is accurate enough.
So back to my original statement then.
The pool hash rate reported is below the actual hash rate of the miners (like all pools)

However, since p2pool has 60x the number of LP's compared to other pools, the actual hash rate is quite a bit higher than reported - whereas with a normal pool it shouldn't be more than about 1% higher (I typically get <0.4% for GPU/BFL/ICA and ~0.7% for MMQ)

Yet in those ignored shares, if there is a valid Block, it will of course get through, so rather than the number of blocks being representative of the number of valid shares, it is in fact representative of the number of all work generated by all p2pool miners which is of course higher than the reported hash rate.

So when people are reporting that p2pool is getting 110% luck consistently (which of course isn't possible - the probability of getting 110% over even 1 month is excessively unlikely) they are in fact not comparing the correct numbers.
Yes p2pool may well now be averaging 100% as expected, but those > 100% numbers are the result of not comparing the correct numbers

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
November 17, 2012, 09:56:32 AM
 #3904

Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion)
Is it just a flag or a counter? We have whole network stats for DOA and Orphans too, are there 2 flags/counters?
With a counter the stale estimation should be pretty good. If it's a flag, multiple stales between shares would be miscounted as an unique stale.

What might be underestimated too is the amount of work from nodes which stop mining after stale shares.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
November 17, 2012, 10:37:25 AM
 #3905

So - how is the pool hash rate calculated?
It includes orphans and dead on arrival shares as they are seen by every node.
Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion)
So it doesn't include all the 1-diff shares generated by the miner ... ?

No... pool hash rate is only determined by actual shares, which is accurate enough.
So back to my original statement then.
The pool hash rate reported is below the actual hash rate of the miners (like all pools)

However, since p2pool has 60x the number of LP's compared to other pools, the actual hash rate is quite a bit higher than reported - whereas with a normal pool it shouldn't be more than about 1% higher (I typically get <0.4% for GPU/BFL/ICA and ~0.7% for MMQ)

Yet in those ignored shares, if there is a valid Block, it will of course get through, so rather than the number of blocks being representative of the number of valid shares, it is in fact representative of the number of all work generated by all p2pool miners which is of course higher than the reported hash rate.

So when people are reporting that p2pool is getting 110% luck consistently (which of course isn't possible - the probability of getting 110% over even 1 month is excessively unlikely) they are in fact not comparing the correct numbers.
Yes p2pool may well now be averaging 100% as expected, but those > 100% numbers are the result of not comparing the correct numbers
you can find a block with an orphaned share too!
think of it as: with a 1diff share being stale on a normal pool u still can get a block (in relation to p2pool)

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
November 17, 2012, 11:10:16 AM
 #3906

Yes our 90 day moving average is impressive and it is being used to sugar coat or slick over the issue we are trying to bring up. Just because our overall luck is good does not mean we don't have a scalability problem. When we get those bumps in hash speed, the person/s that jumped on board usually see that their payouts are low because of the bad luck during the period they hopped on and they leave. That drops us back down in hash rate back to where the supposed scalability issue is no longer in play.

So until we have a run of good luck in the 350+ GH range I and probably some others will still have doubts.

That's just ridiculous. Take a look at the last week. Hashrate has been climing to over 400 GH/s, and the 7-day average is still over 115%.

As you said... "has been climbing" So for part of the week we were below 350 GH. and 7 day average is now down to 110%

I'm done (as in, not gonna argue with you anymore), no one will take a serious look into the issue as long as people are sugar coating it with ... see look our overall luck is good. What I and others are saying is we are noticing that blocks are being solved by the pool less frequently when we are over a certain hash rate.

If you look at my posts, I used to be saying the same thing, except I was saying 300 GH was the magic number. 

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
cabin
Full Member
***
Offline Offline

Activity: 205


View Profile
November 17, 2012, 01:03:13 PM
 #3907

So - how is the pool hash rate calculated?
It includes orphans and dead on arrival shares as they are seen by every node.
Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion)
So it doesn't include all the 1-diff shares generated by the miner ... ?

No... pool hash rate is only determined by actual shares, which is accurate enough.
So back to my original statement then.
The pool hash rate reported is below the actual hash rate of the miners (like all pools)

However, since p2pool has 60x the number of LP's compared to other pools, the actual hash rate is quite a bit higher than reported - whereas with a normal pool it shouldn't be more than about 1% higher (I typically get <0.4% for GPU/BFL/ICA and ~0.7% for MMQ)

Yet in those ignored shares, if there is a valid Block, it will of course get through, so rather than the number of blocks being representative of the number of valid shares, it is in fact representative of the number of all work generated by all p2pool miners which is of course higher than the reported hash rate.

So when people are reporting that p2pool is getting 110% luck consistently (which of course isn't possible - the probability of getting 110% over even 1 month is excessively unlikely) they are in fact not comparing the correct numbers.
Yes p2pool may well now be averaging 100% as expected, but those > 100% numbers are the result of not comparing the correct numbers

One thing that might mitigate some of this is that p2pool does send a header that tells the miner to submit all work, even if it is considered dead right after a long poll. This work should show up in the number of DOA shares the pool reports. So we might be counting most of the hash rate that others pools miss right after a long poll.

Also +/- 10% over the course of a month will happen fairly regularly with a pool of this size.

1Cabinz1RSccAbFx2DikYomSKeMupy7M6V
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
November 17, 2012, 01:11:05 PM
 #3908

The correlation coefficient between hashrate per round and shares per round on D is 0.08. That means no significant correlation at all. Hashrate does not correlate with round length in a linear way. Plotting one against the other doesn't really show any pattern at all. It looks like a cloud of mosquitos.


Unfortunately the data only goes back to August - is there access to all rounds somewhere?

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
cabin
Full Member
***
Offline Offline

Activity: 205


View Profile
November 17, 2012, 02:58:04 PM
 #3909

The correlation coefficient between hashrate per round and shares per round on D is 0.08. That means no significant correlation at all. Hashrate does not correlate with round length in a linear way. Plotting one against the other doesn't really show any pattern at all. It looks like a cloud of mosquitos.


Unfortunately the data only goes back to August - is there access to all rounds somewhere?

This looks promising:
http://p2pool.info/blocks?from=0

1Cabinz1RSccAbFx2DikYomSKeMupy7M6V
twmz
Hero Member
*****
Offline Offline

Activity: 737



View Profile
November 17, 2012, 02:59:45 PM
 #3910

The correlation coefficient between hashrate per round and shares per round on D is 0.08. That means no significant correlation at all. Hashrate does not correlate with round length in a linear way. Plotting one against the other doesn't really show any pattern at all. It looks like a cloud of mosquitos.


Unfortunately the data only goes back to August - is there access to all rounds somewhere?

If you are getting them from my site, you have to add a querystring parameter to get all data since I changed the main page to only show 90 days worth to improve routine performance:

http://p2pool.info/blocks?all=true

Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
November 17, 2012, 04:25:25 PM
 #3911

So back to my original statement then.
The pool hash rate reported is below the actual hash rate of the miners (like all pools)

However, since p2pool has 60x the number of LP's compared to other pools, the actual hash rate is quite a bit higher than reported - whereas with a normal pool it shouldn't be more than about 1% higher (I typically get <0.4% for GPU/BFL/ICA and ~0.7% for MMQ)

Yet in those ignored shares, if there is a valid Block, it will of course get through, so rather than the number of blocks being representative of the number of valid shares, it is in fact representative of the number of all work generated by all p2pool miners which is of course higher than the reported hash rate.
Work done during that time is counted as DOA shares, as cabin said:
One thing that might mitigate some of this is that p2pool does send a header that tells the miner to submit all work, even if it is considered dead right after a long poll. This work should show up in the number of DOA shares the pool reports. So we might be counting most of the hash rate that others pools miss right after a long poll.


So when people are reporting that p2pool is getting 110% luck consistently (which of course isn't possible - the probability of getting 110% over even 1 month is excessively unlikely) they are in fact not comparing the correct numbers.
Yes p2pool may well now be averaging 100% as expected, but those > 100% numbers are the result of not comparing the correct numbers
No, the probability of us getting >110% luck for a given month is 21% (assuming we should get 2.3 blocks/day and a month has 30 days).
Code:
In[23]:= expected = 2.3*30;
In[24]:= 1 - CDF[PoissonDistribution[expected], expected*1.1] // N
Out[24]= 0.214626


Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion)
Is it just a flag or a counter? We have whole network stats for DOA and Orphans too, are there 2 flags/counters?
With a counter the stale estimation should be pretty good. If it's a flag, multiple stales between shares would be miscounted as an unique stale.

What might be underestimated too is the amount of work from nodes which stop mining after stale shares.
It's a flag, but P2Pool buffers the number of stale shares, setting the flag as many times as it needs to. Nodes leaving before getting a share with the flag set is a problem, yes, but I think it's a small one.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
November 17, 2012, 05:16:50 PM
 #3912

Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion)
Is it just a flag or a counter? We have whole network stats for DOA and Orphans too, are there 2 flags/counters?
With a counter the stale estimation should be pretty good. If it's a flag, multiple stales between shares would be miscounted as an unique stale.

What might be underestimated too is the amount of work from nodes which stop mining after stale shares.
Note that I don't think it's an actual problem. With around 9-10 GH/s, I've always seen above 100% PPS and I'm currently at around 115% PPS for the last active weeks (computed from my actual earnings vs actual hash power). It matches the :
- p2pool.info luck,
- my efficiency,
- the average tx fee percentage.
This is why I'm back mining on p2pool: hashpower promises at least 105% PPS when leasing and falls short due to high rejects, I compared my actual PPS over several weeks and stats are largely in favor of p2pool for me. I left p2pool because I had I/O issues and likes to test novelties, but now bitcoind and p2pool are both on SSDs and they are just flying (at least when I'm not rewiring the whole apartment...).

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
November 17, 2012, 05:34:24 PM
 #3913

Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion)
Is it just a flag or a counter? We have whole network stats for DOA and Orphans too, are there 2 flags/counters?
With a counter the stale estimation should be pretty good. If it's a flag, multiple stales between shares would be miscounted as an unique stale.

What might be underestimated too is the amount of work from nodes which stop mining after stale shares.
Note that I don't think it's an actual problem. With around 9-10 GH/s, I've always seen above 100% PPS and I'm currently at around 115% PPS for the last active weeks (computed from my actual earnings vs actual hash power). It matches the :
- p2pool.info luck,
- my efficiency,
- the average tx fee percentage.
This is why I'm back mining on p2pool: hashpower promises at least 105% PPS when leasing and falls short due to high rejects, I compared my actual PPS over several weeks and stats are largely in favor of p2pool for me. I left p2pool because I had I/O issues and likes to test novelties, but now bitcoind and p2pool are both on SSDs and they are just flying (at least when I'm not rewiring the whole apartment...).

My first SSD should be arriving soon.  I'm seriously hoping it decreases my stale rate - like you, I think it's I/O related.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
kano
Legendary
*
Online Online

Activity: 1918


Linux since 1997 RedHat 4


View Profile
November 18, 2012, 01:20:37 AM
 #3914

Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion)
Is it just a flag or a counter? We have whole network stats for DOA and Orphans too, are there 2 flags/counters?
With a counter the stale estimation should be pretty good. If it's a flag, multiple stales between shares would be miscounted as an unique stale.

What might be underestimated too is the amount of work from nodes which stop mining after stale shares.
Note that I don't think it's an actual problem. With around 9-10 GH/s, I've always seen above 100% PPS and I'm currently at around 115% PPS for the last active weeks (computed from my actual earnings vs actual hash power).
...
If you have always seen above 100% PPS then you are missing including something.

Block+Fees average is currently 100.36% according to blockchain.info

Thus you must be missing counting some work somewhere ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
lenny_
Legendary
*
Offline Offline

Activity: 953



View Profile
November 18, 2012, 01:46:39 AM
 #3915

Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion)
Is it just a flag or a counter? We have whole network stats for DOA and Orphans too, are there 2 flags/counters?
With a counter the stale estimation should be pretty good. If it's a flag, multiple stales between shares would be miscounted as an unique stale.

What might be underestimated too is the amount of work from nodes which stop mining after stale shares.
Note that I don't think it's an actual problem. With around 9-10 GH/s, I've always seen above 100% PPS and I'm currently at around 115% PPS for the last active weeks (computed from my actual earnings vs actual hash power). It matches the :
- p2pool.info luck,
- my efficiency,
- the average tx fee percentage.
This is why I'm back mining on p2pool: hashpower promises at least 105% PPS when leasing and falls short due to high rejects, I compared my actual PPS over several weeks and stats are largely in favor of p2pool for me. I left p2pool because I had I/O issues and likes to test novelties, but now bitcoind and p2pool are both on SSDs and they are just flying (at least when I'm not rewiring the whole apartment...).

My first SSD should be arriving soon.  I'm seriously hoping it decreases my stale rate - like you, I think it's I/O related.

M

Have you got latest bitcoind from git? It's much faster than stable version, with new database. With latest bitcoind from git my GetWork Latency dropped about 5-10x times.
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
November 18, 2012, 02:10:43 AM
 #3916

Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion)
Is it just a flag or a counter? We have whole network stats for DOA and Orphans too, are there 2 flags/counters?
With a counter the stale estimation should be pretty good. If it's a flag, multiple stales between shares would be miscounted as an unique stale.

What might be underestimated too is the amount of work from nodes which stop mining after stale shares.
Note that I don't think it's an actual problem. With around 9-10 GH/s, I've always seen above 100% PPS and I'm currently at around 115% PPS for the last active weeks (computed from my actual earnings vs actual hash power). It matches the :
- p2pool.info luck,
- my efficiency,
- the average tx fee percentage.
This is why I'm back mining on p2pool: hashpower promises at least 105% PPS when leasing and falls short due to high rejects, I compared my actual PPS over several weeks and stats are largely in favor of p2pool for me. I left p2pool because I had I/O issues and likes to test novelties, but now bitcoind and p2pool are both on SSDs and they are just flying (at least when I'm not rewiring the whole apartment...).

My first SSD should be arriving soon.  I'm seriously hoping it decreases my stale rate - like you, I think it's I/O related.

M

Have you got latest bitcoind from git? It's much faster than stable version, with new database. With latest bitcoind from git my GetWork Latency dropped about 5-10x times.

I'll try it on my server.  Sounds risky for my main wallet, but main wallet isn't used for mining.

Thanks!

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
lenny_
Legendary
*
Offline Offline

Activity: 953



View Profile
November 18, 2012, 09:16:46 AM
 #3917

Gyver, not quite. Share have a flag that indicates whether the node that generated it got a stale share in the past, and from those, nodes can compute the stale share percentage and then the total hash rate with an expression like: unstale_hash_rate / (1 - pool_stale_proportion)
Is it just a flag or a counter? We have whole network stats for DOA and Orphans too, are there 2 flags/counters?
With a counter the stale estimation should be pretty good. If it's a flag, multiple stales between shares would be miscounted as an unique stale.

What might be underestimated too is the amount of work from nodes which stop mining after stale shares.
Note that I don't think it's an actual problem. With around 9-10 GH/s, I've always seen above 100% PPS and I'm currently at around 115% PPS for the last active weeks (computed from my actual earnings vs actual hash power). It matches the :
- p2pool.info luck,
- my efficiency,
- the average tx fee percentage.
This is why I'm back mining on p2pool: hashpower promises at least 105% PPS when leasing and falls short due to high rejects, I compared my actual PPS over several weeks and stats are largely in favor of p2pool for me. I left p2pool because I had I/O issues and likes to test novelties, but now bitcoind and p2pool are both on SSDs and they are just flying (at least when I'm not rewiring the whole apartment...).

My first SSD should be arriving soon.  I'm seriously hoping it decreases my stale rate - like you, I think it's I/O related.

M

Have you got latest bitcoind from git? It's much faster than stable version, with new database. With latest bitcoind from git my GetWork Latency dropped about 5-10x times.

I'll try it on my server.  Sounds risky for my main wallet, but main wallet isn't used for mining.

Thanks!

M

That's are my results, on Intel Atom 230 1.6GHz HT + 1 GB RAM:

It was after switching from bitcoind 0.7.1 to newest from git Smiley
rav3n_pl
Legendary
*
Offline Offline

Activity: 1320


Don`t panic! Organize!


View Profile
November 18, 2012, 11:14:31 AM
 #3918

Remember to
Code:
strip bitcoind
Smiley

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
November 18, 2012, 01:03:42 PM
 #3919

In case you didn't see my post, I wrote a .Net "widget" for Windows that allows you to monitor your miners on p2pool, eclipse, ozcoin, and 50btc.  More pools are coming as time permits (bitminter is next).

https://bitcointalk.org/index.php?topic=86502.0

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
November 18, 2012, 10:36:42 PM
 #3920

If you have always seen above 100% PPS then you are missing including something.

Block+Fees average is currently 100.36% according to blockchain.info
Not sure which stat you are referring to (whole network over a period of time ?).

Anyway, my computations seem fine to me. That's not rocket science to compute expected income from one's hashrate and current difficulty and compare it to actual income over a large enough period (at least 4 weeks in my case). I have a whole spreadsheet dedicated to my mining activites and one sheet is dedicated to expected/actual mining income: I dutifully enter each mining related transaction and compute expected income for each day (with appropriate adjustments on the days difficulty changes).

If my results seems too good to you on p2pool, you miss one perfectly reasonable explanation. It could simply be luck the PPLNS system doesn't use 1-difficulty shares but far more difficult shares which introduce variance in your expected income (I've seen at least +/- 15%) for a block found. So I may just have been lucky when p2pool found blocks and unlucky when it didn't. But as I said my results are matching with my reported efficiency (between 102 and 106%, was mostly 105 and is around 104 recently), p2pool.info reported luck (~110%) and the 100.36% you report for block+fees (in fact I used 100.25%).

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
Pages: « 1 ... 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 [196] 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 ... 744 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!