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

[Subo1977]

at my site on ubuntu 11.10 all patches:

Version: 11.1-1-g8c9f2ca  from GIT

Pool rate: 342GH/s (14% DOA+orphan) Share difficulty: 616

Node uptime: 1.606 days Peers: 10 out, 0 in

Local rate: 4.63GH/s (4.6% DOA) Expected time to share: 0.155 hours

Shares: 266 total (34 orphaned, 8 dead) Efficiency: 98.25%

Date   Memory Usage/(B)
Sat Jan 12 2013 11:02:24 GMT+0100 (Mitteleuropäische Zeit)   436M
Sat Jan 12 2013 10:28:48 GMT+0100 (Mitteleuropäische Zeit)   436M
Sat Jan 12 2013 09:55:12 GMT+0100 (Mitteleuropäische Zeit)   436M
Sat Jan 12 2013 09:21:36 GMT+0100 (Mitteleuropäische Zeit)   436M
Sat Jan 12 2013 08:48:00 GMT+0100 (Mitteleuropäische Zeit)   436M
Sat Jan 12 2013 08:14:24 GMT+0100 (Mitteleuropäische Zeit)   436M
Sat Jan 12 2013 07:40:48 GMT+0100 (Mitteleuropäische Zeit)   436M
Sat Jan 12 2013 07:07:12 GMT+0100 (Mitteleuropäische Zeit)   436M
Sat Jan 12 2013 06:33:36 GMT+0100 (Mitteleuropäische Zeit)   436M
Sat Jan 12 2013 06:00:00 GMT+0100 (Mitteleuropäische Zeit)   436M
Sat Jan 12 2013 05:26:24 GMT+0100 (Mitteleuropäische Zeit)   436M
Sat Jan 12 2013 04:52:48 GMT+0100 (Mitteleuropäische Zeit)   434M
Sat Jan 12 2013 04:19:12 GMT+0100 (Mitteleuropäische Zeit)   437M
Sat Jan 12 2013 03:45:36 GMT+0100 (Mitteleuropäische Zeit)   434M
Sat Jan 12 2013 03:12:00 GMT+0100 (Mitteleuropäische Zeit)   437M
Sat Jan 12 2013 02:38:24 GMT+0100 (Mitteleuropäische Zeit)   437M
Sat Jan 12 2013 02:04:48 GMT+0100 (Mitteleuropäische Zeit)   435M
Sat Jan 12 2013 01:31:12 GMT+0100 (Mitteleuropäische Zeit)   434M
Sat Jan 12 2013 00:57:36 GMT+0100 (Mitteleuropäische Zeit)   432M
Sat Jan 12 2013 00:24:00 GMT+0100 (Mitteleuropäische Zeit)   431M
Fri Jan 11 2013 23:50:24 GMT+0100 (Mitteleuropäische Zeit)   430M
Fri Jan 11 2013 23:16:48 GMT+0100 (Mitteleuropäische Zeit)   427M
Fri Jan 11 2013 22:43:12 GMT+0100 (Mitteleuropäische Zeit)   428M
Fri Jan 11 2013 22:09:36 GMT+0100 (Mitteleuropäische Zeit)   427M
Fri Jan 11 2013 21:36:00 GMT+0100 (Mitteleuropäische Zeit)   422M
Fri Jan 11 2013 21:02:24 GMT+0100 (Mitteleuropäische Zeit)   422M
Fri Jan 11 2013 20:28:48 GMT+0100 (Mitteleuropäische Zeit)   422M
Fri Jan 11 2013 19:55:12 GMT+0100 (Mitteleuropäische Zeit)   422M
Fri Jan 11 2013 19:21:36 GMT+0100 (Mitteleuropäische Zeit)   423M
Fri Jan 11 2013 18:48:00 GMT+0100 (Mitteleuropäische Zeit)   423M
Fri Jan 11 2013 18:14:24 GMT+0100 (Mitteleuropäische Zeit)   422M
Fri Jan 11 2013 17:40:48 GMT+0100 (Mitteleuropäische Zeit)   423M
Fri Jan 11 2013 17:07:12 GMT+0100 (Mitteleuropäische Zeit)   422M
Fri Jan 11 2013 16:33:36 GMT+0100 (Mitteleuropäische Zeit)   422M
Fri Jan 11 2013 16:00:00 GMT+0100 (Mitteleuropäische Zeit)   411M
Fri Jan 11 2013 15:26:24 GMT+0100 (Mitteleuropäische Zeit)   412M
Fri Jan 11 2013 14:52:48 GMT+0100 (Mitteleuropäische Zeit)   414M
Fri Jan 11 2013 14:19:12 GMT+0100 (Mitteleuropäische Zeit)   411M
Fri Jan 11 2013 13:45:36 GMT+0100 (Mitteleuropäische Zeit)   413M
Fri Jan 11 2013 13:12:00 GMT+0100 (Mitteleuropäische Zeit)   413M
Fri Jan 11 2013 12:38:24 GMT+0100 (Mitteleuropäische Zeit)   413M
Fri Jan 11 2013 12:04:48 GMT+0100 (Mitteleuropäische Zeit)   413M
Fri Jan 11 2013 11:31:12 GMT+0100 (Mitteleuropäische Zeit)   404M

