Bitcoin Forum
August 14, 2020, 12:30:54 AM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 343 344 345 346 347 ... 814 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2587182 times)
bitpop
Legendary
*
Offline Offline

Activity: 2632
Merit: 1048


https://keybase.io/bitpop


View Profile WWW
June 30, 2013, 12:38:16 PM
 #5921

Can't wait for update to rejoin with baj

Reputation  |  PGP  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
1597365054
Hero Member
*
Offline Offline

Posts: 1597365054

View Profile Personal Message (Offline)

Ignore
1597365054
Reply with quote  #2

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

Activity: 454
Merit: 250


View Profile
June 30, 2013, 01:31:14 PM
 #5922

wow, the hashrate now is over 900Gh/s!

witout increase of DOA....

Whre comes it from 

BFL SCs?

@Kano: Did you ever retry p2pool after flashing your jally to firmware 1.2.5? There may be something in there that is enabling the reports that recently shipped BFL devices work on p2pool. Mine shipped, so next week I can try to do some real tests - play with different firmware revisions to try to confirm the problem and fix.
yxxyun
Member
**
Offline Offline

Activity: 100
Merit: 10



View Profile
June 30, 2013, 02:15:04 PM
 #5923

1NastyFRkeUTmMdbMmzggDVTQA6r3ibUoX  this guy has over 200Gh/s on p2pool Huh
xgtele
Sr. Member
****
Offline Offline

Activity: 288
Merit: 250



View Profile
June 30, 2013, 03:24:17 PM
 #5924

1NastyFRkeUTmMdbMmzggDVTQA6r3ibUoX  this guy has over 200Gh/s on p2pool Huh

Yeah, nasty things are coming  Cool
maqifrnswa
Sr. Member
****
Offline Offline

Activity: 454
Merit: 250


View Profile
June 30, 2013, 03:34:04 PM
 #5925

1NastyFRkeUTmMdbMmzggDVTQA6r3ibUoX  this guy has over 200Gh/s on p2pool Huh

Yeah, nasty things are coming  Cool

yeah, nasty  Wink
https://bitcointalk.org/index.php?topic=86854.0

5x BFL 60GH/s ASIC Miner
5x BFL BitForce Single FPGA
1x ASICminer USB Block Erupter
baloo_kiev
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250


View Profile
June 30, 2013, 08:37:28 PM
Last edit: June 30, 2013, 09:25:13 PM by baloo_kiev
 #5926

Brief report of p2pool + AM block eruptor blade investigation

1) Blade always works on difficulty 1, regardless of what server tells, so p2pool must always provide diff 1 pseudoshares to account solved work properly. This does not affect real shares difficulty, which can be tuned as usually.

2) Blade does not use long polling. Instead, it makes about 4 getwork requests per second. Looks like it makes as much requests as it can, each providing work to one chip. With 32 chips, it means about 8 seconds per full round. Maybe it doesn't send solutions before doing this full round; this must rersult in about 50% DOA. Or maybe results are put into queue and wait while software is busy requesting new work. In both cases, running it locally may help. Also, I'm not sure that real share DOA will be as high as pseudoshare DOA.

3) "p2pool + stratum proxy + AM blade" setup has some authorization-related issue. This is all I can tell by now, will try to get more details.

P.S. With the difficulty tweak, it works giving about 50% pseudoshare DOA. Real share efficiency is unknown because of little statistics. Those who have AM blades may give it a try at 78.27.191.182:8353 (with your payout address as username).

P.P.S. A question to any developers here. May I officially state that AM blade software is a piece of crap? No stratum, no long polling and constant difficulty in the year 2013. It might be OK for their internal mining but not for a sold product!

PGP: 6EC48BA7
Welcome to my p2pool: BTC
lenny_
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000


DARKNETMARKETS.COM


View Profile WWW
June 30, 2013, 10:32:13 PM
 #5927

Thank you very much forrestv and baloo_kiev for your efforts and development. I hope that these Blades will be finally working fine with p2pool soon. Smiley

DARKNET MARKETS >> https://DARKNETMARKETS.COM
-ck
Legendary
*
Offline Offline

Activity: 3192
Merit: 1353


Ruu \o/


View Profile WWW
June 30, 2013, 11:32:54 PM
 #5928

P.P.S. A question to any developers here. May I officially state that AM blade software is a piece of crap? No stratum, no long polling and constant difficulty in the year 2013. It might be OK for their internal mining but not for a sold product!
Yes you may say that and you won't get any argument from developers (we weren't remotely involved, engaged or asked).

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
baloo_kiev
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250


View Profile
July 01, 2013, 01:35:28 AM
Last edit: July 01, 2013, 01:45:49 AM by baloo_kiev
 #5929

Brief report of p2pool + AM block eruptor blade investigation

1) Blade always works on difficulty 1, regardless of what server tells, so p2pool must always provide diff 1 pseudoshares to account solved work properly. This does not affect real shares difficulty, which can be tuned as usually.

