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

nreal

full member

Activity: 932

Merit: 100

arcs-chain.com

2013-12-01 10:05:22.933224 GOT SHARE! 1ghdfrxzhjghjk---- 250f99fa prev ba9ac418 age 14.43s
2013-12-01 10:05:22.956239 > Error while processing Event callbacks:
2013-12-01 10:05:22.956296 > Traceback (most recent call last):
2013-12-01 10:05:22.956323 > File "/mnt/p2pool/p2pool/bitcoin/worker_interface.py", line 136, in
2013-12-01 10:05:22.956349 > lambda header, user, coinbase_nonce: handler(header, user, pack.IntType(self._my_bits).pack(nonce) + coinbase_nonce),
2013-12-01 10:05:22.956374 > File "/mnt/p2pool/p2pool/work.py", line 403, in got_response
2013-12-01 10:05:22.956397 > self.node.set_best_share()
2013-12-01 10:05:22.956421 > File "/mnt/p2pool/p2pool/node.py", line 297, in set_best_share
2013-12-01 10:05:22.956457 > self.best_share_var.set(best)
2013-12-01 10:05:22.956487 > File "/mnt/p2pool/p2pool/util/variable.py", line 74, in set
2013-12-01 10:05:22.956510 > self.changed.happened(value)
2013-12-01 10:05:22.956532 > --- ---
2013-12-01 10:05:22.956554 > File "/mnt/p2pool/p2pool/util/variable.py", line 42, in happened
2013-12-01 10:05:22.956577 > func(*event)
2013-12-01 10:05:22.956599 > File "/mnt/p2pool/p2pool/node.py", line 96, in broadcast_share
2013-12-01 10:05:22.956622 > peer.sendShares([share for share in shares if share.peer_addr != peer.addr], self.node.tracker, self.node.known_txs_var.value, include_txs_with=[share_hash])
2013-12-01 10:05:22.956648 > File "/mnt/p2pool/p2pool/p2p.py", line 291, in sendShares
2013-12-01 10:05:22.956671 > assert tx_hash in known_txs, 'tried to broadcast share without knowing all its new transactions'
2013-12-01 10:05:22.956694 > exceptions.AssertionError: tried to broadcast share without knowing all its new transactions

2013-12-01 10:07:28.634340 P2Pool: 17342 shares in chain (17346 verified/17346 total) Peers: 20 (3 incoming)
2013-12-01 10:07:28.634406 Local: 123GH/s in last 10.0 minutes Local dead on arrival: ~4.7% (3-7%) Expected time to share: 2.3 hours
2013-12-01 10:07:28.634436 Shares: 1 (1 orphan, 0 dead) Stale rate: ~100.0% (20-100%) Efficiency: ~0.0% (0-97%) Current payout: 0.0000 BTC

aamarket

sr. member

Activity: 259

Merit: 250

I have a public p2pool node running for some time,
the last week on cheap tvstick mk888b hardware.
It seems running fine, probably latency is a bit worse
than with Intel i3-3220 before.

If anybody wants to test, use your btc address as username,
any password(different from username) and go to

http://aamarket.eu:9332/

feedback welcome.

astutiumRob

full member

Activity: 201

Merit: 100

Quote from: matthewh3 on November 29, 2013, 07:34:15 AM

Is anyone mining October Jupiters on P2Pool with cgminer successfully

12 days (since last firmware reconfig), no crashes, no problems with mine.

nreal

full member

Activity: 932

Merit: 100

arcs-chain.com

So its different here, because with 1000 000 blocksize and latency 0.4-1s my hashreate drops every now and then from 120ghash to even 80ghash. with 0.03 latency it keeps goin at 110 - 135 ghash.

Bitcoind uses sometimes 1% cputime on core i7 3770k ,ssd disk, 16gb ram

lanfanblue

newbie

Activity: 31

Merit: 0

Quote from: nreal on November 30, 2013, 04:37:01 AM

Quote from: Krak on November 30, 2013, 02:13:02 AM

Quote from: nreal on November 30, 2013, 01:50:06 AM

If my node is configured with 1mbit blockmaxsize and minrelaytxfee=0.00001 latency is 0.4-0.9s. That makes miners go allmost asleep - i dont get much shares with these settings alltough it doesnt affect efficiency rate.

