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

[Krak]

what's the matter?
http://img.aalun.com/di/MHWH/p2pool.png
win7 x64, Bitcoin-qt 0.7

Is port 9333 being blocked by a firewall or something on your network? That's the only thing I can think of.

[1714833958]

1714833958

[1714833958]

1714833958

[1714833958]

1714833958

[1714833958]

1714833958

[rav3n_pl]

what's the matter?
http://img.aalun.com/di/MHWH/p2pool.png
win7 x64, Bitcoin-qt 0.7

Is port 9333 being blocked by a firewall or something on your network? That's the only thing I can think of.

Or it is already used by another application, maybe you running p2pool 2nd time?

[jiyu_shi]

what's the matter?
http://img.aalun.com/di/MHWH/p2pool.png
win7 x64, Bitcoin-qt 0.7

Is port 9333 being blocked by a firewall or something on your network? That's the only thing I can think of.

Or it is already used by another application, maybe you running p2pool 2nd time?

it's right! l closed litcoin-qt and it ran successfully!

[rav3n_pl]

what's the matter?
http://img.aalun.com/di/MHWH/p2pool.png
win7 x64, Bitcoin-qt 0.7

Is port 9333 being blocked by a firewall or something on your network? That's the only thing I can think of.

Or it is already used by another application, maybe you running p2pool 2nd time?

it's right! l closed litcoin-qt and it ran successfully!

Code:

        Litecoin's use of ports 9332 and 9332 conflicts with P2Pool running on
        the Bitcoin network. To avoid problems, add these lines to litecoin.conf
        and restart litecoind:
            rpcport=10332
            port=10333

And UR ready to go BTC+LTC

[rav3n_pl]

Pool rate: 400GH/s (7.5% stale) Share difficulty: 930
WTF?
Share diff is hittin roof! Last time it was ~900 on 450-500GH.
Some change in latest code?

Probably more separate miners not volunteering a higher share difficulty.

Pool rate: 385GH/s (12% stale) Share difficulty: 750

Not getting it, it should be linear?

[rav3n_pl]

Pool rate: 375GH/s (10% stale) Share difficulty: 796
O_o
Rate down - SD up??? wth?

Anyway, 55% of network is v4 and v5 so v3 users are spammed by "upgrade now" messages

edit:
Pool rate: 358GH/s (9.3% stale) Share difficulty: 664

Still have no idea what it is calculated.

Network update status:
v5: 43%
v4: 14%
v3: 41%

Time to upgrade

[salfter]

What's responsible for P2Pool's current run of bad luck? Currently, it's been 29 hours (and counting) since the pool last found a block. The last three blocks (excluding the orphan) also took longer than expected...in one case, more than 2.5x longer. Is this a sign of something going wrong, an indication of an anomaly with the larger Bitcoin network, or is it just some unusually bad luck that we're stuck riding out?

[mdude77]

What's responsible for P2Pool's current run of bad luck? Currently, it's been 29 hours (and counting) since the pool last found a block. The last three blocks (excluding the orphan) also took longer than expected...in one case, more than 2.5x longer. Is this a sign of something going wrong, an indication of an anomaly with the larger Bitcoin network, or is it just some unusually bad luck that we're stuck riding out?

My theory, based on experience, is when the hashrate gets above 300gh, things go south.  I consider it a scaling problem.  Others seem to disagree.

Eventually what happens is enough people leave because of the bad run that it drops below 300gh, then things gets better.  Thing is, they get too good, then people come back and it goes back up above 300gh. 

M

[Aseras]

The new version seems to have a memory problem. I'm on a box with 32gb of ram and it will crash after 5-6 hours with a out of memory error, and run_p2pool.exe hogging it all.

[twmz]

My theory, based on experience, is when the hashrate gets above 300gh, things go south.  I consider it a scaling problem.  Others seem to disagree.

Eventually what happens is enough people leave because of the bad run that it drops below 300gh, then things gets better.  Thing is, they get too good, then people come back and it goes back up above 300gh. 

I can't conceive of a scenario where a scaling problem could be responsible for bad luck.  Scaling problems causing more stale shares or more orphaned blocks?  Sure.  Scaling problems making math stop working?  How, exactly could the size of the network have an impact on the likelihood that random numbers are below a defined target?

Just because I can't conceive of it, doesn't necessarily mean it isn't possible, but given an understanding of how this all works, it seems extremely unlikely to be related to scaling.

What's responsible for P2Pool's current run of bad luck?

You said it: bad luck.

[mdude77]

