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

semaster

sr. member

Activity: 395

Merit: 250

zvs, thanks that you care so much about p2pool
if you have some suggestions about efficiency of http://elizium.name write me please.
this node based on an excellent server with a lot of memory, bandwidth, good pings, 99.9% uptime so there is a lot of reasons to use it any ways

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

it looks like their plan so far has been rotating null routing? wtf..

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

ed: fixed name

As far as the [email protected] (awfully similar to the person mining under "[email protected]_batman" on pool), I did notice this:

nm, that info was too old. there are a few reports of email spam coming from [email protected], but i doubt that really has any relevance

maybe the non-clearing sockets are just a side effect of hetzner having some rather serious issues atm? that would be a bug within python I guess?

heh,

Type:   Fault report
Categories:   Network
Start:   November 17, 2013 1:30:00 PM CET
End:   Unknown
Description:   We have unfortunately just experienced a large incoming attack on a server in RZ19.

We have resolved the issue and are currently dropping the udp traffic for 144.76.36.0/27. It appears the Attack switches targets, we'll may need to put additional IP or Subnet on this filter rules.

We apologize for any inconvenience caused.

Thank you for your understanding.

... my point about the sockets not closing still stands tho... I was having that problem *before* this was announced =p

.. and it isn't resolved, still get about 60% ploss to hetzner.de... 144.76.36, some bitcoin pool there? heh

jedimstr

hero member

Activity: 798

Merit: 1000

Quote from: zvs on November 17, 2013, 07:57:50 AM

...snip...

That wouldn't be causing it to get the 4thash then... Grin

....snip...

I wish...

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

Quote from: jedimstr on November 17, 2013, 12:04:09 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?

I use Elizium for one of my backup failovers so I can keep on p2pool when my local node is updated and needs to restart. Secondary Backup on BTCGuild. Elizium's current efficiency of 105% isn't bad and they have decent uptime and ping from my location. Of course I only need them for the minute or so when I'm restarting the node after a git pull or the few minutes I need to do a full reboot and system maintenance.

That wouldn't be causing it to get the 4thash then... Grin

Uh, I think all these bizarre miners on my node are just someone loading me up with TCP sockets that never close.

The daily chart at the moment has quite a few:

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

This Kyle Rubenok fellow in particular doesn't really seem like a bitcoin miner to me. I've tried to contact a few of those ppl, anyway

Here's an example from dstat:

Code:

------sockets------ --net/eth0- -dsk/total- ---load-avg--- ----interrupts---
tot tcp udp raw frg| recv send| read writ| 1m 5m 15m | 44 54 55
981 940 3 0 0| 108k 603k| 0 0 |0.09 0.21 0.22| 0 0 1403
982 940 3 0 0| 243k 1255k| 0 0 |0.16 0.22 0.23| 0 0 3291
982 940 3 0 0| 79k 622k| 0 24k|0.16 0.22 0.23| 7 0 1092
984 942 3 0 0| 168k 991k| 112k 80k|0.16 0.22 0.23| 18 0 2319
987 945 3 0 0| 289k 911k| 52k 0 |0.16 0.22 0.23| 4 0 1473
987 945 3 0 0| 313k 992k| 0 0 |0.16 0.22 0.23| 0 0 1633
987 945 3 0 0| 284k 881k| 0 0 |0.15 0.22 0.23| 0 0 844
987 945 3 0 0| 181k 1163k| 0 0 |0.27 0.25 0.23| 0 0 2430
987 945 3 0 0| 45k 625k| 0 0 |0.27 0.25 0.23| 0 0 786
989 947 3 0 0| 30k 353k| 0 0 |0.27 0.25 0.23| 0 0 473
992 950 3 0 0| 130k 786k| 0 16k|0.27 0.25 0.23| 4 0 1593
992 950 3 0 0| 56k 418k| 0 0 |0.25 0.24 0.23| 1 0 715
992 950 3 0 0| 190k 1110k| 0 0 |0.25 0.24 0.23| 0 0 2562
992 949 3 0 0| 72k 2964k| 0 0 |0.25 0.24 0.23| 0 0 1437
992 949 3 0 0| 146k 3193k| 0 24k|0.25 0.24 0.23| 6 0 2251
994 951 3 0 0| 94k 3100k|2048k 0 |0.25 0.24 0.23| 5 0 1342
998 955 3 0 0| 73k 3181k| 0 0 |0.23 0.24 0.23| 0 0 1295
998 955 3 0 0| 106k 3168k|2048k 0 |0.23 0.24 0.23| 5 0 1383
998 955 3 0 0| 46k 2527k| 0 0 |0.22 0.24 0.23| 0 0 993
997 954 3 0 0| 122k 1866k| 0 0 |0.22 0.24 0.23| 0 0 1815
997 954 3 0 0| 43k 2023k| 0 0 |0.22 0.24 0.23| 0 0 981
998 955 3 0 0| 48k 2575k| 0 568k|0.22 0.24 0.23| 8 0 1047
998 955 3 0 0| 92k 4088k| 0 0 |0.22 0.24 0.23| 0 0 1328
998 955 3 0 0| 104k 3917k| 0 0 |0.28 0.25 0.23| 0 0 1279
998 955 3 0 0| 96k 4044k| 0 0 |0.28 0.25 0.23| 0 0 1315

the 1st and 2nd numbers being of interest (it was 900 to 1000 in a minute or so)

this also caused a stratum disconnect & some lost shares, though I'm not sure if that's even related to this, since Hetzner itself is getting 600ms ping times and hardcore packetloss as well...

Some ping stats around the same time:

Code:

Reply from 5.9.24.82: bytes=32 time=185ms TTL=46
Reply from 5.9.24.82: bytes=32 time=185ms TTL=46
Reply from 5.9.24.82: bytes=32 time=181ms TTL=46
Reply from 5.9.24.82: bytes=32 time=185ms TTL=46
Reply from 5.9.24.82: bytes=32 time=185ms TTL=46
Reply from 5.9.24.82: bytes=32 time=185ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=184ms TTL=46
Reply from 5.9.24.82: bytes=32 time=183ms TTL=46
Reply from 5.9.24.82: bytes=32 time=182ms TTL=46
Reply from 5.9.24.82: bytes=32 time=181ms TTL=46
Reply from 5.9.24.82: bytes=32 time=181ms TTL=46
Reply from 5.9.24.82: bytes=32 time=179ms TTL=46
Reply from 5.9.24.82: bytes=32 time=185ms TTL=46
Reply from 5.9.24.82: bytes=32 time=181ms TTL=46
Reply from 5.9.24.82: bytes=32 time=185ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Request timed out.
Request timed out.
Reply from 5.9.24.82: bytes=32 time=281ms TTL=46
Reply from 5.9.24.82: bytes=32 time=281ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=281ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=281ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=278ms TTL=46
Request timed out.
Request timed out.
Reply from 5.9.24.82: bytes=32 time=278ms TTL=46
Reply from 5.9.24.82: bytes=32 time=281ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=281ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Request timed out.
Request timed out.
Reply from 5.9.24.82: bytes=32 time=281ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Request timed out.
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Request timed out.
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=280ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Request timed out.
Request timed out.
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46
Request timed out.
Request timed out.
Reply from 5.9.24.82: bytes=32 time=279ms TTL=46

Ping statistics for 5.9.24.82:
Packets: Sent = 5596, Received = 5491, Lost = 105 (1% loss),
Approximate round trip times in milli-seconds:
Minimum = 179ms, Maximum = 286ms, Average = 186ms

Pinging google.com [74.125.227.238] with 32 bytes of data:
Reply from 74.125.227.238: bytes=32 time=46ms TTL=56
Reply from 74.125.227.238: bytes=32 time=46ms TTL=56

