Bitcoin Forum
August 19, 2019, 01:14:53 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 [292] 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 ... 814 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2582231 times)
gyverlb
Hero Member
*****
Offline Offline

Activity: 896
Merit: 1000



View Profile
June 23, 2013, 08:29:06 PM
 #5821

I'm seeing only 84% efficiency with mine. What settings are you using? My miner name has +256 appended to it. A poster in the BFL forums is using /6000 and is getting results more like yours than mine. Given that share difficulty is only 1080 as I write this, though, wouldn't setting difficulty too high risk throwing out valid shares?

What would be a good input to have to guess how good these ASICs are would be people comparing what their efficiency was with low-latency mining devices (GPUs/Icarus/Cairnsmore1/Ztex/...) and what is their efficiency with their BFL ASIC without any p2pool node reconfiguration.
If they have a mixed setup, knowing the total hashrate of the low-latency devices and the total hashrate of the BFL ASICs can do too.

Warning: don't use different payout addresses on your node: it currently adds latency in the P2Pool process and would lower efficiency.

Currently they don't seem horrible: 84% efficiency is the worst I'm aware of. It's bad but not far from what is good enough to make it almost as good as most pools (I consider the 90-95% range to be where P2Pool starts to be the best solution for mining).
Try to tune your setup according to my guide to see if you can reach a better efficiency (see my sig).

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
1566220493
Hero Member
*
Offline Offline

Posts: 1566220493

View Profile Personal Message (Offline)

Ignore
1566220493
Reply with quote  #2

1566220493
Report to moderator
1566220493
Hero Member
*
Offline Offline

Posts: 1566220493

View Profile Personal Message (Offline)

Ignore
1566220493
Reply with quote  #2

1566220493
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1566220493
Hero Member
*
Offline Offline

Posts: 1566220493

View Profile Personal Message (Offline)

Ignore
1566220493
Reply with quote  #2

1566220493
Report to moderator
1566220493
Hero Member
*
Offline Offline

Posts: 1566220493

View Profile Personal Message (Offline)

Ignore
1566220493
Reply with quote  #2

1566220493
Report to moderator
zvs
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


House Nogleg


View Profile WWW
June 23, 2013, 08:34:58 PM
 #5822

I'm seeing only 84% efficiency with mine. What settings are you using? My miner name has +256 appended to it. A poster in the BFL forums is using /6000 and is getting results more like yours than mine. Given that share difficulty is only 1080 as I write this, though, wouldn't setting difficulty too high risk throwing out valid shares?

What would be a good input to have to guess how good these ASICs are would be people comparing what their efficiency was with low-latency mining devices (GPUs/Icarus/Cairnsmore1/Ztex/...) and what is their efficiency with their BFL ASIC without any p2pool node reconfiguration.
If they have a mixed setup, knowing the total hashrate of the low-latency devices and the total hashrate of the BFL ASICs can do too.

Warning: don't use different payout addresses on your node: it currently adds latency in the P2Pool process and would lower efficiency.

Currently they don't seem horrible: 84% efficiency is the worst I'm aware of. It's bad but not far from what is good enough to make it almost as good as most pools (I consider the 90-95% range to be where P2Pool starts to be the best solution for mining).
Try to tune your setup according to my guide to see if you can reach a better efficiency (see my sig).

Isn't all that's required the base latency of the jalapeno?  How do they work?  Does it do work for 2s then spit out results?  1s?  1000ms should result in 10% DOA.

The orphans shouldnt deviate from what you'd get from using a GPU

zvs
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


House Nogleg


View Profile WWW
June 23, 2013, 08:36:45 PM
 #5823

OK, so I've been looking at my orphans for the last 10 days or so.... about 33% of them occur after a block solve.

i guess i should also mention that 50% of them are orphaned by

1CTgYxMTY5j6SLytKeMsBWAXuUc6yNKcAe

and i know he isnt using an asic, so why so slow?

How do you know it was that address, and is it wrong to assume that you have his ip address? If so ban him don't send any more work his way. Not that it matters but that address has a huge balance by the way...

nah, he's a major contributor to p2pool.  i think he's been mining it for years.   i'm just whining and wish he had a faster setup.  =p

I don't even know what IP he mines to, which I guess is part of the problem.  I think he's on a private node, probably with just 6 outgoing connections.

oh, I know it was that address since my orphan showed up in the 'headers' list... then I go to the parent share and click on child, and it shows what replaced your orphaned share (if it works the way I think it does, that replacement is actually dictated by the share that comes after it)

