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

I should reiterate this is happening due to the generous offer from Aseras himself to provide me remote access to his units. Since p2pool is part of Aseras' concerns, I will try and address anything I can from the cgminer end but I think that will only achieve so much. Xiangfu has said that they should send me an actual unit, but he doesn't have that power himself, and thinks he should try and convince them.

This is happening next week. If plans go well.

And Kano, take what you can get. Just because you have beef with the avalon team, don't screw with everyone else. If anything we need people like you to get the avalons to operate like they should. Instead, we have this half assed build of cgminer because they wanted it all in house. Better to just cut them out and move on.

Bitcoin is going to ASIC. BFL may be close, or one post away from bankruptcy. There's no one else. Might as well get your hands on what's out there.

What??

That was not a post stating anything - it was a follow up question to a previous discussion. Read the previous threads. The only one shouting about problems is you - get off my freaking case.

And please refrain from sending me any more creepy apologetic pm's - it's not required & I'm really not interested. Move along.

If you know of a problem, you can report it here:
https://github.com/forrestv/p2pool/issues?state=open

This will help you understand how you can help most efficiently:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

you can also find the devs on #p2pool on freenode.net irc if you'd like to discuss something specific with them.

For the sake of p2pool, please stop publicly posting that there are problems with stratum, p2pool, and standard mining software without any data (logs, error messages, debug output). I'm not saying there are no problems, just that no one has reproduced what you are saying is a problem and shared it with developers. Therefore, no one can look into fixing it. If you share your evidence, then maybe we can fix it.

Just get an Avalon for ckolivas and cgminer will be hashing Avalon on all working pools as quickly as possible.
I don't want an Avalon as I have made clear for quite a while now.
So no, it's not get "cgminer team" an Avalon, it's get "ckolivas" an Avalon.

Good for you,

Did Forrest mention anything about checking the whole stratum code in p2pool?

I've been talking with Forrest via PM. basically it's come down to, we just need to get an avalon into a developers hands. ckolivas has offered to try and work remotely. Forrest has hinted he may be interested and has a batch 2 order he's waiting on.

Ok, continuing trying to find bugs:


2 bugs found, one regarding only avalons using avalon-branch cgminer problems with p2pool stratum, one regarding maximum difficulty:


The bug that has been reported regarding avalons, stratum, and p2pool is:
https://bitcointalksearch.org/topic/m.1683442
"Avalon Cgminer without fix protocol connects on stratum but resends all work over and over. There's something wrong with the way it reads the stratum response. Someone, Jeff I think, said it has a problem with double byte responses that p2pool makes. On getwork, it just hammers the server and the DOA rate is >25%. Using a very high diff 3000-4000 helps a tiny bit. The highest p2pool would let me go is 6535. Any higher number just comes back as 6535.

Even soloing to a bitcoind alone will crash. It's too much. Hence the need to run a buffer like eloipool between it."

The workaround is:
https://bitcointalksearch.org/topic/m.1690401
"So far the only thing that works is using fix-protocol and getwork with a very high diff. I've been using /4000+16. That seems the best balance. +32 is all late. You have to remember the "miners" are only 300mhash each. It will bring a 3930k running Ubuntu with 32gb of ram to its knees. It pegs 4 processors trying to keep up and eventually crashes as it runs out of memory. I also is 25-35% DOA. You loose 1/3 of your hashrate."

How it is getting fixed:
https://bitcointalksearch.org/topic/m.1684865
Unfortunately, it appears that until avalan-branch cgminer merges into main-line cgminer it will be difficult to support. Maybe discussing this with Xiangfu ahead of time could be helpful. It might also be helpful to get forrestv/cgminer team avalons if someone cares about support for them.




Bug #2, maximum difficulty:
https://bitcointalksearch.org/topic/m.1684832
using the username+difficulty -u flag, Aseras reported only being able to reach a maximum difficulty of 6535. I can repeat this, the maximum difficulty I can reach is 999 with both stratum and LP. This has been reported here:
https://github.com/forrestv/p2pool/issues/87

I managed to set it up on 512M model, but CPU load is 100%, so the whole thing is useless.
Gonna profile python code, find bottlenecks and rewrite them in C... when I will have some time

For all hashrates, the only way to have accurate measurement is over a large number of shares submitted. For low hashrates, 1000 1-diff shares should give you a good idea. Activate logs in your miner if you can and find out how much time it takes to submit 1-diff shares (which should be what p2pool asks for with low hashrates). Compare the time it took between getwork and stratum, the difference should be ~1% or less if there was no perturbation (loss of Internet connection for example).

I may have spoken too soon.  Using my pool monitor, I have logs every minute of current hash rate, and I'm seeing it fluctuate all over the place both post and pre stratum.  I'm not sure with my low hash rate and the normal cyclic pattern of hash rates that I can definitely say I get a higher rate with LP than I do stratum.

