Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 188. (Read 2591920 times)
April 26, 2015, 10:31:11 AM
Block! Too bad we didn't get that one with the 85BTC in transaction fees. I would have felt bad if we had, though. The poor guy who sent that never meant to send those coins as transaction fees, but the script he used screwed him. At least since it was included in a block by AntPool, maybe he might get lucky and be reimbursed. Good luck that happening here, where the transaction fees would have been distributed to every p2pool miner.
April 26, 2015, 09:56:38 AM
and when you open the task manager ? 
April 25, 2015, 07:04:22 PM
i wait my bitcoin 0.10 sync the network.
i already download the torrent..
i already import that bootstrap.dat, and now going bootstrap.dat
but still 19 week waiting..
i reindexing the block.. still same..
i connect to peer that have high connection, still same..
more than 48hrs, still same..
what i must do?
i using windows 7 to running that bitcoin core.
i already download the torrent..
i already import that bootstrap.dat, and now going bootstrap.dat
but still 19 week waiting..
i reindexing the block.. still same..
i connect to peer that have high connection, still same..
more than 48hrs, still same..
what i must do?
i using windows 7 to running that bitcoin core.
April 25, 2015, 06:11:55 PM
I don't see why the version wouldn't stick after a restart, but we'll see...
The filesystem you see when S5s are running is in ram only, it is not on the flash storage in the device. It needs to be embedded in the firmware for it to be on the flash storage. One day maybe there will be actual firmware you can use in the regular fashion if we can get coordinated with bitmain. Bitmain USA is more receptive to involving us than their main China group. April 25, 2015, 04:29:03 PM
you don't have many on P2Pool to carry 4Th/s ... by default.
how many connexion have you assigned to bitcoin core server and P2Pool node process ?
that can be the 100% CPU ... (check max connexion limit, too)
how many connexion have you assigned to bitcoin core server and P2Pool node process ?
that can be the 100% CPU ... (check max connexion limit, too)
April 25, 2015, 04:19:52 PM
not relevant
What do you mean "not revelant"? That it's not really a bad node? April 25, 2015, 04:04:16 PM
my "bad peers" are:
117.9.135.126 ← This one was the worst, pestering node
211.72.66.229
125.227.225.237
117.9.135.126 ← This one was the worst, pestering node
211.72.66.229
125.227.225.237
1)
116.255.241.111 - 116.255.241.111 , 000 , SMSHoax FakeAV Fraud Trojan
117.011.101.172 - 117.011.101.172 , 000 , Detected AP2P on China Unicom
not relevant.
2)
211.072.061.136 - 211.072.061.143 , 000 , Armed Forces Taichung General Hospital
211.072.066.128 - 211.072.066.255 , 000 , Reuters Limited Taiwan Brauch
211.072.083.172 - 211.072.083.175 , 000 , Creative Images Computer Graphic Co., Ltd
Got it.
3)
125.221.046.000 - 125.221.046.255 , 000 , Xunlei Offline
125.232.071.231 - 125.232.071.231 , 000 , datingnearby.com
not relevant.
April 25, 2015, 02:16:14 PM
2 days ago there was one or more misbehaving p2pool nodes, causing major havoc on my node for about an hour when I finally blocked the IP's at my firewall. My hashrate was dropping at times and I was seeing a lot of LOST CONTACT WITH BITCOIND, because my p2pool/python process was maxing the CPU with nonstop processing of transaction errors. I also had to stop the relaynetworkclient connection because it was passing along the same transactions.
I am not sure which node, or nodes, was causing the problem. All 4 IP's below were banned by p2pool 3 times within a few hours. I eventually blocked the IP's at firewall, which fixed the issue.
2015-04-23 16:13:02.749344 Bad peer banned: ('61.161.171.210', 51265)
2015-04-23 16:59:10.000062 Bad peer banned: ('221.213.100.225', 58179)
2015-04-23 17:01:05.902169 Bad peer banned: ('117.9.135.126', 29857)
2015-04-23 17:02:25.937494 Bad peer banned: ('116.53.251.126', 58333)
My hashrate dropped because the issue.
Yes, I think this is what I experienced, too. I'll block those IPs, too. thank youI am not sure which node, or nodes, was causing the problem. All 4 IP's below were banned by p2pool 3 times within a few hours. I eventually blocked the IP's at firewall, which fixed the issue.
2015-04-23 16:13:02.749344 Bad peer banned: ('61.161.171.210', 51265)
2015-04-23 16:59:10.000062 Bad peer banned: ('221.213.100.225', 58179)
2015-04-23 17:01:05.902169 Bad peer banned: ('117.9.135.126', 29857)
2015-04-23 17:02:25.937494 Bad peer banned: ('116.53.251.126', 58333)
My hashrate dropped because the issue.
my "bad peers" are:
117.9.135.126 ← This one was the worst, pestering node
211.72.66.229
125.227.225.237
These IPs are from China and Taiwan.
All yours are from China.
(You can lookup their locations here.)
I'm not sure why it says my own local and WAN addresses are banned, too, though.
April 25, 2015, 02:12:46 PM
Setting the queue to 0 means the miner doesn't have a whole bunch of stale work to complete when p2pool tells it to start fresh. You are not speeding up p2pool, you are having your miner work on relevant data in a timely fashion. By default, the Ants set the queue to some absurdly high numbers.
Yes, 8192 by defaultThe release of cgminer by ck sets it to 1 by default.
I'm not sure why your hash rate would drop by 90%, but the queue setting is not the cause.
I think it had to do with my machine not giving runp2pool.py enough priority at that time. I also had lots of incoming connections, too, which might've slowed things down. I don't think it was the miner's issue.I'm not sure why your hash rate would drop by 90%, but the queue setting is not the cause.
This may be related, but if not I still want to pass along this info.
2 days ago there was one or more misbehaving p2pool nodes, causing major havoc on my node for about an hour when I finally blocked the IP's at my firewall. My hashrate was dropping at times and I was seeing a lot of LOST CONTACT WITH BITCOIND, because my p2pool/python process was maxing the CPU with nonstop processing of transaction errors. I also had to stop the relaynetworkclient connection because it was passing along the same transactions.
I am not sure which node, or nodes, was causing the problem. All 4 IP's below were banned by p2pool 3 times within a few hours. I eventually blocked the IP's at firewall, which fixed the issue.
2015-04-23 16:13:02.749344 Bad peer banned: ('61.161.171.210', 51265)
2015-04-23 16:59:10.000062 Bad peer banned: ('221.213.100.225', 58179)
2015-04-23 17:01:05.902169 Bad peer banned: ('117.9.135.126', 29857)
2015-04-23 17:02:25.937494 Bad peer banned: ('116.53.251.126', 58333)
My hashrate dropped because the issue.
April 25, 2015, 01:37:40 PM
Setting the queue to 0 means the miner doesn't have a whole bunch of stale work to complete when p2pool tells it to start fresh. You are not speeding up p2pool, you are having your miner work on relevant data in a timely fashion. By default, the Ants set the queue to some absurdly high numbers.
Yes, 8192 by defaultThe release of cgminer by ck sets it to 1 by default.
I'm not sure why your hash rate would drop by 90%, but the queue setting is not the cause.
I think it had to do with my machine not giving runp2pool.py enough priority at that time. I also had lots of incoming connections, too, which might've slowed things down. I don't think it was the miner's issue. I'm not sure why your hash rate would drop by 90%, but the queue setting is not the cause.
April 25, 2015, 01:27:35 PM
Is that something new with the S5? I have S3s and replacing the binary is certainly not in volatile memory. I've heard that changes you make to the init.d scripts might get lost on reboot.
Yes, I know at least the init screpts are lost, but perhaps you're right and the binary is not in volatile memory. I personally haven't tested it to be sure. April 25, 2015, 01:14:45 PM
My guess is you had this TX in your node unconfirmed TX pool:
https://blockchain.info/tx/860e4e6bc2b846f00a1660dcb49d84a00dcd7b87ba23100e836dfb682249a807
Over 85 BTC in miner fees, AntPool got the block, it was not an intentional fee...
http://www.reddit.com/r/Bitcoin/comments/33u2id/help_losing_over_85_btc_because_of_bitgos_flawed/
Yep. Bummer. Was exciting for a moment.
April 25, 2015, 01:11:02 PM
If ever the S5 reboots, you'll have to do this process again, since the new cgminer is in volatile memory.
That might be a deal breaker for me. I appreciate your response, but I don't think this is a reasonable approach for a larger farm. I will do some testing on my more stable units though thanks to your guide. I do wish bitmain would open source their firmware so that an easier and more permanent solution could be implemented.
In any case, couldn't you just write a simple script to execute on boot that does these steps? Or would any script you write also get lost on the reboot? There's got to be some place that's not lost on a reboot...
From what I can tell, only /config is non-volatile. I have a "management" Linux host I use to run scripts in /config post reboot, simply by SSH'ing to the S5's.
April 25, 2015, 01:09:52 PM
My predicted payout went from .06 to .25. Sounds good to me, but what gives? I'm seeing 111.18384982 BTC total to be paid.
My predicted payout went from .06 to .25. Sounds good to me, but what gives?
My guess is you had this TX in your node unconfirmed TX pool:
https://blockchain.info/tx/860e4e6bc2b846f00a1660dcb49d84a00dcd7b87ba23100e836dfb682249a807
Over 85 BTC in miner fees, AntPool got the block, it was not an intentional fee...
http://www.reddit.com/r/Bitcoin/comments/33u2id/help_losing_over_85_btc_because_of_bitgos_flawed/
April 25, 2015, 12:51:45 PM
If ever the S5 reboots, you'll have to do this process again, since the new cgminer is in volatile memory.
That might be a deal breaker for me. I appreciate your response, but I don't think this is a reasonable approach for a larger farm. I will do some testing on my more stable units though thanks to your guide. I do wish bitmain would open source their firmware so that an easier and more permanent solution could be implemented.
In any case, couldn't you just write a simple script to execute on boot that does these steps? Or would any script you write also get lost on the reboot? There's got to be some place that's not lost on a reboot...
April 25, 2015, 12:50:16 PM
If ever the S5 reboots, you'll have to do this process again, since the new cgminer is in volatile memory.
That might be a deal breaker for me. I appreciate your response, but I don't think this is a reasonable approach for a larger farm. I will do some testing on my more stable units though thanks to your guide. I do wish bitmain would open source their firmware so that an easier and more permanent solution could be implemented. April 25, 2015, 12:47:55 PM
My predicted payout went from .06 to .25. Sounds good to me, but what gives? I'm seeing 111.18384982 BTC total to be paid.
My predicted payout went from .06 to .25. Sounds good to me, but what gives?
April 25, 2015, 12:47:25 PM
If ever the S5 reboots, you'll have to do this process again, since the new cgminer is in volatile memory.
That might be a deal breaker for me. I appreciate your response, but I don't think this is a reasonable approach for a larger farm. I will do some testing on my more stable units though thanks to your guide. I do wish bitmain would open source their firmware so that an easier and more permanent solution could be implemented.
EDIT: I went ahead and updated my s5's to the latest cgminer. I don't see why the version wouldn't stick after a restart, but we'll see...
April 25, 2015, 12:45:39 PM
My predicted payout went from .06 to .25. Sounds good to me, but what gives? I'm seeing 111.18384982 BTC total to be paid.
My predicted payout went from .06 to .25. Sounds good to me, but what gives?
No clue... I'm seeing the same thing. All predicted payouts are off. Look at the top 2 miners... their combined expected payout is over 34BTC. April 25, 2015, 12:34:22 PM
How do you use this? Do you update it the same way you would update the s5 firmware? Anyone want to point me in the right direction of some instructions?
Here's what I did under Linux, at the command-line:
Code:
ssh root@
Enter "admin" for the password.Now you'll be at a prompt that says "root@
Type
Code:
cd /tmp
wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
mv cgminer /usr/bin/
/etc/init.d/cgminer.sh restart
If ever the S5 reboots, you'll have to do this process again, since the new cgminer is in volatile memory.wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
mv cgminer /usr/bin/
/etc/init.d/cgminer.sh restart
Another thing to do is set "--queue 0":
Code:
vi /etc/init.d/cgminer.sh
Change "--queue $queue_value" on line 69 to "--queue 0".(If you're not familiar with how to edit files in vi, check this out.)
Basically, you can use your arrow keys to go to line 69, type "i" to go into "insertion mode", which allows inserting and deleting text. When you've made the correction, hit the ESC key and then type ":wq".
Run
Code:
/etc/init.d/cgminer.sh restart
again to make the changes take effect.-ck's cgminer version 4.9 is really an improvement over cgminer 4.8 in Bitmain's firmware. You can be certain stales are being submitted and not ignored. Ever since I started using it, I've been getting blazing fast, stable hash rates (1.2 Thash/s per S5 average) and DOAs about ⅓ the average, pool rate. I also ceased having the strange ramping-down / plumetting hashrate issues some have reported cgminer having with S5s.
Jump to: