slick with the 2012 registration date, with a first post in .. gasp... june of 2014.  how much did you pay bubba for that account?

the same thing is happening to me, re: litecoin.  i didnt want to post here since i figured it was just something dumb i was doing.

in my case, it starts at 0 and slowly increases and then evens out around 0.002 difficulty,  which gets some godawful number of HW failures and about 1/2 hash rate.

"fix-protocol": true,

in the config file fixes this,  that is, using  longpolling instead of stratum

it's at nogleg.com:9326 atm.  tried setting up some stratum proxy that failed miserably too, hence the 9326 port.  no clue.  long polling works but it creates a ton of connections.  it also seems to get more DOA, but then, i usually don't get 16mhash from my X3

ed: i was running a doge scrypt p2pool like 3 days ago, w/o any problems.  i also need to fix my --p2pool-node list, but not until i get stratum working properly ^_^

It's gotta be DOSBox!  That's probably why it's not working as well ...

lol "instahater".  has anyone else noticed that these shills all have similar names?

where is ru4srs

First off, re: this guide, this was on my DOGE pool, but since it's down now:

Since all the "guides" are wrong, I'll talk a little bit about latency when choosing a p2pool. This DOGE pool setup has 15s shares and 60s blocks, for five interruptions per minute. So assume you have a very high 200ms latency (and no packetloss, packetloss *IS* a big deal)... your system will continue working on an old share for 0.2s and it'll take an additional >0.2s for the server to send you out the new share information (well, plus 1-5ms overhead).... so, basically, 400ms per interruption is your DOA window.  5x400ms = 2s, 2 out of 60 = 3.33% DOA. For other coins it's even less of a factor (bitcoin with the 20s share times and the much longer block periods).  I found it wasn't worth mining on my machine locally since I ended up with tons more orphans.  European nodes in general will get less orphans & orphan rate should be the primary factor in determining the best pool. If you get 50ms latency to pool A and 200ms latency to pool B, then pool A would only be better if the orphan rate was an absolute ~2.5% or so lower than pool B.  If not, pool B is better... regardless of the DOAs looking bad on your miner or not...

Bitcoin share time is 30s, so that's even less interrupts.


I don't remember what the advice says at the beginning of this thread, but a lot of it has always been wrong.

I don't see a reason to set a higher share difficulty level unless you like gambling (the /2000 part)...  If you are on a pool that is 2TH, then that 512 will be lower than the default.  All it's used for is to calculate your hash rate and display it on the p2pool graphs.  The lower it is, the more data you'll transfer and the more accurate your hash rate graph will be.

Not sure how you can make a blanket statement about low latency, I mean, I'm sure lots of people in Europe have sub 50ms to my Hetzner server, but I don't.  re: 2TH and no shares, that's because the base p2pool code attempts to "equalize" the shares each pool gets.  I guess 2TH isn't a whole lot for bitcoins anymore, I have no clue.  For scrypt, let's say litecoin p2pools are at 5GH/s total, a node mining litecoins at 5MH/s will be at base share difficulty (the amt used to "attempt" to get one share every 30s network-wide), while a node at 200MH/s will have a share difficulty 20x + of the 5MH/s node.

and it's reasons like this why orphan % is much more important to look at than DOA, if you're mining on some p2pool other than your own.

every "guide" i've seen either says to select the lowest latency p2pool or whichever is 'closest' to you.  *boggle*

my lower orphan rate on my germany server more than made up for the near zero DOA I got from running locally.  it's simple to calculate expected DOA %'s based on latency, as long as there is little to no packetloss (should be less than 1%)

osx?

I think the range has been from 15% to 35% over the last year or so.  Probably averages around 22 or 23.  More than double 10%.

ed2:  lol @ lol, maybe change that 35% to a 50%.  more like change that 50% into a 75%, wtf.

1) no
2) no
3) not long enough

1) No
2) None
3) Which?

Well, I was considering setting up a Litecoin pool with DOGE merged mining (maybe some others, but not too concerned about those since they're worth some tiny fraction of DOGE)... but w/ existing p2pool, I don't think that can be done.  It would need a signup of some sort to get the person's DOGE payout address & connect that to the Litecoin address they're mining to.  I guess I could use something like MPOS but not really keen on that, hah

ed: oh, and my doge node is like 5-10% more efficient then any of the others, outside of a few that are probably mined locally, like taken.pl:22552/static/ ... orphan control!   i've also seen more misinformation about lowest ping time being best, my node tells it like it is =p

ed2: like whomever is on http://p2doge.bkhashing.co:22550/static/  would have made a lot more money on my pool, even if that node is local/close to them.  sure, the DOA is low, but the orphan rate is insane.   shame I'll be shutting it tomorrow 

haha, that 1st page is making my brain hurt.  

re: mrflibblehat, that rrd thing should be able to convert those ping times to ms as well.

my bitcoin-cli for example shows;

"pingtime" : 0.13562600
"pingtime" : 2.79798200,
"pingtime" : 0.05269900,
"pingtime" : 0.19598100,

etc... which I believe are 135ms, 2.8s, 52ms, and 196ms?  the 2.8s one also has a "pingwait" : 582.27381700 ... i'm guessing he's DLing the blockchain and computer is overloaded or something.

oh, i thought the charts on #2 looked cool.. just not something I could use, since it's still just taking all traffic & I have many things running heh

Is there a guide and/or code somewhere to automate merge mining payouts w/ p2pool now?  I haven't kept up to date in a long time..

Did you try downloading the latest version of bitcoin?  There was some headers only version on the git for a while that would cause it to do that every time you reloaded, I think

if that's not it, you should probably run a nice, long memtest86.  well, scan the HDD for errors first

p2pool wouldn't be causing it, would have to be related to the bitcoin client

hmm, I'll try a more current version.  It was based on 0.9.1..

Are they taking the namecoins, ixcoins, and w/e else as well?  lol

ah, looking good.  like a clone of 176.10.116.242, but not so polished yet.  =p

I guess you were syncing with blockchain, w/ those downloaded amounts...  shame about the BQS nodes..   things like that are one of the reasons ppl complain about slow syncs.  I think it takes .. 3 minutes? ... before it asks another peer for those blocks.

I sent .01 to 13qDi8k6cPvwAEDVGL7TYrGcAgEtKb22jt a while back (176.10.116.242 fellow)..   slick it up some and I'd send $5 or $10 or something.  =p   

I prefer the gray/white/black color scheme...   also, re: 176.10.116.242 and the ping times... if you could have it adjust those to ms that'd be a step up.  Another thing it's lacking is total amount sent & total amount received (which would include the peers it has connected to & disconnected from).  I *think* that information is available in bitcoin-cli, but not positive.

also, there sure are a lot of dead nodes that just receive info and never send anything out (on 176.10.116.242, 130.253.21.121, 195.113.161.13, 219.243.208.60 amongst others appear to just be wasting inbound slots)... *boggle*

Haha 

I'll just say that it's faster connecting to 1 peer, not 20 or 30.  Just choose the right peer

more people registered a couple months ago getting shit, apparently

maybe with gawminers you lose less than with these other places?

folks, use your brain before throwing money away on garbage like this