blockmaxsize=100 000 minrelaytxfee=0.0005 latency is +-0.03 and butterflylabs sc:s start to make noise.

Changing these settings doesn't affect the share rate whatsoever.

Well I can say that youre wrong, very much indeed. Going from 0.03s to 0.4s latency you will see alot less shares with asics, because of the lag ofcourse. Immediately you can hear the difference when your equipment runs with work all the time, fans start to really blow..

Try it, and tell us how it went.

one week with 1000 000 blocksize and 0.0001 fees, then the next week drop it to 50 000 and 0.005 fees. If it doesnt make you more shares then the first week im suprised.

But if you have bitcoind on ramdisk difference might not be that big then, im going to try that when my memorys arrive.

In my experience, the block template latency has minor effects on the share rate.
I use Avalon miner. I tuned this latency from <0.1 to ~0.5 by changing maxblocksize from 50k to 700k. In both scenarios, I got almost the same share rate.
You can check log of bitcoind, p2pool asks for a new blocktemplate approximately every 15s. This means, the asic miner works on different block template every 15s. I don't think it's a big deal whether that latency is 0.05s or 0.5s compared to 15s working time period. (0.5/15=3% DOA, but my avalon has 5% DOA due to its long latency. So it won't hurt me a lot. But it might be an issue if it's >1s.)

But I found that the blocksize might be related to orphan rate. When I was using the default block size 250k, I got lots of orphans. When I tuned it to other values, no matter larger or smaller, the orphan rate dropped. But this might be wring, because my Internet connection is really unstable.

nreal

full member

Activity: 932

Merit: 100

arcs-chain.com

Quote from: nreal on November 30, 2013, 04:37:01 AM

Quote from: Krak on November 30, 2013, 02:13:02 AM

Quote from: nreal on November 30, 2013, 01:50:06 AM

If my node is configured with 1mbit blockmaxsize and minrelaytxfee=0.00001 latency is 0.4-0.9s. That makes miners go allmost asleep - i dont get much shares with these settings alltough it doesnt affect efficiency rate.

blockmaxsize=100 000 minrelaytxfee=0.0005 latency is +-0.03 and butterflylabs sc:s start to make noise.

Changing these settings doesn't affect the share rate whatsoever.

Well I can say that youre wrong, very much indeed. Going from 0.03s to 0.4s latency you will see alot less shares with asics, because of the lag ofcourse. Immediately you can hear the difference when your equipment runs with work all the time, fans start to really blow..

Try it, and tell us how it went.

one week with 1000 000 blocksize and 0.0001 fees, then the next week drop it to 50 000 and 0.005 fees. If it doesnt make you more shares then the first week im suprised.

But if you have bitcoind on ramdisk difference might not be that big then, im going to try that when my memorys arrive.

Theres one thing if you run your node on linux kernel that can be tweaked too, infact two

Preemptible Kernel (Low-Latency Desktop) (PREEMPT)

CONFIG_PREEMPT:

This option reduces the latency of the kernel by making
all kernel code (that is not executing in a critical section)
preemptible. This allows reaction to interactive events by
permitting a low priority process to be preempted involuntarily
even if it is in kernel mode executing a system call and would
otherwise not be about to reach a natural preemption point.
This allows applications to run more 'smoothly' even when the
system is under load, at the cost of slightly lower throughput
and a slight runtime overhead to kernel code.

Select this if you are building a kernel for a desktop or
embedded system with latency requirements in the milliseconds
range.

Nr2

Timer frequency

Allows the configuration of the timer frequency. It is customary
to have the timer interrupt run at 1000 Hz but 100 Hz may be more
beneficial for servers and NUMA systems that do not need to have
a fast response for user interaction and that may experience bus
contention and cacheline bounces as a result of timer interrupts.
Note that the timer interrupt occurs on each processor in an SMP
environment leading to NR_CPUS * HZ number of timer interrupts
per second.

Prompt: Timer frequency
Location:
-> Processor type and features
Defined at kernel/Kconfig.hz:5
Selected by: m

1000 HZ (HZ_1000)

CONFIG_HZ_1000:

1000 Hz is the preferred choice for desktop systems and other
systems requiring fast interactive responses to events.

Symbol: HZ_1000 [=y]
Type : boolean
Prompt: 1000 HZ
Location:
-> Processor type and features
-> Timer frequency ( [=y])
Defined at kernel/Kconfig.hz:42
Depends on:

nreal

full member

Activity: 932

Merit: 100

arcs-chain.com

Quote from: Krak on November 30, 2013, 02:13:02 AM

Quote from: nreal on November 30, 2013, 01:50:06 AM

If my node is configured with 1mbit blockmaxsize and minrelaytxfee=0.00001 latency is 0.4-0.9s. That makes miners go allmost asleep - i dont get much shares with these settings alltough it doesnt affect efficiency rate.

blockmaxsize=100 000 minrelaytxfee=0.0005 latency is +-0.03 and butterflylabs sc:s start to make noise.

Changing these settings doesn't affect the share rate whatsoever.

Well I can say that youre wrong, very much indeed. Going from 0.03s to 0.4s latency you will see alot less shares with asics, because of the lag ofcourse. Immediately you can hear the difference when your equipment runs with work all the time, fans start to really blow..

Try it, and tell us how it went.

one week with 1000 000 blocksize and 0.0001 fees, then the next week drop it to 50 000 and 0.005 fees. If it doesnt make you more shares then the first week im suprised.

But if you have bitcoind on ramdisk difference might not be that big then, im going to try that when my memorys arrive.

Krak

hero member

Activity: 591

Merit: 500

Quote from: nreal on November 30, 2013, 01:50:06 AM

If my node is configured with 1mbit blockmaxsize and minrelaytxfee=0.00001 latency is 0.4-0.9s. That makes miners go allmost asleep - i dont get much shares with these settings alltough it doesnt affect efficiency rate.

blockmaxsize=100 000 minrelaytxfee=0.0005 latency is +-0.03 and butterflylabs sc:s start to make noise.

Changing these settings doesn't affect the share rate whatsoever.

nreal

full member

Activity: 932

Merit: 100

arcs-chain.com

Quote from: nreal on November 29, 2013, 03:55:32 PM

Quote from: xyzzy099 on November 29, 2013, 02:30:42 PM

Can anyone tell me some tricks to minimize bitcoind GetBlockTemplate latency? Mine seems to run very consistently at ~1s, but I see many public nodes with less than 0.3s.

What is the source of this latency and what can be done to address it?

blockmaxsize= bigger the slower, minrelaytxfee= smaller is slower , bitcoind on ssd or ramdisk is fast. Bitcoin blocks are stored very stupid way, because blocks arent in folders, so you cant mount --bind some of them to ramdisk, I think all the blocks must be in ram or ssd to get any improvement.. 15,4gt now..

If my node is configured with 1mbit blockmaxsize and minrelaytxfee=0.00001 latency is 0.4-0.9s. That makes miners go allmost asleep - i dont get much shares with these settings alltough it doesnt affect efficiency rate.

blockmaxsize=100 000 minrelaytxfee=0.0005 latency is +-0.03 and butterflylabs sc:s start to make noise.

Ordered 32gb ram to make 24gb ramdisk for bitcoin, cant wait to see what is the effect with that.

Gentoo makes it east to make a ramdisk

file /etc/fstab

tmpfs /var/tmp/portage tmpfs noatime,nodev,nosuid 0 0

kernel three or two settings

CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=24576 > for 24gb ramdisk

oldbushie

member

Activity: 94

Merit: 10

Quote from: Mogumodz on November 29, 2013, 06:42:39 PM

Quote from: oldbushie on November 29, 2013, 03:27:38 PM

Since I changed to p2pool on a Linux VPS, the new custom frontend seems to show a really low "local rate reflected in shares" value compared to the "local hash rate" on that node.
http://192.30.165.92:9332/static/graphs.html?Day

Is this normal? I haven't seen it go close to or above the actual hash rate *once*.

Not sure entirely what you mean, but everything looks normal.