Ping statistics for 74.125.227.238:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 46ms, Maximum = 46ms, Average = 46ms

Pinging 5.9.24.81 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 5.9.24.81: bytes=32 time=605ms TTL=47
Request timed out.
Reply from 5.9.24.81: bytes=32 time=604ms TTL=47
Request timed out.
Reply from 5.9.24.81: bytes=32 time=600ms TTL=47
Reply from 5.9.24.81: bytes=32 time=594ms TTL=47
Reply from 5.9.24.81: bytes=32 time=604ms TTL=47
Reply from 5.9.24.81: bytes=32 time=600ms TTL=47
Request timed out.
Reply from 5.9.24.81: bytes=32 time=599ms TTL=47
Reply from 5.9.24.81: bytes=32 time=598ms TTL=47
Request timed out.
Reply from 5.9.24.81: bytes=32 time=603ms TTL=47
Request timed out.
Reply from 5.9.24.81: bytes=32 time=599ms TTL=47
Reply from 5.9.24.81: bytes=32 time=598ms TTL=47
Request timed out.

Ping statistics for 5.9.24.81:
Packets: Sent = 22, Received = 11, Lost = 11 (50% loss),
Approximate round trip times in milli-seconds:
Minimum = 594ms, Maximum = 605ms, Average = 600ms

Pinging hetzner.de [213.133.107.227] with 32 bytes of data:
Request timed out.
Reply from 213.133.107.227: bytes=32 time=599ms TTL=47
Request timed out.
Reply from 213.133.107.227: bytes=32 time=599ms TTL=47
Reply from 213.133.107.227: bytes=32 time=598ms TTL=47
Reply from 213.133.107.227: bytes=32 time=598ms TTL=47
Request timed out.
Reply from 213.133.107.227: bytes=32 time=594ms TTL=47
Request timed out.
Reply from 213.133.107.227: bytes=32 time=593ms TTL=47
Reply from 213.133.107.227: bytes=32 time=593ms TTL=47
Request timed out.
Reply from 213.133.107.227: bytes=32 time=589ms TTL=47
Reply from 213.133.107.227: bytes=32 time=594ms TTL=47
Reply from 213.133.107.227: bytes=32 time=589ms TTL=47
Reply from 213.133.107.227: bytes=32 time=574ms TTL=47
Request timed out.
Request timed out.
Reply from 213.133.107.227: bytes=32 time=493ms TTL=47
Reply from 213.133.107.227: bytes=32 time=498ms TTL=47
Reply from 213.133.107.227: bytes=32 time=457ms TTL=47

I don't see why so many people would mine w/ invalid addresses to a p2pool node, honestly. I mean, I've had a big warning written up there for several weeks now.

A couple of the "real" addresses have zero total transactions, but a few are active....

So, are all these locked sockets just being caused by Hetzner's network getting messed up, is there really a dozen or two people not using a valid bitcoin address mining to me over the last week?

Does anyone else get hundreds of dead sockets to 9332?

revilo

sr. member

Activity: 543

Merit: 250

Hi guys,
I'm new to Mining BTC with P2Pool as I have always been an LTC miner!
I've setup my pool
pool.play4.co.uk:9332
And I'm hashing at approx 10GH/s

Estimated time to share is about 1 day! Is there anyway to lower this share target or do I just need more miners on here to speed things up?

P.S
Anybody that wants to join in with my pool please feel free it's 0% fee

jedimstr

hero member

Activity: 798

Merit: 1000

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?

I use Elizium for one of my backup failovers so I can keep on p2pool when my local node is updated and needs to restart. Secondary Backup on BTCGuild. Elizium's current efficiency of 105% isn't bad and they have decent uptime and ping from my location. Of course I only need them for the minute or so when I'm restarting the node after a git pull or the few minutes I need to do a full reboot and system maintenance.

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

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?

Carlton Banks