[zvs]

ed (better chart)

Sat Jan 12 2013 08:16:48 GMT-0600 (Central Standard Time)   1.11G
Sat Jan 12 2013 07:43:12 GMT-0600 (Central Standard Time)   1.10G
Sat Jan 12 2013 07:09:36 GMT-0600 (Central Standard Time)   1.08G
Sat Jan 12 2013 06:36:00 GMT-0600 (Central Standard Time)   1.05G
Sat Jan 12 2013 06:02:24 GMT-0600 (Central Standard Time)   1.02G
Sat Jan 12 2013 05:28:48 GMT-0600 (Central Standard Time)   995M
Sat Jan 12 2013 04:55:12 GMT-0600 (Central Standard Time)   969M
Sat Jan 12 2013 04:21:36 GMT-0600 (Central Standard Time)   942M
Sat Jan 12 2013 03:48:00 GMT-0600 (Central Standard Time)   916M
Sat Jan 12 2013 03:14:24 GMT-0600 (Central Standard Time)   890M
Sat Jan 12 2013 02:40:48 GMT-0600 (Central Standard Time)   862M
Sat Jan 12 2013 02:07:12 GMT-0600 (Central Standard Time)   834M
Sat Jan 12 2013 01:33:36 GMT-0600 (Central Standard Time)   806M
Sat Jan 12 2013 01:00:00 GMT-0600 (Central Standard Time)   779M
Sat Jan 12 2013 00:26:24 GMT-0600 (Central Standard Time)   747M
Fri Jan 11 2013 23:52:48 GMT-0600 (Central Standard Time)   718M
Fri Jan 11 2013 23:19:12 GMT-0600 (Central Standard Time)   693M
Fri Jan 11 2013 22:45:36 GMT-0600 (Central Standard Time)   667M
Fri Jan 11 2013 22:12:00 GMT-0600 (Central Standard Time)   638M
Fri Jan 11 2013 21:38:24 GMT-0600 (Central Standard Time)   609M
Fri Jan 11 2013 21:04:48 GMT-0600 (Central Standard Time)   584M
Fri Jan 11 2013 20:31:12 GMT-0600 (Central Standard Time)   561M
Fri Jan 11 2013 19:57:36 GMT-0600 (Central Standard Time)   560M
Fri Jan 11 2013 19:24:00 GMT-0600 (Central Standard Time)   559M
Fri Jan 11 2013 18:50:24 GMT-0600 (Central Standard Time)   529M
Fri Jan 11 2013 18:16:48 GMT-0600 (Central Standard Time)   488M
Fri Jan 11 2013 17:43:12 GMT-0600 (Central Standard Time)   448M
Fri Jan 11 2013 17:09:36 GMT-0600 (Central Standard Time)   437M
Fri Jan 11 2013 16:36:00 GMT-0600 (Central Standard Time)   437M
Fri Jan 11 2013 16:02:24 GMT-0600 (Central Standard Time)   436M
Fri Jan 11 2013 15:28:48 GMT-0600 (Central Standard Time)   436M
Fri Jan 11 2013 14:55:12 GMT-0600 (Central Standard Time)   436M
Fri Jan 11 2013 14:21:36 GMT-0600 (Central Standard Time)   433M
Fri Jan 11 2013 13:48:00 GMT-0600 (Central Standard Time)   425M
Fri Jan 11 2013 13:14:24 GMT-0600 (Central Standard Time)   424M
Fri Jan 11 2013 12:40:48 GMT-0600 (Central Standard Time)   425M
Fri Jan 11 2013 12:07:12 GMT-0600 (Central Standard Time)   427M
Fri Jan 11 2013 11:33:36 GMT-0600 (Central Standard Time)   424M
Fri Jan 11 2013 11:00:00 GMT-0600 (Central Standard Time)   417M
Fri Jan 11 2013 10:26:24 GMT-0600 (Central Standard Time)   412M
Fri Jan 11 2013 09:52:48 GMT-0600 (Central Standard Time)   401M
Fri Jan 11 2013 09:19:12 GMT-0600 (Central Standard Time)   391M
Fri Jan 11 2013 08:45:36 GMT-0600 (Central Standard Time)   383M