I'm comparing the top two graphs. The mean for the "Local rate reflected in shares" graph seems to be at least 100GH/s below the mean for the "Local rate" graph most of the time when I'm looking at it. Before when I was running p2pool at home on a Windows machine (instead of on a vps with Linux) with the original hardcpp p2pool extended frontend instead of the more up to date version I found, I got much different variations between the two, sometimes seeing the mean share rate being significantly higher than the mean local rate (and sometimes much lower).

xyzzy099

legendary

Activity: 1066

Merit: 1098

Quote from: matthewh3 on November 29, 2013, 07:47:47 PM

Quote from: xyzzy099 on November 29, 2013, 10:49:22 AM

Quote from: matthewh3 on November 29, 2013, 10:34:56 AM

Quote from: xyzzy099 on November 29, 2013, 09:27:09 AM

Quote from: matthewh3 on November 29, 2013, 07:34:15 AM

Is anyone mining October Jupiters on P2Pool with cgminer successfully. I know when we tried the other week it would mine OK but every so often cgminer would crash. So it'd just go unhashing for hours until we realised. We have two October Jupiters and a November one on the way that we'd like to hash on P2Pool.

I just started mining my Jupiter on P2Pool 2 days ago, but so far it has been running great - no problems at all.

CGMiner reports a low average hash rate - ~450 GH/s while I typically see a very consistent 566 GH/s on other pools - but P2Pool reports close to the actual hash rate, and the payouts are correct for my actual hash rate.

[EDIT: I should say that this is with the latest 0.99-tune firmware. It was running the same on the plain 0.99 before I updated.]

Yeah it too a good few days between crashes but we was losing that many coins we had to move them off P2Pool.

I remember seeing a bug fix by ckolivas for a serious memory leak that occurred when using the cgminer API. If you were using the miner GUI alot, especially if you were using something like Bertmod, that might explain the crashes you were seeing. If so, you might want to try with the latest cgminer. If not, well, maybe I will start seeing crashes later too Sad

I sure hope not.

Let me know how it goes please.

Will do.

matthewh3

legendary

Activity: 1372

Merit: 1003

Quote from: xyzzy099 on November 29, 2013, 10:49:22 AM

Quote from: matthewh3 on November 29, 2013, 10:34:56 AM

Quote from: xyzzy099 on November 29, 2013, 09:27:09 AM

Quote from: matthewh3 on November 29, 2013, 07:34:15 AM

Is anyone mining October Jupiters on P2Pool with cgminer successfully. I know when we tried the other week it would mine OK but every so often cgminer would crash. So it'd just go unhashing for hours until we realised. We have two October Jupiters and a November one on the way that we'd like to hash on P2Pool.

I just started mining my Jupiter on P2Pool 2 days ago, but so far it has been running great - no problems at all.

CGMiner reports a low average hash rate - ~450 GH/s while I typically see a very consistent 566 GH/s on other pools - but P2Pool reports close to the actual hash rate, and the payouts are correct for my actual hash rate.

[EDIT: I should say that this is with the latest 0.99-tune firmware. It was running the same on the plain 0.99 before I updated.]

Yeah it too a good few days between crashes but we was losing that many coins we had to move them off P2Pool.

I remember seeing a bug fix by ckolivas for a serious memory leak that occurred when using the cgminer API. If you were using the miner GUI alot, especially if you were using something like Bertmod, that might explain the crashes you were seeing. If so, you might want to try with the latest cgminer. If not, well, maybe I will start seeing crashes later too Sad

I sure hope not.

Let me know how it goes please.

Sonatix

member

Activity: 118

Merit: 100

trying to mine terracoin - getting

Code:

2013-11-30 02:13:36.039000 P2Pool: 0 shares in chain (0 verified/0 total) Peers: 0 (0 incoming)
2013-11-30 02:13:36.039000 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2013-11-30 02:13:51.043000 P2Pool: 0 shares in chain (0 verified/0 total) Peers: 0 (0 incoming)
2013-11-30 02:13:51.045000 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2013-11-30 02:13:58.042000 Handshake timed out, disconnecting from 46.105.103.55:9323
2013-11-30 02:14:06.047000 P2Pool: 0 shares in chain (0 verified/0 total) Peers: 0 (0 incoming)
2013-11-30 02:14:06.048000 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2013-11-30 02:14:21.050000 P2Pool: 0 shares in chain (0 verified/0 total) Peers: 0 (0 incoming)
2013-11-30 02:14:21.051000 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2013-11-30 02:14:36.053000 P2Pool: 0 shares in chain (0 verified/0 total) Peers: 0 (0 incoming)
2013-11-30 02:14:36.054000 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2013-11-30 02:14:48.065000 Handshake timed out, disconnecting from 46.105.103.55:9323
2013-11-30 02:14:51.056000 P2Pool: 0 shares in chain (0 verified/0 total) Peers: 0 (0 incoming)
2013-11-30 02:14:51.056000 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2013-11-30 02:15:06.058000 P2Pool: 0 shares in chain (0 verified/0 total) Peers: 0 (0 incoming)
2013-11-30 02:15:06.059000 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2013-11-30 02:15:21.066000 P2Pool: 0 shares in chain (0 verified/0 total) Peers: 0 (0 incoming)
2013-11-30 02:15:21.067000 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2013-11-30 02:15:21.294000 Handshake timed out, disconnecting from 46.105.103.55:9323
2013-11-30 02:15:36.069000 P2Pool: 0 shares in chain (0 verified/0 total) Peers: 0 (0 incoming)
2013-11-30 02:15:36.071000 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ???
2013-11-30 02:15:42.550000 Handshake timed out, disconnecting from 46.105.103.55:9323

Why is my p2pool is constantly connected to the same node that is not available? I delete this IP from the "addr", but p2pool still tries to connect to it and ignores the other addresses.
Sad

Mogumodz

sr. member

Activity: 290

Merit: 250

Quote from: oldbushie on November 29, 2013, 03:27:38 PM

Since I changed to p2pool on a Linux VPS, the new custom frontend seems to show a really low "local rate reflected in shares" value compared to the "local hash rate" on that node.
http://192.30.165.92:9332/static/graphs.html?Day

Is this normal? I haven't seen it go close to or above the actual hash rate *once*.

Not sure entirely what you mean, but everything looks normal.

xyzzy099

legendary

Activity: 1066

Merit: 1098

Quote from: nreal on November 29, 2013, 03:55:32 PM

Quote from: xyzzy099 on November 29, 2013, 02:30:42 PM

Can anyone tell me some tricks to minimize bitcoind GetBlockTemplate latency? Mine seems to run very consistently at ~1s, but I see many public nodes with less than 0.3s.

What is the source of this latency and what can be done to address it?

blockmaxsize= bigger the slower, minrelaytxfee= smaller is slower , bitcoind on ssd or ramdisk is fast. Bitcoin blocks are stored very stupid way, because blocks arent in folders, so you cant mount --bind some of them to ramdisk, I think all the blocks must be in ram or ssd to get any improvement.. 15,4gt now..

Thanks

nreal

full member

Activity: 932

Merit: 100

arcs-chain.com

Quote from: xyzzy099 on November 29, 2013, 02:30:42 PM

Can anyone tell me some tricks to minimize bitcoind GetBlockTemplate latency? Mine seems to run very consistently at ~1s, but I see many public nodes with less than 0.3s.

What is the source of this latency and what can be done to address it?

blockmaxsize= bigger the slower, minrelaytxfee= smaller is slower , bitcoind on ssd or ramdisk is fast. Bitcoin blocks are stored very stupid way, because blocks arent in folders, so you cant mount --bind some of them to ramdisk, I think all the blocks must be in ram or ssd to get any improvement.. 15,4gt now..

oldbushie

member

Activity: 94

Merit: 10

Since I changed to p2pool on a Linux VPS, the new custom frontend seems to show a really low "local rate reflected in shares" value compared to the "local hash rate" on that node.
http://192.30.165.92:9332/static/graphs.html?Day

Is this normal? I haven't seen it go close to or above the actual hash rate *once*.

xyzzy099

legendary

Activity: 1066

Merit: 1098

Can anyone tell me some tricks to minimize bitcoind GetBlockTemplate latency? Mine seems to run very consistently at ~1s, but I see many public nodes with less than 0.3s.

What is the source of this latency and what can be done to address it?

wlz2011

member

Activity: 71

Merit: 10

Quote from: yuyi on November 28, 2013, 01:44:40 PM

