Topic: NastyPoP vs Standard P2Pool - page 5. (Read 17728 times)

I wouldn't normally update this post unless directly asked a question or to respond to some discussion point.  Having written that, I wanted to post this.  On Friday, just after 19:00 UTC, I created a new BTC address and configured one of my S3s to mine on the nastyfans.org traditional p2pool.  I now have 3 S3s on this test: one of them is mining on my backup node, one is mining on nastyfans.org using NastyPoP and the third is mining on nastyfans.org using traditional p2pool payout.

Since I brought this S3 to the nastyfans.org pool, it has found far more shares than it should have: 4 in the past 48 hours.

First, here's the configuration screen of that miner:


Now, here's the graph from nastyfans.org:


Statistically, an S3 should take between a day and a half and 2 days to find a share.  Clearly this miner is beating expectations - and as with the miner on my backup node has shown thus far in the test - variance plays a far larger role on the traditional p2pool node than it will with NastyPoP.  As of this post, the miner on my backup node has 0 shares on the chain.

We'll see how this all plays out come Friday...

CHILLLLLL we here to run tests & a FAIR comparison ! not to .... each other.

Very nice of JB to do the tests & also very nice of nasty who have made a unique p2pool.

I posted it earlier... I created the address yesterday and configured my S3 to use it on the standard Nasty p2pool.  Here it is:

1JbnAstYXy1pmv7AeLj7w117HWvmDXCFDE

What new address are you using to mine?

Quite frankly I'm amazed by your continued assertions that I'm somehow running a flawed test.  Now you're insinuating that my math skills are lacking.  My results absolutely can be attributed to statistical luck, plain and simple.  The latency from my location to your node is higher than I would choose if I were going to be picking a node on which to mine; however, the latency isn't so different as to be as big a factor as you're claiming it is.

To your node:

--- nastyfans.org ping statistics ---
39 packets transmitted, 39 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 116.675/158.528/388.339/71.604 ms

To my node:

--- 104.131.12.128 ping statistics ---
40 packets transmitted, 40 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 20.111/40.750/143.201/36.491 ms

I also stated that a miner is forced to accept the higher latency if he chooses to mine on NastyPoP because your server is located in the EU.  Yes, there are some miners closer to your server, and there are also some miners who are farther away.  The point remains that everybody who chooses NastyPoP is indeed forced to accept that consequence, whereas if they want to mine a traditional p2pool node, they can run their own on their local home network where ping times are of no consequence.  Or, they can choose to run on a node that is close to them.

I didn't mean to insinuate that you are running some non-standard version of the p2pool code.  All I meant here was that you could have tuned your node to change things like max block size, etc.  I don't control the node, so I don't know what you've done.  That's all.  You've cleared it up, and I take your word for it.

I decided to point yet another of my miners to your standard node.  There's not going to be any ramping down and equalizing.  I have 9 S3s.  When I started the test, I used the one pointed to my backup node and pointed one of them to your NastyPoP node.  Now I'm pointing a third to your standard node.  If anything, statistically speaking, the miner using NastyPoP should payout higher this week.  Why?  Because as of now, p2pool expects to find a block every 15 hours or so, yet my S3 only expects to find a share every 36 hours or so.  Therefore, my NastyPoP miner expects to get paid for 2 blocks before my regular Nasty miner even expects to find a share and get paid.  If I'm lucky, I'll find more shares than expected.  If I'm unlucky, I won't.

So much for my lack of math skills.

I really can't believe that you truly think the fact that my S3 happened to have submitted more shares than expected has everything to do with latency and nothing to do with luck.  I'm seeing higher earnings because my S3 had more shares on the chain than expectations, which is easily seen - and strangely enough verified by you - by looking at the hash rate p2pool thinks it has.  Twice in this thread you've provided the hash rate p2pool thinks that miner has, and both times p2pool thought that rate was higher than it actually is.  If you really think that's solely because of latency, you're just plain wrong.

In any case, the test continues and I look forward to seeing how the three miners compare to each other: a close p2pool node, a faraway p2pool node and a faraway node running NastyPoP.

Just because it is high latency where YOU are, does not mean it is that way for everyone.  Hence your flawed results which cannot be attributed to luck.  If you believe that, then I would suggest that you aren't very good at math.




NastyPool is a default P2Pool node.



Cool.  Thank you for deciding to run this test fairly to get legitimate data about NastyPoP vs Standard P2Pool payouts.  I look forward to seeing your numbers show a slight advantage to Standard P2Pool next week as your hashrate ramps down to where both miners are equal, followed by nearly identical numbers the following week.  Perhaps once that happens, you will stop your ludicrous luck argument and restore some legitimacy to these numbers.  Maybe you'll even go as far as removing the inaccurate data.