Node uptime: 1.742 days Peers: 14 out, 0 in

actually, looking at the graph:

http://nogleg.com:9332/static/graphs.html?Day

it appears as if something happened at 6pm (there was an outgoing peer I wasn't supposed to have that disconnected, then it's gone up in a straight line since?)

[zvs]

It took me so long to get the right peers, too... I'm going to hate to reset it later  

hmm, I guess maybe just add the ones I want and remove the getaddr

i suppose it's a coincidence that it's flat lined again after i moved my log to backup?

9:05am - i just swapped a few peers.  see if it starts going up again

[rav3n_pl]

Node v11.1 uptime: 2.514 days
BTC: Peers: 4 out, 8 in; 386MB
TRC: Peers: 2 out, 3 in; 170MB
LTC: Peers: 6 out, 15 in; 205MB
Ubuntu 12.10 (GNU/Linux 3.5.0-18-generic x86_64) 4GB VM
Running bitcoin, litecoin, terracoin, namecoin,devcoin, ixcoin, i0coin....

Code:

rav3n@rav3n:~$ htop

  1  [|||||||                                               9.9%]     Tasks: 38; 3 running
  2  [||||||                                                8.5%]     Load average: 0.36 0.34 0.33
  Mem[|||||||||||||||||||||||||||||||||||||||||||||||3254/3954MB]     Uptime: 2 days, 19:35:02
  Swp[|||||||||||||||||||||||||||||                   996/2043MB]

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
    1 root       20   0 24328  1164   424 S  0.0  0.0  0:00.84 /sbin/init
18819 rav3n      20   0 24800   836   392 S  0.0  0.0  0:18.53 ├─ SCREEN -Udm python /home/rav3n/p2pool/run_p2pool.py -f 0.5 --irc-annou
18820 rav3n      20   0  367M  161M  2152 S  0.0  4.1  1h31:09 │  └─ python /home/rav3n/p2pool/run_p2pool.py -f 0.5 --irc-announce --net
18783 rav3n      20   0 24800   832   392 S  0.0  0.0  1:50.03 ├─ SCREEN -Udm python /home/rav3n/p2pool/run_p2pool.py -f 0.5 --irc-annou
18784 rav3n      20   0  404M  197M  2168 S  2.0  5.0  2h29:46 │  └─ python /home/rav3n/p2pool/run_p2pool.py -f 0.5 --irc-announce --net
18739 rav3n      20   0 24800   836   392 S  0.0  0.0  0:26.58 ├─ SCREEN -Udm python /home/rav3n/p2pool/run_p2pool.py --merged http://ra
18740 rav3n      20   0  649M  372M  2144 R  7.0  9.4  6h52:12 │  └─ python /home/rav3n/p2pool/run_p2pool.py --merged http://rav3n:bc6ca
13313 rav3n      20   0 1128M  288M 28056 S  1.0  7.3 33:04.50 ├─ bitcoind
 2728 rav3n      20   0 24932   832   328 S  0.0  0.0  0:00.02 ├─ SCREEN -U -d -m /home/rav3n/ts3/ts3server_minimal_runscript.sh
 2729 rav3n      20   0  4396   208   208 S  0.0  0.0  0:00.00 │  └─ /bin/sh /home/rav3n/ts3/ts3server_minimal_runscript.sh
 2738 rav3n      20   0  901M  5688  2420 S  5.0  0.1  3h46:55 │     └─ ./ts3server_linux_amd64
 2672 rav3n      20   0 2874M 1599M  4084 S  0.0 40.4 47:57.38 ├─ i0coind -daemon
 2670 rav3n      20   0  795M  129M  3328 S  0.0  3.3 41:17.24 ├─ ixcoind -daemon
 2668 rav3n      20   0  740M  103M  3548 S  1.0  2.6 40:13.67 ├─ namecoind -daemon
 2666 rav3n      20   0  858M 97412  3480 S  1.0  2.4 43:52.46 ├─ devcoind -daemon
 2501 rav3n      20   0 1213M  123M  2760 S  1.0  3.1  1h02:31 ├─ litecoind -daemon
 2305 rav3n      20   0 1139M 23148  3108 S  0.0  0.6 31:19.56 ├─ terracoind -daemon