The new version seems to have a memory problem. I'm on a box with 32gb of ram and it will crash after 5-6 hours with a out of memory error, and run_p2pool.exe hogging it all.

Try running the python version.  I'm using it on a 4gb box and after 56 hours it's using 200meg of memory.

M

[salfter]

The new version seems to have a memory problem. I'm on a box with 32gb of ram and it will crash after 5-6 hours with a out of memory error, and run_p2pool.exe hogging it all.

FWIW, I have it (and bitcoind and cgminer) running on a box with 1 GB. I've only run into memory shortage issues when compiling newer versions of bitcoind.

[mdude77]

My theory, based on experience, is when the hashrate gets above 300gh, things go south.  I consider it a scaling problem.  Others seem to disagree.

Eventually what happens is enough people leave because of the bad run that it drops below 300gh, then things gets better.  Thing is, they get too good, then people come back and it goes back up above 300gh. 

I can't conceive of a scenario where a scaling problem could be responsible for bad luck.  Scaling problems causing more stale shares or more orphaned blocks?  Sure.  Scaling problems making math stop working?  How, exactly could the size of the network have an impact on the likelihood that random numbers are below a defined target?

Just because I can't conceive of it, doesn't necessarily mean it isn't possible, but given an understanding of how this all works, it seems extremely unlikely to be related to scaling.

I'm stating from what I've observed.  Every time the pool hash rate goes > 300gh, things go south.  When it drops back down, things go better.  It could be coincidence that it happens every single time I guess.

When we're below 300gh, yes, we have bad runs, but the good runs always outnumber the bad.  When we get above, the trend reverses.

<shrug>

M

[jiyu_shi]

I run litcoin with "litecoin.conf":
    rpcuser=abc
    rpcpassword=123
    server=1
    rpcport=10332
    port=10333

and then run:
    run_p2pool --net litecoin -w 10032 abc 123

it returns:


also try:
    run_p2pool --net litecoin --p2pool-port 10032 abc 123

itreturns:


so,will anybody help me?Thanks!

[kjj]

-w tells p2pool what port to listen for miners on, not what port to connect to.

try --bitcoind-rpc-port 10332 --bitcoind-p2p-port 10333

I'm just looking at main.py.  I don't know if specifying the --net litecoin option changes the names of those two options or not.  It doesn't appear to.

[jiyu_shi]

-w tells p2pool what port to listen for miners on, not what port to connect to.

try --bitcoind-rpc-port 10332 --bitcoind-p2p-port 10333

I'm just looking at main.py.  I don't know if specifying the --net litecoin option changes the names of those two options or not.  It doesn't appear to.

it runs successfully!

[rav3n_pl]

-w tells p2pool what port to listen for miners on, not what port to connect to.

try --bitcoind-rpc-port 10332 --bitcoind-p2p-port 10333

I'm just looking at main.py.  I don't know if specifying the --net litecoin option changes the names of those two options or not.  It doesn't appear to.

it runs successfully!

If you have correct litecoin.conf
run_p2pool --net litecoin
should be enough to run p2pool properly. It reads data (ports, user, password) from config file.
Also remember to restart litecond after you change config file.

In mean time 70% of network is on v5 already

[Ed]

LAN and WAN miners has deepbit as backup pool, when DOA is go to 100% I am manually close port, then
they automatically switch to deepbit and working with DOA 0.45%

as I can see p2pool and deepbit is not compatible in multipool cgminer sheme
if cgminer goes from p2pool (main) to deepbit (backup), and going back to p2pool, longpooling stop functioning and all work going rejected

everything, bitcoind, p2pool, cgminer is last versions

[twmz]

LAN and WAN miners has deepbit as backup pool, when DOA is go to 100% I am manually close port, then
they automatically switch to deepbit and working with DOA 0.45%

as I can see p2pool and deepbit is not compatible in multipool cgminer sheme
if cgminer goes from p2pool (main) to deepbit (backup), and going back to p2pool, longpooling stop functioning and all work going rejected

everything, bitcoind, p2pool, cgminer is last versions

Correct.  You can not mix p2pool and non-p2pool entries in the same cgminer instance.  

P2Pool, the distributed network itself, is essentially never "down".  If you want a backup to your personal p2pool node being down, use someone else's public p2pool node as a backup (there is a thread here somewhere with a list of public p2pool servers) and specify your bitcoin address as the username.

[rav3n_pl]

Public nodes list:
http://nodes.p2pmine.com/

You can verify fee of pool using http://node:port/fee