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

Yeah just changing everything to default settings fixed it... all I have set now on bitcoind is server mode and user/pass. I also got rid of the max-conns argument in my p2pool batch file.

wait, you mean the getblocktemplate latency is 1000ms?   remote stuff like google.com or something is 1000ms?  local network is 1000ms?

if it's #3, that should be easy to troubleshoot.  if it's #2, your upstream is probably becoming saturated (or your dad might be torrenting pr0n), so you should leave p2pool at 6 outbound connections and firewall 9332, change bitcoin.conf to listen=0, maxconnections=4, have enough connects (connect=xx.xx.xx.xx) so you dont get random connections (stuff i've been using for like a year, some like 5.9.24.81, 69.195.155.227, 188.40.112.72, 5.9.157.50, 89.238.64.139, 50.31.149.57).. some of those might not allow incoming connections anymore, i haven't maintenanced my addnode list in like 3 months..  but, uh, luke.dashjr.org/programs/bitcoin/files/charts/seeds.txt is a good reference (ignore any node that's using something older than 0.8.2, or maybe 0.8.1 is ok..  the bitpeer node doesnt do any transaction verification (or blocks), so that's nixed too)

if it's #1, you either need to update your bitcoind version (it's probably taking all those horse staple battery transactions), change the fees, or reduce maximum block size.  most likely the first

is the laptop on wifi ?? if so maybe the latency is from the wifi connection

I'm trying something different... just turning off all extraneous settings except the ones needed barebones to make the setup work at all. Instead of having a few options turned on that I know nothing about. Let's see how long it stays reasonable.

I'm struggling with latency... for the first 15 hours when I started up p2pool my latency was 0.2 seconds. Then it inexplicably jumped to 1s at 7:30am a couple days ago (I was asleep but my dad turned on his Mac Mini apparently). I'm running it on an idle laptop that's not currently being used for anything else. I've tried:
- Turning off all other internet connected devices in the house to see if one could be the cause
- using QoS to prioritize bitcoind and p2pool packets
- fiddling with max connections, either low (20) or high (80) on both bitcoind and p2pool
- resetting the laptop p2pool is hosted on

I'm just boggling at what could possibly be the cause. The only things left I haven't tried are disabling/tweaking Kaspersky (any suggestions? not quite sure how to fine tune that besides having it exclude those directories from scanning, tho I do have Kaspersky Internet Security and it may be impeding the internal internet connections) or rebooting the router, maybe. I'm just not clear what suddenly triggered the latency to go into overdrive. Is bitcoind somehow remembering a bad node? How do I check for and/or clear bad nodes?

that pool has an excessive # of orphans, if you're only going to have 6 outgoing connections and 0 incoming, you should use addnode (ed: --p2pool-node) to make sure you get at least a couple that are good

use http://p2pool-nodes.info/  and look for some that are well connected and allow incoming connections, you should also add that 4.5TH one regardless, if it still allows incoming connections, not sure

I can only post one of the pool as my associate state side is hosting my Jupiter's for import VAT reasons here in the UK.

Just wanted to say thanks to everyone here.
We have a strong & free Litecoin and Bitcoin mining site because of your work.
Very, very appreciative.

Post a screen shot
... as I did above, it's easy to work out what it is really doing.

I've currently got 398959MH off just three chips over ten rounds on Slush.  With the fourth board and chip due at KNC in Sweden tomorrow for replacement.

Hmmm....maybe I just have an extra crappy model.  I've tried 3 different pools and get 50-80G difference from what the pool reports and what cgminer reports.  Though they all report much higher than p2pool.

I had a solid 560GH reported by Slush over ten rounds before the board died.  It's due to arrive in Sweden tomorrow and only then can they replace it.  160GH is a lot too loose and I want compo but was planning BabyJets next if they ship this month.

Yeah I like how everyone sees the hashrate on cgminer and gets excited.  It doesn't really matter. cgminer reports over 530 G for me on btcguild, but the pool only reports 480-490 G.  Maybe I can get Knc to pay the difference since they refuse to prove they didn't make cgminer lie.  At least p2pool pays me more than cgminer is reporting 

I've got a Jupiter mining on Slush but one of its boards died on a firmware update.  Tho still with only three of the four chips I'm getting an average of 400GH over ten rounds on Slush.

Hmm calculation time on your picture
Elapsed = 96511s
Accepted = 7963136 1diff shares
Rejected = 166912 1diff shares
Hardware errors = 657472 1diff nonces

So Accepted hash rate is 2^32 * Accepted / Elapsed
354.4GH/s

Full hash rate (Accepted + Rejected) is 2^32 * (Accepted + Rejected) / Elapsed
361.8GH/s

Only one minor comment on those - you can only count the Rejected in the device GH/s if KnC hasn't fucked with the submit_nonce() code and also you can verify that by seeing why the shares were Rejected.
As far as I know there's been no sign of the GPL3 code as should have been given to anyone with a KnC who asks for it ... and it must have all versions of the code asked for.

Gee ... I wonder if I'll have another Kano vs GitSyncom ... what'll it be called this time ... Kano vs KFC
Nom nom.

Anyway, now for the fun numbers there ...
Hardware % = Hardware / (Accepted + Rejected + Hardware)
7.48%
which, BTW, is 29.3GH/s of hardware errors

Well at least it's less than the original 16% when they were boasting about how good it was ... lolololol

Now ... what are these things supposed to be doing?

I'm sure I saw them boasting in that video how they were doing 500GH ... how did it that boasting go ... ?
"... Back in May we promised you 250 ... well it's not 250
Then we upped it to 300 ... it's not 300
In June we said 350. We published that on the web site ... it's not 350 (tears paper in half)
In August we said 400 ... well it's not 400 (screws up the page and throws it on the floor)
We have a 500 machine here for you today and as evidence of the 500 machine we have a laptop in front of us running a full copy of cgminer.
We can see here that we are actually achieving, on average, over 500
In fact the theoretical limit is 576+
576 gigahashes a second and it's fully working and we start shipping today ..."

Interesting definition of "fully working" ...

So do you feel like telling them to go fuck themselves about the red comments for your hardware?

I will add they failed to see that it wasn't even showing 500GH/s on the screen as I pointed out here:
https://bitcointalksearch.org/topic/m.3276727

But of course the most important point being firstly that they seem to think that cgminer showing that on the screen is all the proof they needed.
Yay cgminer

Pity they wrote the driver and fucked up cgminer's reputation ... well ... we didn't have anything to do with their driver code.

Nice to see that totally unproductive 0.3BTC in your payout queue. 

Here you go, 24 unproductive hours with a Jupiter on p2pool  (.93 firmware)

Anyone seen any GPL3 source code yet?

Worst thing KNC has done was to not include Con in their efforts.

Such a shame. 

lol...but we just love to hear you say it Con