Search content
Sort by
Showing 9 of 9 results by gigabitfx
Re: [3500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Hi community, I have a instance of p2pool running on windows. I used the latest git available via forestv. The pool has been running all night, over 12 hours but when I submit a share to it, it doesn't contain any additional transaction fees in the share. How does p2pool include the transaction fees in shares, and what am I missing to have them included in mine. I have also followed the p2pool tuning post and have the min-max tx fees included in the bitcoin.conf file as well as server=1. Any other tips before I move the node to a Linux install to see if that corrects the issue. It should be also noted that im running the bitcoin-qt gui and mining the pool against that, perhaps I need to run the daemon? but no information on the web to say the gui client is limited vs the bitcoind.exe.
P2Pool gets the transactions from the bitcoin node it is running on, to see the current tx pool on your node run "bitcoind getrawmempool".
Setting the min/max tx fees in bitcoin.conf will determine what transactions are included in your transaction pool.
When your node finds a share that also meets the minimum bitcoin difficulty, the transactions in your bitcoin nodes tx pool are included in the block and broadcast to both the p2pool and bitcoin network.
Re: [3500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Hi community, I have a instance of p2pool running on windows. I used the latest git available via forestv. The pool has been running all night, over 12 hours but when I submit a share to it, it doesn't contain any additional transaction fees in the share. How does p2pool include the transaction fees in shares, and what am I missing to have them included in mine. I have also followed the p2pool tuning post and have the min-max tx fees included in the bitcoin.conf file as well as server=1. Any other tips before I move the node to a Linux install to see if that corrects the issue. It should be also noted that im running the bitcoin-qt gui and mining the pool against that, perhaps I need to run the daemon? but no information on the web to say the gui client is limited vs the bitcoind.exe.
Hey all. I ordered 4 units and 1 of the four units 8 asics never init; they are not over clocked. Ive had my fair share of running S1's so was used to the occasional reboot to resolve asics that drop offline. However these never come online and I've rebooted so many times I'm just ready to send it back for replacement.
The question i have is, how long does it generally take to receive a response back from bitmain? My initial question was sent to them using the website form over at bitmaintech.com on july 30th, and also another message sent on august 3rd. Im starting to worry at this point, thus me questioning the forums. Has anyone successfully submitted an RMA request and have any comments from experience on the process in general and how long do things take to get moving and to receive replacement?
The question i have is, how long does it generally take to receive a response back from bitmain? My initial question was sent to them using the website form over at bitmaintech.com on july 30th, and also another message sent on august 3rd. Im starting to worry at this point, thus me questioning the forums. Has anyone successfully submitted an RMA request and have any comments from experience on the process in general and how long do things take to get moving and to receive replacement?
New VTC mining pool
vtc.dnsd.me:9174
username: your VTC address
password: aaa
Pool Location: Florida
Running p2pool in the vercoin3 pool
Mining software:
Vertcoin.org official binaries
sgminer newer unofficial binaries
vtc.dnsd.me:9174
username: your VTC address
password: aaa
Pool Location: Florida
Running p2pool in the vercoin3 pool
Mining software:
Vertcoin.org official binaries
sgminer newer unofficial binaries
Point miners to:
vtc.dnsd.me:9174
username: your VTC address
password: aaa
Pool Location: Florida
Running p2pool in the vercoin3 pool
Mining software:
Vertcoin.org official binaries
sgminer newer unofficial binaries
vtc.dnsd.me:9174
username: your VTC address
password: aaa
Pool Location: Florida
Running p2pool in the vercoin3 pool
Mining software:
Vertcoin.org official binaries
sgminer newer unofficial binaries
Re: [460 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Looks like my pool stats did report normally after a couple shares were submitted, and I was also paid the other missing shares after I had restarted p2pool. Now I have a couple of questions maybe you can help me out with:
I would like to have each miner use a non wallet address rather than configure each miner with the same address for better individual tracking. I figured this could happen a couple ways, 1 would be to create a new receiving address in the wallet for each miner, but that seems to wasteful. 2. I was thinking to set the pool fee to 100% and set the -a payout address and then configure miners with any textual username I prefer.
How would one do this will the least amount of effort?
I'm actively developing the front end on my site, it's still in beta and requires PHP and a DB to be set up on the node.... It does address some of your concerns about not being able to see shares after a restart... I posted some of the preliminary code in this thread here if you want to check it out.
The expected time to share looks about right to me, here is one of my miners (2x S1), about double your speed, about 1/2 the expected time-to-share:
http://mining.coincadence.com/miner.php?id=13AxQAKFiy6Dks5Jwdbah3rhMJAJ9UzwHk
I would like to have each miner use a non wallet address rather than configure each miner with the same address for better individual tracking. I figured this could happen a couple ways, 1 would be to create a new receiving address in the wallet for each miner, but that seems to wasteful. 2. I was thinking to set the pool fee to 100% and set the -a payout address and then configure miners with any textual username I prefer.
How would one do this will the least amount of effort?
Can you share that frontend your using? Im used to mining on slush's pool so I understand a little about variance. mdude77 I do indeed have new cgminer for s1.
Im still confused about the data on the homepage and if my data is normal for a newly configured p2pool, or if i need to look further into it. Here is the stats listed
http://s2.postimg.org/lh6uy5iqx/Capture.jpg
Is the "expected time to share" normal for my node uptime? Ive seen others that show it down to an hour with similar pool speed as mine. I suppose most of my confusion is that with slushs pool i see shares coming in from my miners much more frequently than this and of course they state the average btc for current round as well. I feel im flying more blind with p2pool, especially with 0 as expected payout. The vanilla p2pool interface showed an expected payout number, even when pool was freshly fired up and went up/down as data came through.
Im still confused about the data on the homepage and if my data is normal for a newly configured p2pool, or if i need to look further into it. Here is the stats listed
http://s2.postimg.org/lh6uy5iqx/Capture.jpg
Is the "expected time to share" normal for my node uptime? Ive seen others that show it down to an hour with similar pool speed as mine. I suppose most of my confusion is that with slushs pool i see shares coming in from my miners much more frequently than this and of course they state the average btc for current round as well. I feel im flying more blind with p2pool, especially with 0 as expected payout. The vanilla p2pool interface showed an expected payout number, even when pool was freshly fired up and went up/down as data came through.
I'm actively developing the front end on my site, it's still in beta and requires PHP and a DB to be set up on the node.... It does address some of your concerns about not being able to see shares after a restart... I posted some of the preliminary code in this thread here if you want to check it out.
The expected time to share looks about right to me, here is one of my miners (2x S1), about double your speed, about 1/2 the expected time-to-share:
http://mining.coincadence.com/miner.php?id=13AxQAKFiy6Dks5Jwdbah3rhMJAJ9UzwHk
Re: [460 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Can you share that frontend your using? Im used to mining on slush's pool so I understand a little about variance. mdude77 I do indeed have new cgminer for s1.
Im still confused about the data on the homepage and if my data is normal for a newly configured p2pool, or if i need to look further into it. Here is the stats listed
http://s2.postimg.org/lh6uy5iqx/Capture.jpg
Is the "expected time to share" normal for my node uptime? Ive seen others that show it down to an hour with similar pool speed as mine. I suppose most of my confusion is that with slushs pool i see shares coming in from my miners much more frequently than this and of course they state the average btc for current round as well. I feel im flying more blind with p2pool, especially with 0 as expected payout. The vanilla p2pool interface showed an expected payout number, even when pool was freshly fired up and went up/down as data came through.
Hi Gigabit,
I'm by no means the expert, still studying the code and learning, but I'll give you my best advice and if I'm wrong, or there is a better solution hopefully someone will jump in...
1. It's constant.
2. Restarting will dump all your peers, and re-start many of the stats. Accepted shares will not be lost during a restart, but will not show on your stats page after, obviously shares submitted during a restart will be lost or stale by the time your node is back up. I try to limit restarts as much as possible.
3. Expected time to share is based on your ~estimated~ hash rate, is subject to your miners luck/variance, and can vary greatly.
4. Once you get some shares in the current block this will change, also subject to variance, some days will be higher and some lower.
5. I don't. There are some good tutorials for getting it up and running efficiently here on the forum, and on some alt-coin forums, but no definitive docs that I have found...
Here is an example of the variance/luck, the bottom 2 miners have both been consistently mining on p2pool, the bottom one is currently in a streak of good luck, while the middle one is in a streak of what I'd call less then ideal luck...
https://www.evernote.com/shard/s91/sh/7eb6221c-6c8d-4c28-a312-75f0814db881/4883b9429424359e3b46c058b2aa4f9f/deep/0/p2pool-variance1.png
It all balances out over time, a key to successfully mining on p2pool is having the patience and consistency to stick with it until it does
Im still confused about the data on the homepage and if my data is normal for a newly configured p2pool, or if i need to look further into it. Here is the stats listed
http://s2.postimg.org/lh6uy5iqx/Capture.jpg
Is the "expected time to share" normal for my node uptime? Ive seen others that show it down to an hour with similar pool speed as mine. I suppose most of my confusion is that with slushs pool i see shares coming in from my miners much more frequently than this and of course they state the average btc for current round as well. I feel im flying more blind with p2pool, especially with 0 as expected payout. The vanilla p2pool interface showed an expected payout number, even when pool was freshly fired up and went up/down as data came through.
Hi Gigabit,
I'm by no means the expert, still studying the code and learning, but I'll give you my best advice and if I'm wrong, or there is a better solution hopefully someone will jump in...
1. It's constant.
2. Restarting will dump all your peers, and re-start many of the stats. Accepted shares will not be lost during a restart, but will not show on your stats page after, obviously shares submitted during a restart will be lost or stale by the time your node is back up. I try to limit restarts as much as possible.
3. Expected time to share is based on your ~estimated~ hash rate, is subject to your miners luck/variance, and can vary greatly.
4. Once you get some shares in the current block this will change, also subject to variance, some days will be higher and some lower.
5. I don't. There are some good tutorials for getting it up and running efficiently here on the forum, and on some alt-coin forums, but no definitive docs that I have found...
Here is an example of the variance/luck, the bottom 2 miners have both been consistently mining on p2pool, the bottom one is currently in a streak of good luck, while the middle one is in a streak of what I'd call less then ideal luck...
https://www.evernote.com/shard/s91/sh/7eb6221c-6c8d-4c28-a312-75f0814db881/4883b9429424359e3b46c058b2aa4f9f/deep/0/p2pool-variance1.png
It all balances out over time, a key to successfully mining on p2pool is having the patience and consistency to stick with it until it does
Re: [460 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool
Hi Windpath, thanks for the info here, im running some s1 and was having hard time with google on a definitive response to setting the pseudo share.
couple of questions
1. is 0.00000116 a static constant, or based off dynamic number? Wondering if i need to redo the math periodically to keep my miners running efficiently.
2. do you know of any downsides to restarting p2pool, i noticed i lost a few shares once i had done so, but technically i dont understand why that would be. i did however update the -a payout address, perhaps that restages the pool?
3. "expected time to share" seems to stay around 7-12hrs, im assuming its because the pool doesn't have any stats to work off of yet?
4. "payout if a block were found NOW" seems to remain at 0, any tips on that?
5. know of any p2pool advanced docs/manuals out there?
Thanks for any info
If you have some new miners hitting your node you may want to set your share diff and pseudo share diff on your miner....
If your running S1's set to 0 ("0" defaults to lowest p2pool diff, currently 1677854.73)
And to 220.4 (optimized for 190GH/s)
is calculated as your hash rate in KH/s times 0.00000116
i.e. 190,000,000 * 0.00000116 = 220.4
Here is an example for an ant S1:
If you have a hash rate over 1TH/s you might consider upping your share diff to something higher then the p2pool minimum to reduce network traffic and increase the value of your shares...
[/quote]
couple of questions
1. is 0.00000116 a static constant, or based off dynamic number? Wondering if i need to redo the math periodically to keep my miners running efficiently.
2. do you know of any downsides to restarting p2pool, i noticed i lost a few shares once i had done so, but technically i dont understand why that would be. i did however update the -a payout address, perhaps that restages the pool?
3. "expected time to share" seems to stay around 7-12hrs, im assuming its because the pool doesn't have any stats to work off of yet?
4. "payout if a block were found NOW" seems to remain at 0, any tips on that?
5. know of any p2pool advanced docs/manuals out there?
Thanks for any info
Is it just me or did the p2pool hash rate just double to almost 1ph/s?!
I'm showing 682TH/s on my node, a nice jump....If you have some new miners hitting your node you may want to set your share diff and pseudo share diff on your miner....
Code:
bitcoin_address/+
If your running S1's set to 0 ("0" defaults to lowest p2pool diff, currently 1677854.73)
And to 220.4 (optimized for 190GH/s)
is calculated as your hash rate in KH/s times 0.00000116
i.e. 190,000,000 * 0.00000116 = 220.4
Here is an example for an ant S1:
Code:
19vXrwKGUhK4cCU8tA4kWZgbChcmh9a6qj/0+220.4
If you have a hash rate over 1TH/s you might consider upping your share diff to something higher then the p2pool minimum to reduce network traffic and increase the value of your shares...
[/quote]