Quote from: wlz2011 on November 21, 2013, 03:53:26 PM

Quote from: zvs on November 20, 2013, 08:15:32 PM

Quote from: wlz2011 on November 20, 2013, 03:42:13 AM

Quote from: zvs on November 16, 2013, 11:30:10 PM

OK, so I'm guessing people probably use 204.10.105.113:9332/static because of the domain p2pool.org... even though it's horribly set up & has a 2% fee. quite sad really, when one looks at the one month/one year chart. (oh and ofc he never took me up on my offer, no mails from that guy)

now, second question, why do people use elizium.name?... or is it just all local traffic? though I'd be shocked if 95% or more of it wasn't just from random people using a remote p2pool. 400 shares I think is enough to get a trend & 55 orphans is bad. I can see there's 11 outgoing connections, but I guess I'll assume that those are just random outgoing connections? It looks like my node @ 198.12.127.2 used one of its random outgoing connections to hook up w/ it, but not connected to me at the other two places. normally i'd add it to --p2pool-node since it seems to be on a fast enough computer & good connection, but i've just been observing the sub 100% efficiency for the last few days & curiosity killed the cat. Is it all just because of that interface? The most important part is busted (the share explorer).

I also don't understand why so many people use 183.136.216.39:9332/static/graphs.html?Year when it's absolutely horrid. 10 outgoing connections, that are either totally random or not good choices. For location (China), he's not connecting to some critical western US & Russian nodes that he should be on. I *think* it's also on an old version of bitcoind. at least it's at 0% fee

But why would you use that over this: mine.yuyi.tw:9332 a far superior pool in Taiwan with 1/10th the hashrate. This one runs 0% fee too, so that's not it

is there some place i'm missing where these sites are being advertised? reddit? asic hardware manufacturer forums? lol.

some people want to use p2pool for whatever reason, but don't want to spend money on hosting for their own node (I'll assume they live in a crap rural area like myself w/ shit for bandwidth). but why always choose the wrong pools? then you get all the bullshit misinformation about how p2pool pays out less than . yeah, probably cause you were on one of these low efficiency pools or running a local node that was getting 15% orphans and 5% DOA.. though if it weren't for those people, I guess the rest wouldn't be picking up the bonus

but, seriously, who is mining on one of those 3 pools right now and why? is there anyone that reads this thread that does? if not, where are they coming from?

你懂中文吗？我不懂英文，183.136.216.39：9332是我建立的，但是我不懂编程这些技术，这是个普通的P2POOL节点矿池。我不知道如何去固定节点，或者应该怎么固定你说的美国俄罗斯节点。我只是和朋友在一起挖矿，可能是最差的池，来自一个完全不懂电脑程序的人，服务器是朋友提供的，没有打算收取任何费用。很高兴能引起你的关注，同时我也希望能得到技术上的帮助。如果你懂中文，是否可以用中文来帮助我解决这些问题，谢谢。钱包是的0.85版本。

I had to use google translate. Grin

I'd say talk to this guy: mine.yuyi.tw:9332

https://twitter.com/TaiwanPool (for one, you'd want him to --p2pool-node to your pool, since he has 0 incoming)

I've been saying for a while it's by far the best server in Oceania area.... it looks like he picked up a lot of hashing power recently and is still doing well on orphans

LOL，我看懂了，你和我一样需要谷歌翻译。好吧，你的意思是说台湾 mine.yuyi.tw:9332池子效率很高。我昨天叫矿友们去测试了，效率是要好一些。我很羡慕你们懂的如何提升矿池效率，我不懂编程这些，能力非常有限，但是我尽量让矿池效率提升。我让矿友一部分算力进入mine.yuyi.tw:9332，分散一些算力，因为P2POOL节点矿池有个瓶颈，无论你的池子效率多高，都会遇见程序的瓶颈。

当算力大于3T，会出现吞噬小算力，如图

这个算力被吞噬了，完全失去了效率。

另外一个BUG，当算力大于3.5T或者4T以上，会出现算力溢出，如图

这些算力是溢出的，当4.5T可以看见有100G-300G算力被溢出。

如果你能联系上P2POOL程序的作者，应该让他优化程序，对P2POOL的发展是有帮助的。对大家都有好处，P2POOL算力值有50T - 70 T，目前的难度和矿机算力看，P2POOL需要尽快修改这些BGU。