You aren't seeing higher earnings due to luck with Standard P2Pool.  Your hashrate isn't low enough to see the extreme variance reduction benefits of NastyPoP.  For the test you think you're doing, you'd see much better results mining with 1GH/s.  

Another week of testing has passed and here are the results...

Standard p2pool node: 0.05615571BTC
NastyPoP: 0.05015601BTC
Expected: 0.0393BTC

Both the standard p2pool node as well as the NasyPoP system beat expectations this week.  Also, if you take a look at the payout history for my miner on the standard p2pool node, you'll notice that I received no payouts for two of the found blocks because I didn't have any shares on the chain when they were found.  For my miner on NastyPoP, I did indeed receive a payout for those blocks.

This is where NastyPoP shines and truly shows the reduced variance and I was hoping we'd see it during the testing.  Although the miner on the standard node edged out the miner on the NastyPoP node, the difference between the two is pretty insignificant this week.

Standard p2pool node paid 142.89% of expectations this week.  NastyPoP paid 127.62%.

Another note I want to add here... to assuage any concerns that OgNasty has had regarding the execution of the tests I've been running, I have pointed yet another of my S3s away from my own node and to the standard p2pool node at nastyfans.org.  This S3 is like the other two: running at a clock of 218.75 getting 440GH/s.  I started it at approximately 19:10UTC today.  The address is 1JbnAstYXy1pmv7AeLj7w117HWvmDXCFDE.  Starting next week I will include the results from that miner in the report as well.

I've updated the OP with this week's results.

OgNasty,

There are 2 reasons why I chose to implement the test the way I did.

1) A miner who chooses to use p2pool is either going to run his own node, or find one as close to his miners as possible from a latency perspective that is performing respectably (low GBT latency, decent efficiency, etc).  If the miner decides to go with NastyPoP, he must accept the added latency as a byproduct of that choice, since he can't build or run his own version of NastyPoP locally or choose to mine on a closer node on which it is installed.
2) I built and own the node on which my miner is pointed and know it is in fact a standard p2pool node with no modifications other than justino's front end and is running the latest version of bitcoind compiled and built on the server.  I don't have control over your node, and I don't know what if any modifications and tuning parameters you've made to your own.

However, since you seem to feel that my test is in some way invalid because I'm not mining on your node, I will gladly rectify this situation.  As of 1900 UTC this coming Friday, I will point one of my S3s to your standard p2pool node, and keep my current miner on the NastyPoP version.

What I have shown thus far in the test is that luck has everything to do with mining and a miner on a standard p2pool node will experience the variance of that luck far more than would a miner who chooses NastyPoP.  In reality, the payouts aren't the real result of the test - the fact that the variance is far less on NastyPoP than it is on a standard node is.  You can even seen this by looking at the results in the OP.  Look how different the numbers are in the standard node vs those on your NastyPoP node.  That evidence clearly shows how NastyPoP reduces variance.

I hope this explanation helps to clarify any misunderstandings you may have.

Nobody, including me, is accusing you of not being transparent. You were accusing JB of this:


I have congratulated & praised you & p2p-pop already, as well as suggested your pool to potential miners:


So there is really no reason to twist my words.

I'm outta here.

I don't have any questions about his lack of transparency.  I fully understand what he is doing.  He can chime in on why he decided to test Standard P2Pool payouts from a lower latency node if he wants to explain why he decided to handicap NastyPoP payouts for this test.  That would be relevant.



The NastyPoP software was developed by nonnakip.  It is not mine.  However, the actual count of hashes is published in the NastyPoP Standings page and updated every 5 minutes as well as the payouts being public record.  That is pretty transparent.  If you feel we aren't being honest, you can count your hashes and check the public payout records to make sure everything is being reported accurately.  Giving away the code (it's a completely separate program written in C that runs NastyFans.org, most P2Pool users wouldn't know what they were looking at or how to integrate it with their node anyway) does not equal transparency, as there is no guarantee that we would actually be using the same code we gave out anyway.  Publishing the number of hashes so users can confirm and making our overall hashrate and payouts public via P2Pool is more transparent than handing out code that can't be confirmed is identical to what we are using in my opinion.  With all the efforts that are made to be transparent (look at all the automated statistics in my NastyMining thread, my free iOS App, naypalm's 3rd party coin analyzer, and how nonnakip improved upon P2Pool's hashrate estimate and charts, not to mention the wealth of statistics available to members at NastyFans.org), I am disappointed to be accused of not being transparent.



I know we are doing great things and we will continue to do so for a long time.  Thank you for the kind words.

I'm sure JB can answer any questions regarding your transparency concerns when he comes online.

BTW, your software is closed source is it not? Hardly a platform from which to talk about transparency.....

Seriously, I think you're doing a good thing with your idea, and hope it works out well for you.

Peace 