legendary

Activity: 3430

Merit: 3083

To all p2pool users:

Please consider using the patched Bitcoin main client that de-prioritises re-used addresses patched Bitcoin main client that de-prioritises re-used addresses. This will not affect the processing of payments to the addresses that p2pool users all re-use for our reward payments, as confirmed by the author of the patch.

The future value of everyone's Bitcoin depends on removing the effectiveness of the coloured lists. De-prioritising re-used addresses will make Green listed addresses unattractive, and hopefully it will be possible to change the culture, using HD keychains, to need to re-use addresses by anyone, including making mining with an alternating address a reality (which can only be a privacy enhancement).

forrestv, please consider the options. Right now, it is possible that p2pool could benefit from moving to a self defined username model, with the p2pool client requesting a new public key for reward payments each time we hit a new round. Possibly this could introduce problems with orphaning blocks that are found consecutively, on the rare occasions that this has occured on p2pool. In the future, enabling the use of BIP32 keychains for reward payment is also an option. Do not be concerned that this is a privacy issue, multiple keychains can be created per wallet, and so you can create a specific keychain to use only with p2pool or whoever else you wish to mine with.

Support the discouraging of address re-use.

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

d'oh, I hadn't reset it yet and someone started.... and I got the 1/100 chance of the share.. still putting together a p2pool-node list =/

oh, it's set to wrong name, anyway... have to use payout address Undecided

ok, i think the whole interrupt thing should be fixed now, and it's set back to 0%

ed: haha, figures that hetzner's network starts messing up right after i fix that. it's definitely reissuing the work faster now though, so no 1-2 second delay there if it goes 90 seconds w/o anything. at least when hetzner isn't getting 20% ploss and 400ms ping times

canth

legendary

Activity: 1442

Merit: 1001

Quote from: gnar1ta$ on November 15, 2013, 11:13:23 PM

What flags are you using for cgminer? I have had a dozen types of miners including a Jupiter on my node and they always fail over fine to my backup pool when I take the node down for maintenance. failover-only is the only thing I add to my conf for ASICs.

No flags set - it's essentially a default Jupiter but with 4 pools for failover. The symptom I've recently seen has been 2 Jupiters which stop hashing at the exact same time. When investigated, cgminer is no longer running, screen is no longer running. This behavior has not happened on other pools - only on p2pool and now twice in less than a week.

Failover works correctly for other non-p2pools. With the combination of no idle worker alerts and this crashing behavior, it's just easier and safer to use standard pools. Looking forward to when p2pool gets an alert feature.

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

Quote from: maqifrnswa on November 15, 2013, 12:10:06 PM

@zvs: When I'm mining on your node, and it goes down, my cgminer client totally locks up and stops working. Other nodes, however, don't have that problem and cgminer properly switches to failover nodes. Has anyone else seen this on your node? I don't remember the error it gave; I stopped mining on it after it happened a few times (3 times last week).

I thought about it some more... since this behavior should be common to all p2pools (stratum "interrupted" after a 90s period of no block/new work), mine shouldn't cause a disconnect/lockup/whatever any more (or less) frequently than any others.

Maybe latency has something to do with it? A really small window for stratum to reconnect? Huh

