FYI for the devs: It specifies in the release notes that: rpcallowip=192.168.*.* needs to be changed to: rpcallowip=192.168/16 Well, that didn't work. I ended up just putting in the full IP address of the pool (ex: rpcallowip=192.168.1.101) xpool.net has been updated to v1.8 |
|
|
|
|
Thanks Lucky Cris. Would you or anyone else happen to know what the other file is?
|
|
|
|
Never said I did the VoltMod  ...but yea, for those that do: Do NOT try to mine BTC |
|
|
|
as stated there a flaw in the p2 system if i can do that by just turn the manual diff up as this test is proving quite well
Sorry to quote but wanted to point out the p2pool will only allow you to increase your share diff up to 30 times the minimum no matter what you set. |
|
|
|
It's all good man...were all here to help and support each other  |
|
|
|
Having looked into the effect of using /# on BTC it appears that the p2pool hash rate is so large that most miners are already running at the minimum p2pool share diff. Unless you are on a node that has over 1.6% (something like that) of the hash rate for p2pool you should be getting the lowest possible share diff....so for BTC it shouldn't really matter if you use /# unless you are on an extreamly large node. The problem is that the lowest possible share diff is so large that miners with lower hashrate are missing blocks since they are not getting shares into the chain in a timely manner...hence the scalability issue. Will only get worse for the smaller miners as more hashrate is added to p2pool. For example this guy with 143 Gh/s is estimated to get a share every 1d 18h and already has the lowest possible p2pool share diff.  Expected Time to Block on p2pool is 0d 12h 19m 11s so they are missing payments on blocks due to not being able to get a share in time.  Again, after seeing that the minimum p2pool share diff has gotten so high I don't think /# will make a difference unless you are on a "public" node with more than 1.6% of the p2pool hashrate. +# is a different story but I'll leave that for another time  How's that saying go, damn if you do; damned if you don't. It appears that the larger p2pool gets the worse it is for smaller miners....quite the dilemma since it needs to keep getting bigger to stay relevant. |
|
|
|
|
/#+# should only be needed if your running on a node that has other miners on it that are not yours. Otherwise it may be best to let it autoadjust...i.e. don't use it.
|
|
|
|
That's why I'm still looking. I want to be absolutely sure. To this point, however, there is nothing in the code that I've seen to indicate anything other than what I've posted. Besides, why take the chance? If you intend to set your difficulty manually to some silly low value, just use /1 instead.
Basically, my search is now concentrating on finding some comparison to the effect of "take the greater of my desired share difficulty and p2pool's minimum share difficulty" during miner payout calculations. If your assertion is correct, then I need to find some other piece of code that says, "if desired share difficulty equals 2**256-1, set share difficulty equal to minimum p2pool share difficulty".
/1 works just as well as /0 for BTC...anything up to the minimum p2pool share diff is fine and works the same. It helps to see what's going on and dial it in if you use a modified node that shows the share diff and time to share per address. Below is an example using a scrypt coin. Scrypt coins move much faster so its easier to see how it all works.  The minimum share diff on this coins p2pool is 0.00615 with Expected time to share of ~9 seconds for the node. That means that every 9 seconds a share is given to the node that is then taken by one of the miners on that node. This node has the majority of the hashrate so p2pool increases each miners share diff to the max possible of 0.184578 (0.00615 *30). If one of the miners use /0 they will be given a share diff of 0.00615 instead of 0.184578 and their time to share would dramatically decrease. The 35.31 Kh/s guy should consider using /# but not too low as to collect dust...he could play with /# to get his time to share down to what he wants. If I could I would bring up a BTC node so you could try it out but don't currently have the resources to do so. |
|
|
|
Ok... did a little investigating on this issue. First off, setting the difficulty to /0 or +0 actually initially sets both to the highest possible values. First the code in work.py in get_user_details:
So for sure don't set your miners to /0
I'm going to keep digging through the code to see what more I can learn from it.
Keep digging...don't think your assertation is correct. I know from experience that /0 absolutely sets your miners to get shares at the smallest possible p2pool share difficulty (currently at 4608650.012 for BTC). |
|
|
|
Watching this reduced reward "experiment" with interest. I know others coins have done so but this is my first time with teeth in the game so I'm paying attention Oh no.... miners going away. Network hashrate was down to ~60 Mh/s at one point today when it was flirting with 1 Gh/s before  |
|
|
|
On number 2 I have been wondering about this. This isn't really about shares, but diff with high hashrate miners question. When Mr 80TH's shows up on pool it's just killing everyone else it seems. Default diff is 999 or so. Based on what you're saying that is not actually correct because if you get a share it's worth more. Currently one address around 12TH/s and you just see all the estimated earnings going down for smaller miners. Have your smaller miners use /0 or whatever you think is appropriate so their share diff is not raised from the larger ones. On my front end I show the miners share diff and expected time to share by address so they can adjust it as necessary. This is if you use a public node...if you have your own it really shouldn't matter. Did you lift some of your suggested settings from Norgz' Antminer settings page? http://www.norgzpool.net.au/antminer.htmlNope, have not seen that site before. Their recommendation on /0+220 seems good for S1's. You could play with the 220 until you get a pseudo share diff that your comfortable with. In regard to the --scan-time 1 --expiry 1 settings I read a detailed post (I think from ck) saying those were essentially obsolete. Wish I would have saved it. |
|
|
|
On number 2 I have been wondering about this. This isn't really about shares, but diff with high hashrate miners question. When Mr 80TH's shows up on pool it's just killing everyone else it seems. Default diff is 999 or so. Based on what you're saying that is not actually correct because if you get a share it's worth more. Currently one address around 12TH/s and you just see all the estimated earnings going down for smaller miners. Have your smaller miners use /0 or whatever you think is appropriate so their share diff is not raised from the larger ones. On my front end I show the miners share diff and expected time to share by address so they can adjust it as necessary. This is if you use a public node...if you have your own it really shouldn't matter. |
|
|
|
I wrote an FAQ on setting P2Pools share difficulty under the section "Can I set my own share difficulty?": http://xpool.net/faq.htmlThought it might help some people.... I've read through your FAQ. Nice writeup. I do have a few comments/questions for you. 1) You state that setting your difficulty to something silly low (like /0 for example) will have an effect on your payout. I do not believe this to be true. A submitted share from your miner means absolutely nothing to p2pool unless it is above the threshold difficulty, which currently sits over 4,000,000. You can set your difficulty to /0 or /10 or /1000000 and it won't mean a thing. Setting it to a value over 4,000,000 however, will have an effect. I made a post regarding this a few pages back. 2) You are absolutely correct about the node's hash rate determining the difficulty for the miners, and if you're mining on a node where there is a very large discrepancy between you and the node's hash rate, you'll find shares less often; however, when you do find that share it will be worth more. 3) Where did you get the 0.00000116 value for setting pseudo-share? I've seen that number passed around, especially for scrypt mining, and I forget the origin. Also, is that number relevant to BTC, and if not, what is? I do remember reading a thread about setting difficulty, but damned if I can find it now. Thanks. The concepts are the same but perhaps I should have posted that it is written with primarily scrypt miners in mind  So, yea the "low setting" caution statement is for coins that could incur large fees when sent due to low payout amounts (dust) to smaller miners. I do believe that the /0 setting overrides the minimum "dust" payout code written into p2pool so you might want to double check on that. Don't remember if I verified from reviewing the code but I'm relatively sure that's how it works....thinking about it though the minimum p2pool share difficulty is too high on BTC to matter... |
|
|
|
I wrote an FAQ on setting P2Pools share difficulty under the section "Can I set my own share difficulty?": http://xpool.net/faq.htmlThought it might help some people.... |
|
|
|
Watching this reduced reward "experiment" with interest. I know others coins have done so but this is my first time with teeth in the game so I'm paying attention |
|
|
|
|
I tried dual mining but found that while doing so gridseeds would start falling off slowly (zombie) requiring them to be power cycled. Since I have them running at a remote location and can not easily power cycle I changed back to just mining scrypt as that is solid.
|
|
|
|
This type of upgrade will never go 100% smooth. It's like herding cats.
Not true...but I will leave it alone. |
|
|
|
MANDATORY UPDATE TO v1.3.0.0 - HARDFORK OCCURRED AT BLOCK 546250
A hardfork occurs when the new coin specs go into effect...not when you release a new client version with it set to change after a certain point. So the question is...when does the hardfork actually occur....could look at the source but just wanted to point out the hardfork did not actually take effect yet. Edit: To answer my own question...hardfork will actually take effect at block 575000. Update before then or you will be on the wrong chain. Hard fork occurs when new clients are released that ignore the clients with the old protocol. That has already occurred. The chains are already diverging. If you make a transaction on the 1.2 chain right now, it will not be in the 1.3 chain. If you mine on the 1.2 chain, those will not be on the 1.3 chain. 1.3 clients currently ignore 1.2 clients. Wow, so you released a client that immediately created a forked blockchain?! That essentially gave no one time to update.... irresponsible in my opinion.  |
|
|
|
Hehehe, it's more profitable to mine BTC now...who would have thought? Not taking electricity cost into consideration of course |
|
|
|
|
Show Posts
