This is an interesting discussion, please let us know the results.
P2pool is important for bitcoin and making it accessible to more people is important. This type of change helps public pools - and that helps bitcoin and p2pool. Let's face it, many people won't set up their own p2pool node, they want easy and compared to pools that require registration, p2pool is easy.
Decreasing variance (since people are impatient and don't care about the math) could be helpful too.
Has been working well so far. The diff miners get is lower than it'd normally be, but not as low as if they did /1 to mine at the minimum share diff all of the time. The reason /1 goes lower is that it overrides the dust prevention code. So it's best to not just tell all public node miners to use /1, and instead only have people who can't stomach the variance and are willing to pay the tx fees do that (or they should use a normal pool). The node I'm testing on is http://vtc-us-east.royalminingco.com:9171/static/graphs.html?Weekand the code went live at the Feb 9ths mark (early morning). You can see from the pool shares graph the peaks/valleys have smoothed out, and you can see it happening in a similar way on a per-miner level on the miner graphs. I don't run a BTC node at the present time so I don't know what sort of share difficulties normally get assigned to workers on the public pools. The VTC p2pool network is over 5% of the global network speed and finds many blocks per day. So the behavior here might be quite difference than on BTC itself. Hopefully forrestv or someone with more knowledge and experience with the p2pool code base will review and comment. |
|
|
|
looks like someone is massively DDosing the pools.
If some of the normal pools aren't working, there are dozens of public p2pool nodes available to use as backup pools.  |
|
|
|
|
The settings I use on other scrypt coins give me massive HWs too. What I ended up with was 8192 thread concurrency, I 13, and 2 gpu threads. That is working pretty darn well with no HW.
|
|
|
|
Specifically, these settings: vertminer.exe --scrypt-vert -o stratum+tcp://vertcoinheavyindustries.com:4444 -u xxxx -p xxxxxx -v 1 -w 256 -I 13 -g 2 --lookup-gap 2 --gpu-powertune -20,-20 --temp-overheat 85 --temp-cutoff 90 --gpu-memclock 1500,1500 --gpu-engine 1000,1000 --thread-concurrency 8193
Not sure what happened, those settings are pretty conservative for the tri-x cards.
Do you normally mine other coins with 1000/1500 clock speeds? I'd suggest lowering them back down to factory defaults and seeing if that clears your game up. Edit: I'm not sure which card you own but the standard tri-x cards ship with 1000/1250 and the Sapphire OC ships with 1040/1300. Make sure your memory is back down to 1250 if the cgminer crash has left it at 1500. |
|
|
|
Decided to try and mine Vertcoin, within 3 minutes of using the settings on page 1 my rig crashed. Now it locks up and crashes indefinitely when trying to mine any altcoin. I had zero problems using cgminer to mine other coins for three weeks straight.
Also, just tried to play a game (BF3) to test it, and the whole rig crashes immediately.
It sounds like you used settings that overclocked your video card too high. Use Saphinre Trixx or some similar program to make sure your clock rates are normal. cgminer doesn't reset the block back down when it exits (except maybe in latest version), and that won't happen if cgminer crashed. If you are too over clocked then you'll keep having problems in video games, mining other things, etc until you move your speeds back down. I didn't see any cgminer settings on page one so I don't know if they included overclocking or not. Edit: If you mean the settings in the first post of https://bitcointalk.org/index.php?topic=416572then yeah, the clock speeds he sets there are perhaps be too high for your video card. Make sure you aren't still at those speeds. |
|
|
|
Aha, thanks for the explanation. But why the initial payout contained a lot of address? Just because those addresses are in the queue, which is shared between p2pool nodes? By the other words, it is possible that my address will be in this list for something other who decided to bring up the p2pool node?
When any p2pool node finds a block, everyone in the share chain gets paid. Once you find nodes (of your own, or a fee % of the shares your miners find) then you'll be in the share chain for while. You'll be paid on every block found by anyone on p2pool until your shares expire. |
|
|
|
There's also a new one http://www.clevermining.com/Has a very nice web interface, and auto converts the alt coins it mines into BTC for you so you get paid in BTC. |
|
|
|
I can also say my order from February 1 is going to be delivered on Tuesday according to My UPS Online. Big order too, several thousand U1's!
U1s? Do you think you will make a ROI? Maybe he's reselling them individually. Which will make a nice profit. |
|
|
|
|
Not that I know of. Maybe someone else can chime in. Remember p2pool is intended for each miner to run themselves.
|
|
|
|
1 thing is not verryr clear:
When u use p2pool doe 1 coin, users use their wallet as username for payment,
What if you merge mining,? Users get only payed in 1 currency?
Yes, the merge mining income goes to the local wallet for the node. If you are going to pay that to users you need to set something up to handle that yourself. |
|
|
|
Can someone provide a link, instructions, or tutorial on how to join a p2p pool? I just figured out how to mine in a traditional pool. But I only have one gpu. I am thinking I should be able to do better in a p2p pool, correct?
Variance will be higher in p2pool than a normal pool. You connect just like a normal pool, but use your payment address as the username and any password as password. As a tiny miner you should either run p2pool yourself, or add "/.00001" to your username when you connect. That will increase the dust in your wallet (smaller payouts) but will prevent the variance where you get very few payouts. (They will average out to your expected earnings long-term but most small miners get frustrated with public nodes if they don't use the /.00001 trick.) I'm running a patch atm to reduce small miner variance on my east p2pool node if you want to try it. Not as many shares as /.00001 but also less dust. Patch isn't needed if you install and run p2pool on your own computer. |
|
|
|
My culprit I see is that they have my power on stupid stuff like BTC mining and also on PPC mining despite the fact that I joined this pool to NOT do that! I wish there was a way to be excluded from BTC, there are a ton of other pools that will mine btc...why on earth would they allow that?! So as it stands there are still ZERO good Sha256 multi-pools.
Sometimes BTC is higher profitability than TRC or PPC though. |
|
|
|
Pointed my miner (75Gh avg) to my pool. After a while graphs shows ~6.0 mBTC in the "Current payout to default address" section, but the pool balance still is zero. Is this a glitch or hidden/donated payouts?
Thanks in advance!
That amount is how much money for -fee is in the Payouts list, I think. Remember that -fee doesn't provide a steady commission on all node income, but it gives you that % of the pool shares randomly. So you'll see variance in the node income even if the miner shares are steady. |
|
|
|
I'm temporarily testing a change to p2pool on my east coast node. If you are a low speed miner (1-2 GPUs) you might want to mine with me overnight and see how your share graph looks in the morning, to help me test it out and see what happens. It should reduce share variance for smaller miners to match the same variance you'd get if you installed a local p2pool node on your own machine. (Running p2pool for yourself is still the best choice, but for people who use public nodes instead I'm trying to improve the experience a bit.) http://vtc-us-east.royalminingco.com:9171/static/Another option low speed miners have with P2POOL is to mine with "ADDRESSS/.00001" or similar. The /.00001 sets the difficulty you want as your share target. It won't ever go below "share difficulty" on the web interface to p2pool, but it will override vardiff. The issue small miners using large public nodes have is that by default vardiff operates on the hash rate of the node as a whole, not the individual miners. This is because p2pool is intended for every miner to install for themselves. If you are a small miner and install your own p2pool node, you won't have the variance issues people are having on the public nodes since the node's speed would match your own speed. |
|
|
|
As an experiment I'm running this live on one of my VTC nodes now, after testing it out some. The share difficulties are being set exactly as expected. Will check again in morning but it seems to be working great. Here is a diff for anyone's review/comments please. Remember python is whitespace sensitive if you try to apply this to test yourself. What happens is the share target when sending out work is set based on the payment addresses' hash rate instead of the whole node's hash rate. This way each person/group mining to an address on a public node finds shares at the same difficulty as if they ran a local private p2pool, and don't get increased variance based on the size of the public node. diff --git a/p2pool/work.py b/p2pool/work.py
index e1c677d..285fa3e 100644
--- a/p2pool/work.py
+++ b/p2pool/work.py
@@ -245,12 +245,11 @@ class WorkerBridge(worker_interface.WorkerBridge):
if desired_share_target is None:
desired_share_target = 2**256-1
- local_hash_rate = self._estimate_local_hash_rate()
- if local_hash_rate is not None:
+ local_addr_rates = self.get_local_addr_rates()
+ local_hash_rate = local_addr_rates.get(pubkey_hash, 0)
+ if local_hash_rate > 0.0:
desired_share_target = min(desired_share_target,
bitcoin_data.average_attempts_to_target(local_hash_rate * self.node.net.SHARE_PERIOD / 0.0167)) # limit to 1.67% of pool shares by modulating share difficulty
-
- local_addr_rates = self.get_local_addr_rates()
lookbehind = 3600//self.node.net.SHARE_PERIOD
block_subsidy = self.node.bitcoind_work.value['subsidy']
if previous_share is not None and self.node.tracker.get_height(previous_share.hash) > lookbehind:
One weakness of the ADDR/1 workaround is it overrides vardiff completely and ignores the network.py dust threshold. The optimal solution is for every miner to run their own p2pool node. |
|
|
|
My order time is 2014-01-29 14:51:53.0 but still Unshipped on Bitmaintech and no Information from UPS.
Anyone has similar status?
I did not get an email from UPS, but it is on my calendar. but if you log into myUPS and view calendar... it may be there. bitmain site will stay unshipped for a while, they do not update that very often. Thank you for this tip. I just went online and I see it in MyUPS that I just signed up for. Expected delivery date is Tuesday. Boy that's fast. |
|
|
|
I realize that p2pool's intention is to treat each node as a single miner, and p2pool isn't intended to operate as a pseduo public pool. So as I look in the code, I see how the 1.67% cap is applied to the node (not individual connected miners) and that makes total sense in the context that a node is a single operation (an individual or group using p2pool with all of their own hardware as a replacement for solo mining). However, to better support miners that want to use a public node for whatever reason I think it'd be good if that could be handled in a way that will, in effect, simulate the same result as if they were running a p2pool node of their own instead. Maybe as a command line option that is off by default so any changes make zero difference to existing operations. Basically this comes down to making the share target for a miner (by which I mean a person or group with 1 or more physical mining devices) based on that miner, and the 1.67% cap on that miner. Not on the node as whole. The key code in get_work currently is: if desired_share_target is None:
desired_share_target = 2**256-1
local_hash_rate = self._estimate_local_hash_rate()
if local_hash_rate is not None:
desired_share_target = min(desired_share_target,
bitcoin_data.average_attempts_to_target(local_hash_rate * self.node.net.SHARE_PERIOD / 0.0167))
# limit to 1.67% of pool shares by modulating share difficulty
However, we wouldn't want to just change the local_hash_rate to be the miner whose new work is being assigned (the physical mining device with a connection to the pool). That would defeat the purpose of things like the 1.67% cap. What if, instead, it was based on the estimated hash rate of the destination payment address? So if I have 4 antminers all mining to ADDR_X, the target share rate is based on their combined speed. But someone else connecting their two antminers with ADDR_Y will have a lower target share rate. ADDR_X and ADDR_Y are both having the 1.67% cap applied individually, etc. Someone operating a node now with dozens of pieces of equipment all paying to the same address would see zero change even if they did toggle this on. Individual miners on a public node would see reduced variance in their own shares, since pool hash rate is taken out of the equation. They could do this by hand now with ADDR/1 (or say /.000001 for scrypt), but I think handling it automatically makes more sense (and keeps vardiff alive for miners that are maybe bigger than justifies using ADDR/1). The way I view this is that if ADDR_X and ADDR_Y were running their own nodes instead of connecting to a public node, their target share rates would be based on only their own hash rates anyway. The 1.67% would be applied to each of them individually (instead of all combined in the public node). By adjusting their target share rates only to their own speeds, it simulates them running their own nodes. Thoughts? TLDR: A small miner connecting to a busy public node has much higher variance than running a node of their own. |
|
|
|
Interesting. I've always assumed small miners on public nodes have high variance because of share difficulty. But that's not the case, the bigger the pool is the more it will push up those miner's share targets so that the pool as a whole hits its share target. As far as I understand it so far anyway. This doesn't happen if a miner runs his own pool, since you'd then be working on the minimum difficulty if you aren't getting enough shares. Please see this post and my two followup replies: https://bitcointalk.org/index.php?topic=214512.msg5019286#msg5019286For example I have a dozen of these for miners: 2014-02-08 19:06:36.628849 New work for worker! Difficulty: 0.002211 Share difficulty: 1.629049 Total block value: 50.017000 VTC including 14 transactions And here is my ADDR/.000001 test: 2014-02-08 19:06:36.633762 New work for worker! Difficulty: 0.002211 Share difficulty: 0.054301 Total block value: 50.017000 VTC including 14 transactions Share difficulty from web interface is .054. So left to the defaults, I'd be able to get shares onto the share chain less than 1/100 as often? |
|
|
|
IMHO the main problem with this is, that p2pool tries to dish out share difficulties so that it expects no more than one solved share per minute from all connected clients. So as my VTC node has about 6 MH/s local rate at the moment, the log shows a standard share difficulty of 1.39 given to clients. Minimum share difficulty for the pool is 0.063 on the other hand. So it seems perfectly legit to specify a custom share difficulty of 0.55 for my miner. (If you specify it too low, p2pool seems to use the minimum pool difficulty anyway).
Interesting. I kept assuming small miner variance was due to large share difficulty but that's not the case at all for VTC right now, if you are a small miner using a big public node. 2014-02-08 18:41:03.086159 New work for worker! Difficulty: 0.001676 Share difficulty: 1.505790 2014-02-08 18:41:03.287006 New work for worker! Difficulty: 0.001676 Share difficulty: 0.058060 I have a couple dozen lines similar to the first. The 2nd is my testing with difficultly forced as low as it can go. Being a single GPU miner, 1.5 (98683) will take me far far longer to get 1 share than .058 (3805) would. Edit: Apologies for the thread hijack. mmouse we should move this to the P2Pool main thread or to the VTC thread. |
|
|
|
|
Hmmm. Even if I try to set /.00001 I can't see it changing anything on my miner's end. Using + of course submits diff 1 pseudo-shares constantly which is a waste of resources.
Looking at all of the New Work messages, they aren't all being set to the same difficulty. On my pool most are set to 0.00244 but one is .000812 and one is .000244. I assume those are the pseduo share difficulties and the tiny ones are the two slowest miners in pool?
Because yes, there is also the "Share difficulty: 1.918" which is going to all but 2 miners. One is me with my /.000001 forcing it down to match share difficulty. That other must be you or someone like you, setting a lower share difficulty with ADDR/ which means you'll actually have reduced variance since the difficulty chosen is still over the minimum.
Is it really 1 share total from all miners combined, or 1 share per minute from each miner individually? The latter would make more sense to me, but I'm thinking of it from a "running a pool-like public node" perspective. p2pool is designed from a "run it as a reduced variance solo mining operation" perspective.
|
|
|
|
|
Show Posts