The guy with the Avalon though should open an issue, if he hasn't already.

M

If people really have a problem with p2pool and stratum they should start opening tickets on github with details about their setup (OS, python, twisted, p2pool and miner versions, hardware used, hashrate involved, stratum or getwork, load, steps to reproduce the problem).

Meanwhile the silent majority mines with p2pool and stratum without problems since the beginning. We don't have problems: how can you expect us to help if you don't give the information needed to do so? I would like to help diagnose the problem but I certainly won't dig into previous posts to guess what could be the problem with the setups involved.

Here's one setup working as expected (mine) to make it clear what might be useful to pinpoint the source of a problem:

• OS: Gentoo stable, python 2.7.3 (stable), twisted-11.1.0 unmasked (11.0 is missing a way to close connections properly which leads to memory leaks),
• Hardware: Core2Duo E8400 3GHz with 6GB RAM, bitcoind/litecoind/p2pool on SSD, other software used on the server but with low loads.
• P2Pool: git master branch
• mining devices: Cairnsmore1 and Icarus, 5870 and 5970 graphic cards for a total of ~9GH/s when mining BTC and ~5MH/s when mining LTC with GPUs,
• software: MPBM master branch for FPGAs, cgminer 2.11.3 for GPUs,
• configuration: MPBM using getwork with BTC p2pool, cgminer using stratum with both BTC p2pool and LTC p2pool,
• load: there's little CPU usage from p2pool and cgminer (<5%), RAM is usually <250MB for LTC p2pool and <500MB for BTC p2pool. cgminer RAM usage is ~30MB. There's negligible amount of IO wait time (always <1%): p2pool isn't waiting for disk reads/writes.

Organ,

Text can very easily be taken the wrong way if it is not carefully phrased, and it helps to use the smileys also. If you meant no malice then fair play to you.

You know my stance on this situation with stratum & p2pool more than most people, we've had discussions about it before. I have taken far too much undeserved flack over the months since it was introduced, not just because I stood my ground because I believed I was right, but also because others refused to even contemplate that there was even a problem with it - preferring to ridicule & deny anything was wrong rather than investigate what me and others suggested a long time ago. This only resulted in damage to p2pool, my favourite pool. I won't deny the fact that I feel slightly vindicated with what we now know, but what is important is that it gets fixed. Pronto.
There are a few people in this pool who are too quick to jump on others at the slightest hint of questioning anything, dismissing them as not being of sufficient intellect - even suggesting they go elsewhere to do their mining, that for me flies in the face of p2p. The whole idea of p2p is communal sharing, effort & problem solving - that's the main reason why I chose this pool. Even "experts" can be wrong, the same as the rest of us mere mortals, but accepting to be wrong seems a little too hard for some people. That's a shame.

Anyways, rant over. Can we fix it and move on now?  

Peace  

THANK YOU! This is a legitimate starting point. This is something that can actually be looked into, do you mind filing an issue:
https://github.com/forrestv/p2pool/issues?state=open
(I think forrestv does some triage on this forum as well)

I've been running p2pool on stratum for about a week with cgminer.  I noticed the hash rate just isn't as high as it should be.  Not significantly lower (2.4gh instead of 2.6), but still lower.  Based on what was revealed about Avalon and stratum, I thought I'd try disabling stratum in cgminer.  Guess what, my hash rate is back where it should be.  Note that I don't have the hash rate degradation on a "conventional" pool with stratum.

Unfortunately while I can only salivate about the idea of having an Avalon, there does seem to be evidence that stratum isn't functioning up to par on p2pool.

M

This is the problem: you keep citing the wrong numbers as evidence of a problem.

You think there is a problem with stratum, but you keep using "luck" as your evidence. Your argument is "it is impossible for luck to be this bad, therefore something must be broken." Your premise is false, and I proved it by demonstrating how common such bad luck is in reality. That isn't living in denial, but in reality.

However, this post presents new evidence: "stratum connection crashes p2pool." If that is true, that has nothing to do with luck (a crashed p2pool does not hash and does not contribute to luck). Your use of luck as a metric/evidence is still wrong.

I'm not saying there is nothing wrong with p2pool, I've been saying all along that your arguments are based on either the wrong data or wrong conclusions from data.

I think you took that the wrong way.

Edit: try reading it as 'One is only a "FUD spreading noob" when one talks about things one *doesn't* understand about mining bitcoin.'

Unnecessary, uncalled for & counter productive. Especially coming from a person of your undoubted mathematical knowledge & reputation.

Constructive criticism is most welcome regarding this problem, derogatory comments are not. It helps nobody & nothing.

You're only a "FUD spreading noob" when you talk about things you *don't* understand about mining bitcoin.

Thanks Subo.

Not bad for a "FUD spreading noob who obviously doesn't understand mining bitcoin" eh?