I really not see any p2pool memory leak issue... Only that i0coin is killing me :/

[lenny_]

ravn_3pl,
AFAIK you're running a Virtual Machine with absolutely everything (except basic kernel and console access) cutted off. IMO it cannot be compared to results provided by people running it on real servers with many services, older but stable Linux kernel etc. running on same hardware all at once.

[zvs]

OK, my usage started going up again:

Sat Jan 12 2013 16:33:48 GMT-0600 (Central Standard Time)   1.17G
Sat Jan 12 2013 16:31:00 GMT-0600 (Central Standard Time)   1.16G
Sat Jan 12 2013 16:28:12 GMT-0600 (Central Standard Time)   1.16G
Sat Jan 12 2013 16:25:24 GMT-0600 (Central Standard Time)   1.16G
Sat Jan 12 2013 16:22:36 GMT-0600 (Central Standard Time)   1.16G
Sat Jan 12 2013 16:19:48 GMT-0600 (Central Standard Time)   1.15G
Sat Jan 12 2013 16:17:00 GMT-0600 (Central Standard Time)   1.15G
Sat Jan 12 2013 16:14:12 GMT-0600 (Central Standard Time)   1.15G
Sat Jan 12 2013 16:11:24 GMT-0600 (Central Standard Time)   1.15G
Sat Jan 12 2013 16:08:36 GMT-0600 (Central Standard Time)   1.15G
Sat Jan 12 2013 16:05:48 GMT-0600 (Central Standard Time)   1.15G
Sat Jan 12 2013 16:03:00 GMT-0600 (Central Standard Time)   1.14G
Sat Jan 12 2013 16:00:12 GMT-0600 (Central Standard Time)   1.14G
Sat Jan 12 2013 15:57:24 GMT-0600 (Central Standard Time)   1.14G
Sat Jan 12 2013 15:54:36 GMT-0600 (Central Standard Time)   1.14G
Sat Jan 12 2013 15:51:48 GMT-0600 (Central Standard Time)   1.13G
Sat Jan 12 2013 15:49:00 GMT-0600 (Central Standard Time)   1.13G
Sat Jan 12 2013 15:46:12 GMT-0600 (Central Standard Time)   1.13G
Sat Jan 12 2013 15:43:24 GMT-0600 (Central Standard Time)   1.13G
Sat Jan 12 2013 15:40:36 GMT-0600 (Central Standard Time)   1.13G
Sat Jan 12 2013 15:37:48 GMT-0600 (Central Standard Time)   1.12G

it was stable at 1.11-1.12 for a while, last time it stopped after i moved my log file to backup and removed a couple of peers that had changed overnight.   the log file is about 1/5th the size it was earlier, so that's not it.  i haven't done anything on my system

i've had a few peers change.  one of them is >300ms with tons of packetloss and connected at 3PM.    I also moved the log file to backup again at 3:03PM..

nothing in the logfile appears out of the ordinary

going to restart it now  (for the record, since 3PM I've gotten 2 orphans and 1 DOA out of 16 shares.  it was  476 (16 orphan, 16 dead) at 3:03pm

[lenny_]

zvs, how exactly are you removing peers from your p2pool? Or how are you checking their latency?

[zvs]

zvs, how exactly are you removing peers from your p2pool? Or how are you checking their latency?

http://xxx:xxx/peer_addresses shows the peers connected on the web interface... or you can use netstat -p -n --tcp in linux (and look for python).  netstat would work on windows too, but not sure if you can list by program or not... you could tell by the ports, I guess.

There might be a way on the web interface to see latency... there used to be at one point.  I'm not sure what it is anymore, or if it still exists...  I use mtr in linux to check ping times, or from a command prompt in windows you can just use ping -t xx.xx.xx.xx

[lenny_]

I am using Linux too. Thanks.
That's a kind of a hax, by the way. P2pool itself could implement some technique of rolling peers until those with optimal latency are found.
What command you're using to remove peer?
Can you share script you're using to ping peers? I am sure you're using one:) Pinging manually all peers from p2pool_address:port/peer_addresses may take time to do by hand;)

[rav3n_pl]

Banning lagging (basing on ping) peers can split pool to small local pools ie euope, usa etc.
From my side eu peers have <50 ms where us ones are over 100ms. If I put kind of threshold that disconnect slowest peers it will lead to connect only to eu ones.
We not want this afik