If you're in the US, 198.12.127.2 should have low latency... I'll drop the fee on it to 0%, anyway (ed: in about 10-15 minutes, have to check log and redo --p2pool-node's and such)... if ANYONE wants to mess with it.

I assume that port 9332 works, though it does seem a bit odd that not one person has mined on there in 2-3 weeks though

ok, done. i changed something in the code that might or might not do something as well

198.12.127.2:9332, has 0% fee now

ed: i just tested it myself. had the 90s delay, didn't get an interrupted on my vid card, so i think i fixed it. i'll reset 5.9.24.81 in a bit and put it back to 0% for a while

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

The question is if KnC has fixed the 10s LP issue (10s job reset)
... a KnC takes 10s to do an LP
So with that issue, 33% of your mining time on p2pool is ... idle.

gnar1ta$

donator

Activity: 798

Merit: 500

Quote from: matthewh3 on November 15, 2013, 04:57:23 PM

Quote from: maqifrnswa on November 15, 2013, 12:47:43 PM

Quote from: matthewh3 on November 15, 2013, 12:19:28 PM

Quote from: maqifrnswa on November 15, 2013, 12:10:06 PM

@zvs: When I'm mining on your node, and it goes down, my cgminer client totally locks up and stops working. Other nodes, however, don't have that problem and cgminer properly switches to failover nodes. Has anyone else seen this on your node? I don't remember the error it gave; I stopped mining on it after it happened a few times (3 times last week).

This keeps happening to us on OGnasty's node and we've had to take 1.1TH off P2Pool because of this plus we'll have 650GH/s Jupiter soon to hash on as well. So that's 1.75TH/s for P2Pool if anyone can help us. Does anyone have a list of the nodes you mention that enable a fallover?

Edit: Although my friend hosting the miners says it's cgminer actually crashing and is a cgminer problem.

it is a cgminer problem, I think I found some info here:
https://bitcointalksearch.org/topic/cgminer-stratum-connection-to-pool-0-interrupted-issue-188533

funny thing is that OgNasty's node failsover fine for me! I have much smaller hashrate, maybe that has something to do with it too.

KNC have released a new firmware update today. If anyone finds out this stops the cgminer P2Pool for KNC Jupiters bug let me know and the pool will gain 1.75TH.

What flags are you using for cgminer? I have had a dozen types of miners including a Jupiter on my node and they always fail over fine to my backup pool when I take the node down for maintenance. failover-only is the only thing I add to my conf for ASICs.

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

Quote from: jedimstr on November 15, 2013, 11:32:09 AM

Quote from: zvs on November 15, 2013, 10:36:33 AM

Quote from: phillipsjk on November 15, 2013, 01:59:32 AM

Quote from: zvs on November 11, 2013, 02:02:39 AM

tip #7: compile bitcoind with outgoing connections of 1, run bitcoind with listen=1, maxconnections=2, with one node on connect... well, that's what I do, since I can monitor it constantly.. you'd probably want to change maxconnections to 3 or 4, in case one of the nodes craps out, be it due to the Interpol, cult of the dead cow, or whatever else. an example conf file,

While a low number of connections may save bandwidth, wouldn't it possibly have the side-effect of making the Bitcoin network less resilient?

I guess I will see how much bandwidth is used when I finally get my node up.

yeah, but if you are trying to run a node locally and are bandwidth starved, that's something you should do.

otherwise you'll either randomly connect to an outgoing peer that is missing part of the block chain or have one connect to you. then your upstream is saturated

i think it's not so bad in other parts of the world, but in the US, you really get gimped on upstream

Not all of us... I've got 75down/35up rated (typically 86down/39up actual). FiOS kicks a$$.

Running a local node at galactica.geekgalaxy.com:9332
Any tips? Wink

no, i like your outgoing connections =p

zvs

legendary

Activity: 1680

Merit: 1000

https://web.archive.org/web/*/nogleg.com

Quote from: maqifrnswa on November 15, 2013, 12:10:06 PM

@zvs: When I'm mining on your node, and it goes down, my cgminer client totally locks up and stops working. Other nodes, however, don't have that problem and cgminer properly switches to failover nodes. Has anyone else seen this on your node? I don't remember the error it gave; I stopped mining on it after it happened a few times (3 times last week).

I think this is caused by the stratum interrupts when the p2pool doesn't find a new share for 90 seconds?

It says something about it when I have my video card pointed there too, stops for about 1/2 a second also, but i'm using some .. 6 month old version of cgminer

maybe it works properly now, i dunno

but that's when it happens. when there is no new block or no new share for 90 seconds

ed: it should be common to any p2pool? my video card starts back up right away on cgminer 3.3.4, it just says stratum connection was interrupted and then restarts

matthewh3

legendary

Activity: 1372

Merit: 1003

Quote from: maqifrnswa on November 15, 2013, 12:47:43 PM

Quote from: matthewh3 on November 15, 2013, 12:19:28 PM

Quote from: maqifrnswa on November 15, 2013, 12:10:06 PM

@zvs: When I'm mining on your node, and it goes down, my cgminer client totally locks up and stops working. Other nodes, however, don't have that problem and cgminer properly switches to failover nodes. Has anyone else seen this on your node? I don't remember the error it gave; I stopped mining on it after it happened a few times (3 times last week).

This keeps happening to us on OGnasty's node and we've had to take 1.1TH off P2Pool because of this plus we'll have 650GH/s Jupiter soon to hash on as well. So that's 1.75TH/s for P2Pool if anyone can help us. Does anyone have a list of the nodes you mention that enable a fallover?

Edit: Although my friend hosting the miners says it's cgminer actually crashing and is a cgminer problem.

it is a cgminer problem, I think I found some info here:
https://bitcointalksearch.org/topic/cgminer-stratum-connection-to-pool-0-interrupted-issue-188533

funny thing is that OgNasty's node failsover fine for me! I have much smaller hashrate, maybe that has something to do with it too.

KNC have released a new firmware update today. If anyone finds out this stops the cgminer P2Pool for KNC Jupiters bug let me know and the pool will gain 1.75TH.

maqifrnswa

sr. member

Activity: 454

Merit: 252

Quote from: matthewh3 on November 15, 2013, 12:19:28 PM

Quote from: maqifrnswa on November 15, 2013, 12:10:06 PM

@zvs: When I'm mining on your node, and it goes down, my cgminer client totally locks up and stops working. Other nodes, however, don't have that problem and cgminer properly switches to failover nodes. Has anyone else seen this on your node? I don't remember the error it gave; I stopped mining on it after it happened a few times (3 times last week).

This keeps happening to us on OGnasty's node and we've had to take 1.1TH off P2Pool because of this plus we'll have 650GH/s Jupiter soon to hash on as well. So that's 1.75TH/s for P2Pool if anyone can help us. Does anyone have a list of the nodes you mention that enable a fallover?

Edit: Although my friend hosting the miners says it's cgminer actually crashing and is a cgminer problem.

it is a cgminer problem, I think I found some info here:
https://bitcointalksearch.org/topic/cgminer-stratum-connection-to-pool-0-interrupted-issue-188533

funny thing is that OgNasty's node failsover fine for me! I have much smaller hashrate, maybe that has something to do with it too.

matthewh3

legendary

Activity: 1372

Merit: 1003

Quote from: maqifrnswa on November 15, 2013, 12:10:06 PM

@zvs: When I'm mining on your node, and it goes down, my cgminer client totally locks up and stops working. Other nodes, however, don't have that problem and cgminer properly switches to failover nodes. Has anyone else seen this on your node? I don't remember the error it gave; I stopped mining on it after it happened a few times (3 times last week).

This keeps happening to us on OGnasty's node and we've had to take 1.1TH off P2Pool because of this plus we'll have 650GH/s Jupiter soon to hash on as well. So that's 1.75TH/s for P2Pool if anyone can help us. Does anyone have a list of the nodes you mention that enable a fallover?

Edit: Although my friend hosting the miners says it's cgminer actually crashing and is a cgminer problem.

maqifrnswa

sr. member

Activity: 454

Merit: 252

@zvs: When I'm mining on your node, and it goes down, my cgminer client totally locks up and stops working. Other nodes, however, don't have that problem and cgminer properly switches to failover nodes. Has anyone else seen this on your node? I don't remember the error it gave; I stopped mining on it after it happened a few times (3 times last week).

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