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

[Sonatix]

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.
 

[matthewh3]

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   I sure hope not.

Let me know how it goes please.

[xyzzy099]

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   I sure hope not.

Let me know how it goes please.

Will do.

[oldbushie]

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).

[nreal]

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

[Krak]

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]

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.

[nreal]

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 (<choice> [=y])
Defined at kernel/Kconfig.hz:42
Depends on: <choice>

[lanfanblue]

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]

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

[astutiumRob]

Is anyone mining October Jupiters on P2Pool with cgminer successfully

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

[aamarket]

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.

[nreal]

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 <lambda>
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 > --- <exception caught here> ---
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

[xgtele]

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.

Looks interesting. Which OS do you installed on it?

[wlz2011]

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

2.

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

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

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

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

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

183.136.216.39:9332 服务器停机维护

2013.12.03  我们开始测试矿池 http://mine.yuyi.tw:9332

矿池算力上到4.5T，算力溢出很明显。如下图



http://i44.tinypic.com/jj71hg.jpg

大概有300G的算力被溢出，并且抢走了2个SHARE。

这仅仅是个开始，相信会有足够的证据留在图表中。

[yuyi]

It is not a problem, but it had been solved in my pool. ( http://mine.yuyi.tw:9332 )

I already sent you a pm in detail. 

183.136.216.39:9332 服务器停机维护

2013.12.03  我们开始测试矿池 http://mine.yuyi.tw:9332

矿池算力上到4.5T，算力溢出很明显。如下图

http://i44.tinypic.com/jj71hg.jpg

http://i44.tinypic.com/jj71hg.jpg

大概有300G的算力被溢出，并且抢走了2个SHARE。

这仅仅是个开始，相信会有足够的证据留在图表中。

[forrestv]

P2Pool release 13.4 - commit hash: 8e7cb8223a38bdd4ff55971d2945f5ccb571e063

Windows binary: http://u.forre.st/u/wftncvpn/p2pool_win32_13.4.zip
Windows binary signature: http://u.forre.st/u/eoietnxc/p2pool_win32_13.4.zip.sig
Source zipball: https://github.com/forrestv/p2pool/zipball/13.4
Source tarball: https://github.com/forrestv/p2pool/tarball/13.4

Changes:
* Require Litecoin >=0.8.5.1
* Warn about old versions of Bitcoin and Terracoin
* Many improvements to web interface and graphs
* Fixed error messages being created in bitcoind's debug.log due to invalid message being sent

[Raulnsh]

Hi,
I have some strange problem. I've discovered that my node of version 13.3 kept litecoin log from 2013-08-21 (when I've installed it) to 2013-08-22. No log since 2013-08-23; yesterday it have stopped payment to default address for found shares. I've restarted it, and now I see log for 2013-12-04.
Why this can happen?

[forrestv]

Hi,
I have some strange problem. I've discovered that my node of version 13.3 kept litecoin log from 2013-08-21 (when I've installed it) to 2013-08-22. No log since 2013-08-23; yesterday it have stopped payment to default address for found shares. I've restarted it, and now I see log for 2013-12-04.
Why this can happen?

If your hard drive was full or some other error happened while writing to the log file, it just stops writing to the log file but continues to work.

[oteoztsoffn]

Why not state clearly in this thread that p2pool.org and p2pool.com are not affiliated with p2pool?