baloo_kiev
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250


View Profile
June 23, 2013, 08:48:08 PM
 #5824

Been testing my upgraded Jally on p2pool after the reports that BFL asics seemed to be doing OK. After around 18 hours, I'm seeing this:



Efficiency seems OK? DOA is high though, should I be worried about that? Guess I will let it run a few more days and see how payouts go once we start actually solving some blocks.

I'm seeing only 84% efficiency with mine. What settings are you using? My miner name has +256 appended to it. A poster in the BFL forums is using /6000 and is getting results more like yours than mine. Given that share difficulty is only 1080 as I write this, though, wouldn't setting difficulty too high risk throwing out valid shares?

To little data to make judgements. At 108 total shares stale+doa rate is (23.1 +- 11.Cool%. I mean that the real rate could be up to 34.9%, which gives efficiency of 83%. So to be sure, you need to wait to get more stats (several hundreds total shares).

PGP: 6EC48BA7
Welcome to my p2pool: BTC
gilamonsterz
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
June 23, 2013, 08:50:36 PM
 #5825

bahaha 5 days later, well done all
freshzive
Sr. Member
****
Offline Offline

Activity: 447
Merit: 250


View Profile
June 23, 2013, 08:51:50 PM
 #5826

Alright, I'll wait it out a few more days and check efficiency again.

On a more positive note: WE FOUND A BLOCK!!!! AT LAST!!!

gyverlb
Hero Member
*****
Offline Offline

Activity: 896
Merit: 1000



View Profile
June 23, 2013, 09:56:28 PM
 #5827

OK, so I've been looking at my orphans for the last 10 days or so.... about 33% of them occur after a block solve.

i guess i should also mention that 50% of them are orphaned by

1CTgYxMTY5j6SLytKeMsBWAXuUc6yNKcAe

and i know he isnt using an asic, so why so slow?

How do you know it was that address, and is it wrong to assume that you have his ip address? If so ban him don't send any more work his way. Not that it matters but that address has a huge balance by the way...

nah, he's a major contributor to p2pool.  i think he's been mining it for years.   i'm just whining and wish he had a faster setup.  =p

I can confirm that this address is mining since ages. The user behind may have changed his/her rigs since then but when the P2Pool mining started it was either GPU or FPGA based, seems the hashrate is fairly constant too: it always was around 50-60GH/s (computed from the payouts).

If he is reading this thread, he should definitely upgrade his setup: he's probably able to shave quite a few more bitcoins by lowering his bitcoind latency (which is probably the reason why his setup is orphaning zvs shares on occasion instead of building on top of them). This should help us too: he may have mined orphan blocks (not sure of the probabilities though).

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
GrapeApe
Sr. Member
****
Offline Offline

Activity: 477
Merit: 250



View Profile
June 23, 2013, 10:26:01 PM
Last edit: June 24, 2013, 12:26:26 AM by GrapeApe
 #5828

OK, so I've been looking at my orphans for the last 10 days or so.... about 33% of them occur after a block solve.

i guess i should also mention that 50% of them are orphaned by

1CTgYxMTY5j6SLytKeMsBWAXuUc6yNKcAe

and i know he isnt using an asic, so why so slow?

How do you know it was that address, and is it wrong to assume that you have his ip address? If so ban him don't send any more work his way. Not that it matters but that address has a huge balance by the way...

nah, he's a major contributor to p2pool.  i think he's been mining it for years.   i'm just whining and wish he had a faster setup.  =p

I can confirm that this address is mining since ages. The user behind may have changed his/her rigs since then but when the P2Pool mining started it was either GPU or FPGA based, seems the hashrate is fairly constant too: it always was around 50-60GH/s (computed from the payouts).

If he is reading this thread, he should definitely upgrade his setup: he's probably able to shave quite a few more bitcoins by lowering his bitcoind latency (which is probably the reason why his setup is orphaning zvs shares on occasion instead of building on top of them). This should help us too: he may have mined orphan blocks (not sure of the probabilities though).

I didn’t mean to sound so cold about it....

On another note I’m happy to hear that some are mining their jals on here.  I am waiting on mine and want to stay here. I read that someone has raised the difficulty to 6000 on it.  As salfter asked earlier won't this risk  throwing out good work or is the point to just get the efficiency up regardless of what it throws out. Which brings up another question if jals are throwing out easier work and the efficiency is acceptable, isn't that good for lower hash rate miners?
forrestv
Hero Member
*****
Offline Offline

Activity: 516
Merit: 514


View Profile
June 24, 2013, 01:17:40 AM
 #5829

In the next couple days, I'm going to release a hard-forking change to P2Pool that will make the following changes:

Global changes
* Increase last transaction extranonce length from 4 bytes to 8 bytes, so full 4-byte Stratum workunits can be efficiently generated (which will prevent the need for the avalon branch)
* Delay payout calculation 1 share so that payouts can be calculated ahead of time, reducing latency between a new share being received and work being distributed to miners
* Option to set a "dust target," which increases your share difficulty so that you don't get payouts below that target

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Litecoin network
* Decrease SPREAD (number of blocks a share's payout is spread over, on average) from 12 blocks to 3 blocks, significantly decreasing the dust payouts generated for miners who get a share less often than every 3 blocks the pool finds

Warnings will be spammed to miners (UPGRADE REQUIRED) once 50% of each P2Pool's mining power has upgraded and the changes will take effect 12 hours after 95% of the mining power has been upgraded, as usual.

If anyone has any recommendations for additional changes or comments on these, please respond.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
daemondazz
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
June 24, 2013, 01:42:29 AM
 #5830

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Will this increase the sharechain from 1 day to 3 days?

Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
forrestv
Hero Member
*****
Offline Offline

Activity: 516
Merit: 514


View Profile
June 24, 2013, 01:53:27 AM
 #5831

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Will this increase the sharechain from 1 day to 3 days?

I was planning on keeping it the same for now. The only disadvantage a long sharechain has is making P2Pool take a long time to start up and download shares, along with increased memory usage.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
Krellan
Member
**
Offline Offline

Activity: 106
Merit: 10


View Profile
June 24, 2013, 02:12:12 AM
 #5832

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Will this increase the sharechain from 1 day to 3 days?

I was planning on keeping it the same for now. The only disadvantage a long sharechain has is making P2Pool take a long time to start up and download shares, along with increased memory usage.

I'm rather happy with all the changes, except this one.  Going from 10 seconds/share to 30 seconds/share, but without also increasing the sharechain length, means that there will be much fewer paid shares per found block.

24 hours at 10 seconds each = 8640 shares.  At 30 seconds each = only 2880 shares.

I have a rather slow node (only one Eurupter, it does 320 MH/s), so I have to be pretty lucky to squeeze in my shares during the 24 hour window of opportunity, otherwise they expire unpaid.  When the block was found recently, my node was pretty far down on the list.  Under these new rules, I might not be on the list at all.

That takes away one of the big reasons to do shared pool mining: consistent and steady payouts over time, instead of having to play the lottery for a rare big payout.

Please reconsider?

Is there a problem now with the payout being spread too thin?  I didn't think there was.  If that is a problem, then there would be reason to reduce the shares per block.  Otherwise, since you're already doing a hard fork, now would also be a great time to also stretch the sharechain to 3 days, instead of 1 day, which would keep the number of paid shares per block the same.

Josh

1JUZr4TZ5zuB4WdEv4mrhZMaM7yttpJvLG Smiley
forrestv
Hero Member
*****
Offline Offline

Activity: 516
Merit: 514


View Profile
June 24, 2013, 02:14:40 AM
 #5833

I'm rather happy with all the changes, except this one.  Going from 10 seconds/share to 30 seconds/share, but without also increasing the sharechain length, means that there will be much fewer paid shares per found block.

24 hours at 10 seconds each = 8640 shares.  At 30 seconds each = only 2880 shares.

I have a rather slow node (only one Eurupter, it does 320 MH/s), so I have to be pretty lucky to squeeze in my shares during the 24 hour window of opportunity, otherwise they expire unpaid.  When the block was found recently, my node was pretty far down on the list.  Under these new rules, I might not be on the list at all.

That takes away one of the big reasons to do shared pool mining: consistent and steady payouts over time, instead of having to play the lottery for a rare big payout.

Please reconsider?

Is there a problem now with the payout being spread too thin?  I didn't think there was.  If that is a problem, then there would be reason to reduce the shares per block.  Otherwise, since you're already doing a hard fork, now would also be a great time to also stretch the sharechain to 3 days, instead of 1 day, which would keep the number of paid shares per block the same.

Sorry about the confusion and your time spent writing a long post - the sharechain length is set in terms of number of shares, not time, and I meant that the number of shares (8640) will remain the same, so you have nothing to worry about! The new sharechain will indeed be 3 days long.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
notme
Legendary
*
Offline Offline

Activity: 1904
Merit: 1001


View Profile
June 24, 2013, 02:38:05 AM
 #5834

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Will this increase the sharechain from 1 day to 3 days?

I was planning on keeping it the same for now. The only disadvantage a long sharechain has is making P2Pool take a long time to start up and download shares, along with increased memory usage.

I'm rather happy with all the changes, except this one.  Going from 10 seconds/share to 30 seconds/share, but without also increasing the sharechain length, means that there will be much fewer paid shares per found block.

24 hours at 10 seconds each = 8640 shares.  At 30 seconds each = only 2880 shares.

I have a rather slow node (only one Eurupter, it does 320 MH/s), so I have to be pretty lucky to squeeze in my shares during the 24 hour window of opportunity, otherwise they expire unpaid.  When the block was found recently, my node was pretty far down on the list.  Under these new rules, I might not be on the list at all.

That takes away one of the big reasons to do shared pool mining: consistent and steady payouts over time, instead of having to play the lottery for a rare big payout.

Please reconsider?

Is there a problem now with the payout being spread too thin?  I didn't think there was.  If that is a problem, then there would be reason to reduce the shares per block.  Otherwise, since you're already doing a hard fork, now would also be a great time to also stretch the sharechain to 3 days, instead of 1 day, which would keep the number of paid shares per block the same.

Josh


If you want to stay with p2pool, but desire lower variance perhaps you can consider one of the p2pool pooling options available in this thread: https://bitcointalk.org/index.php?topic=234841.0

The first option is a ruby based proxy which logs all pseudoshares and then redirects all shares to the same p2pool address.  As a miner all you have to do is change your pool address.  The other option is a python patch for p2pool that logs all pseudoshares.  You can then run the node with a 100% fee and split up the payments based on the logs.  Source code is available for both, but I'm not sure if there is a public pool for the patch option yet.  I run a server with the ruby proxy solution, but I welcome you to start your own pool with either codebase.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
freshzive
Sr. Member
****
Offline Offline

Activity: 447
Merit: 250


View Profile
June 24, 2013, 03:19:56 AM
 #5835

What determines your # of incoming connections? Just uptime? It seems like the longer I leave my node up, the more I get?

bitpop
Legendary
*
Offline Offline

Activity: 2520
Merit: 1045


https://keybase.io/bitpop


View Profile WWW
June 24, 2013, 03:22:43 AM
 #5836

Sweet can't wait to bring back my jalapeno!

Reputation  |  PGP  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
daemondazz
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
June 24, 2013, 05:34:23 AM
 #5837

@forrestv - have you considered adding a string to the coinbase to identify p2pool?

Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
yxxyun
Member
**
Offline Offline

Activity: 100
Merit: 10



View Profile
June 24, 2013, 06:06:30 AM
 #5838

@forrestv - have you considered adding a string to the coinbase to identify p2pool?
+1
wtogami
Sr. Member
****
Offline Offline

Activity: 263
Merit: 250



View Profile
June 24, 2013, 07:35:14 AM
 #5839

@forrestv - have you considered adding a string to the coinbase to identify p2pool?

There is no need.  It can be identified automatically by forrestv's payout txo.

If you appreciate my work please consider making a small donation.
BTC:  1LkYiL3RaouKXTUhGcE84XLece31JjnLc3      LTC:  LYtrtYZsVSn5ymhPepcJMo4HnBeeXXVKW9
GPG: AEC1884398647C47413C1C3FB1179EB7347DC10D
wtogami
Sr. Member
****
Offline Offline

Activity: 263
Merit: 250



View Profile
June 24, 2013, 03:16:39 PM
Last edit: June 24, 2013, 03:58:53 PM by wtogami
 #5840

Litecoin-0.6.9.1 now recommended for all LTC p2pool nodes.
You MUST follow directions and connect to a supernode

Important bug fixes, August 15th hardfork deadline, plus reduced fee!

https://forum.litecoin.net/index.php/topic,4615.0.html

The release for the general public on Litecoin.org is coming real soon.  You can help smooth the transition of the network to the lower fee by upgrading the entire p2pool LTC network to be capable of relaying newfee transactions.  Follow the directions and add two or three supernodes to your litecoin.conf.

If you appreciate my work please consider making a small donation.
BTC:  1LkYiL3RaouKXTUhGcE84XLece31JjnLc3      LTC:  LYtrtYZsVSn5ymhPepcJMo4HnBeeXXVKW9
GPG: AEC1884398647C47413C1C3FB1179EB7347DC10D
Pages: « 1 ... 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 [292] 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 ... 814 »
  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!