[K1773R]

zvs, how exactly are you removing peers from your p2pool? Or how are you checking their latency?

http://xxx:xxx/peer_addresses shows the peers connected on the web interface... or you can use netstat -p -n --tcp in linux (and look for python).  netstat would work on windows too, but not sure if you can list by program or not... you could tell by the ports, I guess.

There might be a way on the web interface to see latency... there used to be at one point.  I'm not sure what it is anymore, or if it still exists...  I use mtr in linux to check ping times, or from a command prompt in windows you can just use ping -t xx.xx.xx.xx

use <IP>:9332/pings

[zvs]

I am using Linux too. Thanks.
That's a kind of a hax, by the way. P2pool itself could implement some technique of rolling peers until those with optimal latency are found.
What command you're using to remove peer?
Can you share script you're using to ping peers? I am sure you're using one:) Pinging manually all peers from p2pool_address:port/peer_addresses may take time to do by hand;)

actually, i did just do it manually.  i had forgotten about 'pings', thanks.

it didn't take that long though, since i had my connections limited to .. 14, I think it was... (12 now)

i use tcpkill to kill peers, it's in the repository as 'dsniff' i think?

re: thing about >100ms,   i said in an earlier msg that it was good that I had some US peers with 130ms.  i don't remove someone at 130ms.  i do if they're at 300ms, or someone that jitters from 150ms to 600ms, stuff like that.  you can make a bunch of screens and just use mtr for a little bit to see if they are having bandwidth issues

[rav3n_pl]

ravn_3pl,
AFAIK you're running a Virtual Machine with absolutely everything (except basic kernel and console access) cutted off. IMO it cannot be compared to results provided by people running it on real servers with many services, older but stable Linux kernel etc. running on same hardware all at once.

Why? We talking about Python, it is connected somehow to hardware running program that only run program that NOT use hardware (only ram and cpu)?

[lenny_]

ravn_3pl,
AFAIK you're running a Virtual Machine with absolutely everything (except basic kernel and console access) cutted off. IMO it cannot be compared to results provided by people running it on real servers with many services, older but stable Linux kernel etc. running on same hardware all at once.

Why? We talking about Python, it is connected somehow to hardware running program that only run program that NOT use hardware (only ram and cpu)?

I don't know, I am not Linux expert:) This may be related to: python version and/or Linux kernel version. Probably it needs more attention from forrestv or someone else able to investigate those memory leaks.

[K1773R]

ravn_3pl,
AFAIK you're running a Virtual Machine with absolutely everything (except basic kernel and console access) cutted off. IMO it cannot be compared to results provided by people running it on real servers with many services, older but stable Linux kernel etc. running on same hardware all at once.

Why? We talking about Python, it is connected somehow to hardware running program that only run program that NOT use hardware (only ram and cpu)?

I don't know, I am not Linux expert:) This may be related to: python version and/or Linux kernel version. Probably it needs more attention from forrestv or someone else able to investigate those memory leaks.

kernel is irrelevant since python is managing the memory of p2pool. it only depends on which python version/build.

[zvs]

http://nogleg.com:9332/static/graphs.html?Week

the memory thing could possibly be linked to establishing an extra outgoing connection that isn't supposed to be established, they seem to coincide with the straight angled mem usage

[K1773R]

http://nogleg.com:9332/static/graphs.html?Week

the memory thing could possibly be linked to establishing an extra outgoing connection that isn't supposed to be established, they seem to coincide with the straight angled mem usage

i got 50 outgoing cons and got 423MB mean usage, so this isnt possible.

[zvs]

http://nogleg.com:9332/static/graphs.html?Week

the memory thing could possibly be linked to establishing an extra outgoing connection that isn't supposed to be established, they seem to coincide with the straight angled mem usage

i got 50 outgoing cons and got 423MB mean usage, so this isnt possible.

well, if your limit is set to 50, have you had 51?

[AV]

With p2pool 11.1
I have drop cgminer or bfgminer, if drop internet connection.
With 10 version this was not.
What can I do ?

[K1773R]

http://nogleg.com:9332/static/graphs.html?Week

the memory thing could possibly be linked to establishing an extra outgoing connection that isn't supposed to be established, they seem to coincide with the straight angled mem usage

i got 50 outgoing cons and got 423MB mean usage, so this isnt possible.

well, if your limit is set to 50, have you had 51?

conns arent limited with my p2pool.
you cant have 51 cons if the limit would be 50.