如果能P2POOL使用stratum协议，效率会更高，为什么是目前的Getwork协议？效率很低！！！

请帮助我转达给P2POOL的作者，谢谢。我的英文不好，让他来看图吧。

另外你说的 https://twitter.com/TaiwanPool 添加为节点。IP = 59.24.3.173

请问bitcoin.conf该如何写呢？请帮助我，我真的不懂编程，这些命令我一点不懂。谢谢

rpcuser=abc
rpcpassword=123
server=1
rpcport=8332
port=8333
rpcconnect=127.0.0.1
addnode=59.24.3.173
addnode=

这样写正确吗？？？

可以给我一份这个bitcoin.conf的内容吗？请写上你认为更多的非常好的节点。谢谢！！！

如果你能帮助我，将会获得更多的算力加入P2POOL！

来自中国的P2POOL矿友 Wlz2011

1. DOA變100%的問題我也有注意到，目前重開挖礦程式就會好，似乎和運算能力沒關係，比較像是隨機出現。

2.

我目前沒有大於4.5T的環境可以測試，而且最近在我礦池上都沒發生null。

比對之前有出現短暫null時，整體礦池也沒有超過4.5Thash/s過。

是否可以試著換挖礦程式 cgminer 或 bfgminer 試試。

3. taiwan pool的配置無法從外面連線，我有先將你的IP加入我連線的清單，伺服器下次重啟就會連上你的礦池。

如果有任何問題歡迎pm跟我討論

很高兴看见你回复，台湾池主，总算是遇见一个会说中文的

1. DOA100%重启好像不能解决问题，我认为这是程序构架上的问题，算力出现吞噬，当然我没有再次测试，暂时的处理方法是分散了算力，有朋友暂时提供了另外的免费服务器，当然免费是不可能长久持续的。

2. 4.5T的高压环境，NULL已经在3个服务器测试，均出现了这个问题，我认为这也是程序构架的问题，当然如果你想看见这个结果，我可以尝试安排这样的环境在你的服务器进行测试，正好过几天我会关闭服务器几小时，应该你能看见这样的效果。

3. 我不知道矿池之间该如何正确的固定连线，我有添加在CONF文件里添加你的http://mine.yuyi.tw:9332的IP地址，不知道这样做是否正确，但是我感觉好像不是这样操作。https://twitter.com/TaiwanPool 我根本就打不开这个页面。

4. 我这边是WIN环境，Python 运行矿池，如果可以的话，请告诉我如何固定连线别的矿池，我不懂编程这些的，所以对很多设置都是陌生的，非常感谢。

很高兴认识你，希望P2POOL算力上去，对大家都有好处。

xyzzy099

legendary

Activity: 1066

Merit: 1098

Quote from: matthewh3 on November 29, 2013, 10:34:56 AM

Quote from: xyzzy099 on November 29, 2013, 09:27:09 AM

Quote from: matthewh3 on November 29, 2013, 07:34:15 AM

Is anyone mining October Jupiters on P2Pool with cgminer successfully. I know when we tried the other week it would mine OK but every so often cgminer would crash. So it'd just go unhashing for hours until we realised. We have two October Jupiters and a November one on the way that we'd like to hash on P2Pool.

I just started mining my Jupiter on P2Pool 2 days ago, but so far it has been running great - no problems at all.

CGMiner reports a low average hash rate - ~450 GH/s while I typically see a very consistent 566 GH/s on other pools - but P2Pool reports close to the actual hash rate, and the payouts are correct for my actual hash rate.

[EDIT: I should say that this is with the latest 0.99-tune firmware. It was running the same on the plain 0.99 before I updated.]

Yeah it too a good few days between crashes but we was losing that many coins we had to move them off P2Pool.

I remember seeing a bug fix by ckolivas for a serious memory leak that occurred when using the cgminer API. If you were using the miner GUI alot, especially if you were using something like Bertmod, that might explain the crashes you were seeing. If so, you might want to try with the latest cgminer. If not, well, maybe I will start seeing crashes later too Sad

I sure hope not.

Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 462. (Read 2591964 times)