2) Blade does not use long polling. Instead, it makes about 4 getwork requests per second. Looks like it makes as much requests as it can, each providing work to one chip. With 32 chips, it means about 8 seconds per full round. Maybe it doesn't send solutions before doing this full round; this must rersult in about 50% DOA. Or maybe results are put into queue and wait while software is busy requesting new work. In both cases, running it locally may help. Also, I'm not sure that real share DOA will be as high as pseudoshare DOA.

3) "p2pool + stratum proxy + AM blade" setup has some authorization-related issue. This is all I can tell by now, will try to get more details.

P.S. With the difficulty tweak, it works giving about 50% pseudoshare DOA. Real share efficiency is unknown because of little statistics. Those who have AM blades may give it a try at 78.27.191.182:8353 (with your payout address as username).

P.P.S. A question to any developers here. May I officially state that AM blade software is a piece of crap? No stratum, no long polling and constant difficulty in the year 2013. It might be OK for their internal mining but not for a sold product!

Update!
At last, the blade's mining mechanism is clear to me. Like in AM USB, found solutions are reported immediately. However, unlike AM USB and like BFL devices, work is not restarted. This means that a chip keeps mining the same work for about 12 seconds (I guess it corresponds to full nonce range of 32 bit, and is equal to average chip's time per one diff1 share). Since solutions are reported immediately, this must give slightly less than 50% DOA shares.

There's a solution that can considerably increase mining efficiency on p2pool for ASIC devices, and this solution is... share difficulty. By setting it high you not only help small miners, but also protect yourself from orphan shares! If you are mining with x10 share difficulty, your "DOA" shares will most probably get into the chain, since your share's work is bigger than even 9 min diff shares. With current mindiff of 1500 and expected time to block of 30 hours, ASIC miners (except AM USB which works fine) can set their diff to 15000 without any serious increase of variance. Shares which are first reported DOA in p2pool node log may still get into the chain!

PGP: 6EC48BA7
Welcome to my p2pool: BTC
forrestv
Hero Member
*****
Offline Offline

Activity: 516
Merit: 514


View Profile
July 01, 2013, 01:40:26 AM
 #5930

There's a solution that can considerably increase mining efficiency on p2pool for ASIC devices, and this solution is... share difficulty. Setting it high you not only help small miners, but also protect yourself from orphan shares! If you are mining with x10 share difficulty, your "DOA" shares will most probably get into the chain, since your share's work is bigger than even 9 min diff shares. With current mindiff of 1500 and expected time to block of 30 hours, ASIC miners (except AM USB which works fine) can set their diff to 15000 without any serious increase of variance!

This actually doesn't do anything (thankfully). P2Pool uses the work of a share's 5th parent when sorting sharechain tips, which prevents attacks that would allow you to effectively orphan the tip share on command.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
bitpop
Legendary
*
Offline Offline

Activity: 2632
Merit: 1048


https://keybase.io/bitpop


View Profile WWW
July 01, 2013, 03:00:12 AM
 #5931

Why would they fix this only in the usb version?

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

Activity: 448
Merit: 250



View Profile
July 01, 2013, 04:14:20 AM
 #5932

The USB version doesn't run standalone.

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

Activity: 106
Merit: 10


View Profile
July 01, 2013, 06:01:14 AM
 #5933

* 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

Good idea to precalculate the blocks that will be worked on, to reduce latency.  However, curious how this works.  If blocks are now precalculated, delayed by 1 share, then where will the most recent winning share be stored in the sharechain?  I thought it worked now by each miner creating a new block containing their payout address, and trying to solve that, until finding a winning solution, at which point the block becomes a valid share in the sharechain.  If this isn't the case, then where will the payout addresses be stored now?  I hope this doesn't open up an opportunity for a miner to cheat.  Or, do I have it all wrong here?  Thanks!


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

Activity: 516
Merit: 514


View Profile
July 01, 2013, 06:03:37 AM
 #5934

* 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

Good idea to precalculate the blocks that will be worked on, to reduce latency.  However, curious how this works.  If blocks are now precalculated, delayed by 1 share, then where will the most recent winning share be stored in the sharechain?  I thought it worked now by each miner creating a new block containing their payout address, and trying to solve that, until finding a winning solution, at which point the block becomes a valid share in the sharechain.  If this isn't the case, then where will the payout addresses be stored now?  I hope this doesn't open up an opportunity for a miner to cheat.  Or, do I have it all wrong here?  Thanks!