I asked him to do a fair test and even told him how it could be done with total transparency. When he gave the information that showed their was no transparency and the numbers weren't matching up to what P2Pool was reporting for his hashrate, he says his miner was lucky. While having incredible luck for months is a possibility, that isn't my issue with this test. Although, standing behind a lack of transparency for no legitimate reason and claiming a lucky streak does leave a bad taste in my mouth. Especially when there's a transparent and fair method to test readily available. I don't care about falling out with anyone. I care about accurate, transparent, and fair results when running a test.

Well, I have no intention of falling out with anyone over this, but the fact remains that you asked him to do it. So he did.

I was calling him out because his test is flawed and not a representation of NastyPoP vs Standard P2Pool. He is testing a payout method yet is using different nodes with drastically different latency and claiming that it's an accurate portrayal of NastyPoP vs Standard P2Pool, which it is not. Someone in another location closer to our node doing his same test and using his same nodes would see the opposite results. That's why this is a joke. OP is aware of the latency issue, but ignores it for some reason even though it could easily be corrected. Why purposely run a flawed test when it's been pointed out that the way you're doing it is flawed and has no transparency is the question you should be asking. Especially when a transparent method with the same latency is available...

It is (was) indeed a strange response OgNasty. JB has put a lot of effort & time into carrying out this experiment at your request. Calling him out simply because you don't like the results seems a little OTT, especially as JB has made it clear that luck has had a lot to do with the results.

Every p2pool user has praised you for taking the initiative & tackling the p2pool variance problem, so this kind of response is uncalled for I believe. There are many very knowledgable p2pool users who could contribute to your software & help make any improvements needed that could maybe improve the results & help the p2pool network generally - maybe now is the time to open source the code so that the community can help?

Just a thought  

That's your (now deleted) response?  Where in any post in this thread have I led you to believe that I have any intention of trolling you?  Where in any of my post history have I given any indication that I engage in trolling activity?

I began this test at your request.  I agreed to do so because I thought you had provided an innovative approach to handling the inherent variance experienced by p2pool miners and because you're a donating and respected member of this community.  I did it as a favor to you at my own expense to hopefully help you promote your idea.

The only thing that can clearly be seen here is that I've engaged you in a discussion in which I've praised your efforts and presented logical and well argued counterpoints to statements you've made with which I don't agree.  I'm terribly sorry that you have somehow translated that into being trolled.

Did you not bother to read what I have written?  I have consistently praised the work you and Nonnakip have done and have even stated multiple times through both the first and the second post and throughout our conversation in this thread that the results of my test should not be taken as concrete evidence either way.

What is being measured here is one S3 on a standard p2pool node and another on the NastyPoP enhanced p2pool node.  While distance certainly plays a factor, it is most certainly NOT the only reason the results are what they are.  I could have 100TH/s on my node and 100TH/s on your standard p2pool node and 100TH/s on your NastyPoP node and there is absolutely no guarantee whatsoever that all 3 of those will pay out identically as you are trying to convince everyone.  NastyPoP is not guaranteed to payout exactly the same as a standard node over time.  Why?  Because as is being witnessed in this very test, sometimes a miner beats the odds and sometimes a miner doesn't.  Mining and finding shares is LUCK.  NastyPoP guarantees that the variance in that process is reduced.  That's ALL it guarantees.

You asked me to do a test like I did comparing p2pool to BAN and I obliged.  Neither the test nor the title of this thread is misleading in any way.

NastyPoP pays out identical to what you will get on P2Pool over time, right down to the P2Pool luck.  What is being measured here is the benefit to mining on a closer node with lower latency and what it would look like if your miner regularly performed at above it's hashrate only on the Standard P2Pool.  Extremely misleading test/title.  You'd think someone who puts effort into testing something like this wouldn't do so in such a way that drastically alters the results.

Week 3 results... (12/12 - 12/19)

NastyPoP: 0.03382075BTC
p2pool: 0.07363736BTC
Expected earnings: 0.0334BTC

So, as in the past couple weeks, the S3 mining on my standard p2pool node paid out more than the one mining on NastyPoP.  Apparently the miner's lucky streak has continued.  NastyPoP paid almost exactly the expected earnings for the S3.

I'll be updating the OP with this week's results.

Both are remote... Albeit my p2pool node is considerably closer than yours is.  My node is running on a VPS in New York less than 100 miles from the miner.  I fully agree with you that the distance is playing havoc with my rejects on yours... And thus the earnings are also likely impacted a bit because of it.  Do I think that is the only reason why the earnings are less on your node than they are on mine?  No.  Luck is definitely a factor here.  The miner in my node just happens to be having a good streak.  That kind of streak is what your system mitigates.  Like I wrote it can just as easily go the other way.  When it does the miner on my node will suffer with no payouts while the miner on yours will still be rewarded for its contributions.