The sharechain has some P2Pool-specific data (including the winner's payout address) within each share, along with everything needed to compute the current block being mined. So no, this is a very safe change.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
Krellan
Member
**
Offline Offline

Activity: 106
Merit: 10


View Profile
July 01, 2013, 06:30:08 AM
 #5935

I'm not sure how Erupter blades behave with P2Pool, please give us a quick report when your reach 25 total shares then 50 (the more you have the more we will know for sure how your setup behaves).

Up to 50 shares now!

Not exactly Nasty, but still chugging along nicely, for only a single Erupter.

I increased the number of outgoing connections to the maximum allowed of 10, and that seemed to have helped a lot.  Having more network connections helps keep my node "in the loop" so that it is not the last to find out about the newest blocks.

P2Pool webpage:

Code:
Node uptime: 8.525 days Peers: 10 out, 10 in
Local rate: 344MH/s (0.0% DOA) Expected time to share: 4.97 hours
Shares: 52 total (8 orphaned, 0 dead) Efficiency: 102.5%

P2Pool console dump:

Code:
2013-06-30 23:23:42.542263 P2Pool: 17325 shares in chain (17329 verified/17329 total) Peers: 20 (10 incoming)
2013-06-30 23:23:42.542394  Local: 379MH/s in last 10.0 minutes Local dead on arrival: ~0.0% (0-7%) Expected time to share: 4.6 hours
2013-06-30 23:23:42.542474  Shares: 52 (8 orphan, 0 dead) Stale rate: ~15.4% (8-28%) Efficiency: ~102.5% (87-112%) Current payout: 0.0137 BTC
2013-06-30 23:23:42.542560  Pool: 774GH/s Stale rate: 17.4% Expected time to block: 1.4 days

BFGMiner console header text:

Code:
--------------------------------------------------------------------------------
 5s: 87.3 avg:335.9 u:326.3 Mh/s | A:55990 R:1012+0(1.8%) HW:507
 ST: 1  GF: 0  NB: 1397  AS: 0  RF: 0  E: 0.06  U:4.6/m  BS:274k
 Connected to localhost diff 1 with stratum as user P2Pool
 Block: ...4592a33c #244201  Diff:21.3M (152.7Th/s)  Started: [23:25:51]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 169.5/335.9/326.3Mh/s | A:55990 R:1012+0(1.8%) HW:507
--------------------------------------------------------------------------------

BFGMiner pool information:

Code:
Queued work requests: 78282
 Share submissions: 56993
 Accepted shares: 55981
 Rejected shares: 1012 + 0 stale (0.02%)
 Accepted difficulty shares: 55981
 Rejected difficulty shares: 1012
 Efficiency (accepted * difficulty / 2 KB): 0.06
 Stale submissions discarded due to new blocks: 0
 Unable to get work from server occasions: 0
 Submitting work remotely delay occasions: 0

It's been nicely stable.  I need to upgrade Bitcoin to 0.8.3 (from 0.8.2) and BFGMiner to 3.1.1 (from 3.1.0), so will restart it soon for that.

1JUZr4TZ5zuB4WdEv4mrhZMaM7yttpJvLG Smiley
baloo_kiev
Sr. Member
****
Offline Offline

Activity: 476
Merit: 250


View Profile
July 01, 2013, 07:54:22 AM
 #5936

Why would they fix this only in the usb version?

Usb version is controlled by third-party mining software like cgminer and others. Blades are controlled by closed-source software written (poorly!) by some AM's partner company. I guess the only thing can be done here is waiting until AM fixes its dumb software for its smart chips.

PGP: 6EC48BA7
Welcome to my p2pool: BTC
daemondazz
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
July 01, 2013, 08:26:20 AM
 #5937

I would not be surprised if one of the biggest changes to their "next generation" blade will be the firmware. The first version of the blade's I think really were the quick and dirty to get them going. Version 2 will be the time to fix the problems.

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

Activity: 194
Merit: 100


View Profile
July 01, 2013, 10:17:01 AM
 #5938

Is it normal for a node with 2GH/s?
No. You just step on memory leak. Git pull and restart node.
Updated and restarted, looks better now: 300 MB of memory used.
Does it increases with the hashrate or not?
It seems to be correlated to the # of peers/workers connected.

Give me Btc: 1BRkf5bwSVdGCyvu4SyYBiJjEjbNiAQoYd Mine on my node: http://ask.gxsnmp.org:9332/
rav3n_pl
Legendary
*
Offline Offline

Activity: 1361
Merit: 1000


Don`t panic! Organize!


View Profile WWW
July 01, 2013, 12:43:44 PM
 #5939

From my observation it is some leak in tcp/ip twisted/zope connectors.
Lak occurs when there is some switching in connected nodes and connected miners.
Probably something is "hanging" connections buffers that are spawned in next created connections and making cascade eat of ram.
Found some articles about that. Looks like connections that are not closed "directly" are moved to new instance by default and then even after connection finally drops memory is "eaten" and GC is not freeing it.

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
Some stuff on https://github.com/Rav3nPL/
Boing7898
Sr. Member
****
Offline Offline

Activity: 686
Merit: 259



View Profile
July 01, 2013, 04:07:27 PM
 #5940

After updating to the last git, I'm starting to get a lot of "Couldn't bind: 24: too many open files"
What's the problem?
I have to restart p2pool each time it happens..

Also wtf, is this normal? That looks like a Litecoin address to me.. I'm hosting a Bitcoin pool.

2013-07-01 12:15:46.267753 Worker Lcn8gbjgv3L9V3WQMEgxxRBrbmEbCVNCF3 submitted share with hash > target:
2013-07-01 12:15:46.267822     Hash:   3509665dafb744bfcfcc932d7cf29052e51c4afe763165b4e3e1f80ec85286a1
2013-07-01 12:15:46.268389     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff
Pages: « 1 ... 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 343 344 345 346 347 ... 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!