Not bad huh?
HOW?Give us spec.
ps. update main topic, we passed 1000 GH/s
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 540. (Read 2591920 times)
Give us spec.
ps. update main topic, we passed 1000 GH/s
Not bad huh?
mintxfee=0.01 is too big imo, tx fee is calculate per 1kb of tx data, so if s1 is sending from p2pool mining account this can hurts.
w8 perhaps i missed a part, but the config file is the same of the old version 8.1?
because nothing has changed when i set the new parameters, the latency remain the same, with or without setting
because nothing has changed when i set the new parameters, the latency remain the same, with or without setting
Did you upgrade to 0.8.1rc1?
As I posted from my latency graph screenshot, the latency about halved with the new version at default settings on my system.
my concern is that even if i put those settings in the config file
mintxfee=0.01
minrelaytxfee=0.005
the latency remain the same as default
Nice!
2013-05-24 14:52:34.464483 Pool: 1000GH/s Stale rate: 16.5% Expected time to block: 13.3 hours
2013-05-24 14:52:34.464483 Pool: 1000GH/s Stale rate: 16.5% Expected time to block: 13.3 hours
Someone appears to be bringing more hardware online in the pool, approx 100GH/s in the last hour or so, my node is currently reporting 980GH/s
Are we going to break 1TH/s soon
Are we going to break 1TH/s soon
w8 perhaps i missed a part, but the config file is the same of the old version 8.1?
because nothing has changed when i set the new parameters, the latency remain the same, with or without setting
because nothing has changed when i set the new parameters, the latency remain the same, with or without setting
Did you upgrade to 0.8.1rc1?
As I posted from my latency graph screenshot, the latency about halved with the new version at default settings on my system.
w8 perhaps i missed a part, but the config file is the same of the old version 8.1?
because nothing has changed when i set the new parameters, the latency remain the same, with or without setting
because nothing has changed when i set the new parameters, the latency remain the same, with or without setting
Seen on the btcguild news page:
So I guess the ebil p2pool people weren't the only ones seeing the problem...
Quote
Stratum servers have recently had a patch applied to the bitcoind client which should reduce the time the servers spend waiting for new work to be generated when a block is found on the network. This should result in fewer stales for all users on Stratum, who have seen stale rates increasing due to performance issues in bitcoind the last week.
So I guess the ebil p2pool people weren't the only ones seeing the problem...
Ah yeah - I forgot to completely ignore the fact (like you are) that the big pools are confirming the transactions that you aren't ...
So yet again your excuse for proving p2pool is worse for bitcoin is that ... there's apparently a problem with bitcoind that the big pools can work around ... and then you get posts like the one above this post ...
I also notice that gmaxwell is completely avoiding posting here ... yes he's an avid proponent of p2pool ... maybe there's a reason he's not commenting in here ...
So yet again your excuse for proving p2pool is worse for bitcoin is that ... there's apparently a problem with bitcoind that the big pools can work around ... and then you get posts like the one above this post ...
I also notice that gmaxwell is completely avoiding posting here ... yes he's an avid proponent of p2pool ... maybe there's a reason he's not commenting in here ...
What's your point again? Sorry kano, but your bullshitting is so thick I don't even know what you are bullshitting about now.
Pulled the latest git... (reports itself as "version" : 80201)
Nice... Latency has dropped waaay down.
http://ask.gxsnmp.org/
Nice... Latency has dropped waaay down.
http://ask.gxsnmp.org/
I pulled down the latest bitcoind from Git yesterday and rebuilt it (rather than using the Ubuntu PPA).
The latency at a bit over 12s is version 0.8.1 from the PPA. No matter what changes I made to the config, it would always climb up to that within a couple of hours.
The next step is 0.8.2rc1 from Git with all values at the default. Definitely a lot better. I'm getting a lot of non-standard transaction type messages in the log, which I am assuming is transactions that fail the new dust test. I have deb files for Ubuntu 12.04 AMD64 if anyone is interested.
The last step is setting the mintxfee and minrelaytxfee to double the default values:
I am mining blocks with transaction fees (133 transactions at the moment), although that's a bit moot anyway because I haven't actually solved a block in the whole time I've been mining, but still.
I'm hoping that's a reasonable tradeoff between a p2pool node that generates some income and contributing to the greater bitcoin network.
The latency at a bit over 12s is version 0.8.1 from the PPA. No matter what changes I made to the config, it would always climb up to that within a couple of hours.
The next step is 0.8.2rc1 from Git with all values at the default. Definitely a lot better. I'm getting a lot of non-standard transaction type messages in the log, which I am assuming is transactions that fail the new dust test. I have deb files for Ubuntu 12.04 AMD64 if anyone is interested.
The last step is setting the mintxfee and minrelaytxfee to double the default values:
Code:
mintxfee=0.001
minrelaytxfee=0.001
I am mining blocks with transaction fees (133 transactions at the moment), although that's a bit moot anyway because I haven't actually solved a block in the whole time I've been mining, but still.
I'm hoping that's a reasonable tradeoff between a p2pool node that generates some income and contributing to the greater bitcoin network.
I still think they should implement this call on top of an asynchronous update of the block template to make the RPC call o(1) instead of o(nb_tx) or worse though. In the worst case, even if some params of getblocktemplate don't allow to precompute most of the template at least the common case scenario with no parameter can be sped up.
Suggested it, hopefully sipa will be interested enough to either explain why it can't work or make a mental note of the idea for the next performance roadblock.
gmaxwell's comment makes me think the discussion about async processing of templates should be taken here. I'm wondering if forrestv implemented a p2pool template cache with the same approach I suggested could be provided by bitcoind. Especially just after a new block found on the network (see the comment here). There's no explicit configuration of bitcoind done to make signal p2pool new blocks so is it detecting them by calling a fast RPC method of bitcoind or is there a delay that could be shortened by using the "blocknotify" bitcoind option for example?
So yet again your excuse for proving p2pool is worse for bitcoin is that ... there's apparently a problem with bitcoind that the big pools can work around ... and then you get posts like the one above this post ...
I also notice that gmaxwell is completely avoiding posting here ... yes he's an avid proponent of p2pool ... maybe there's a reason he's not commenting in here ...
mintxfee=0.002
minrelaytxfee=0.002
those setting are the best for me, latency is now stable at 0.223
minrelaytxfee=0.002
those setting are the best for me, latency is now stable at 0.223
I still think they should implement this call on top of an asynchronous update of the block template to make the RPC call o(1) instead of o(nb_tx) or worse though. In the worst case, even if some params of getblocktemplate don't allow to precompute most of the template at least the common case scenario with no parameter can be sped up.
Suggested it, hopefully sipa will be interested enough to either explain why it can't work or make a mental note of the idea for the next performance roadblock.
gmaxwell's comment makes me think the discussion about async processing of templates should be taken here. I'm wondering if forrestv implemented a p2pool template cache with the same approach I suggested could be provided by bitcoind. Especially just after a new block found on the network (see the comment here). There's no explicit configuration of bitcoind done to make signal p2pool new blocks so is it detecting them by calling a fast RPC method of bitcoind or is there a delay that could be shortened by using the "blocknotify" bitcoind option for example?
WOW! How?
1) actual bitcoin from git ( moves variables ...Fees.. from main.h to main.cpp)
2) set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000; # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;
3) compile bitcoin
4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0
Greets
I did what is stated above to the latest 0.8.2rc1 bitcoin-qt and my GBT latency is 3.00 ms (.003 s). Make these changes along with the changes Sipa is recommending should speed things up no?
I still think they should implement this call on top of an asynchronous update of the block template to make the RPC call o(1) instead of o(nb_tx) or worse though. In the worst case, even if some params of getblocktemplate don't allow to precompute most of the template at least the common case scenario with no parameter can be sped up.
Suggested it, hopefully sipa will be interested enough to either explain why it can't work or make a mental note of the idea for the next performance roadblock.
Sipa(one of the bitcoin developrs) did a pull request which may help with this https://github.com/bitcoin/bitcoin/pull/2677
Slush had similar problems on his pool and it was causing high invalids.
Slush had similar problems on his pool and it was causing high invalids.
Oh look, people with a clue do what we wished for! How surprising...
It clearly will help: a 10x improvement in getblocktemplate will bring fresh air.
I still think they should implement this call on top of an asynchronous update of the block template to make the RPC call o(1) instead of o(nb_tx) or worse though. In the worst case, even if some params of getblocktemplate don't allow to precompute most of the template at least the common case scenario with no parameter can be sped up.
Sipa(one of the bitcoin developrs) did a pull request which may help with this https://github.com/bitcoin/bitcoin/pull/2677
Slush had similar problems on his pool and it was causing high invalids.
Slush had similar problems on his pool and it was causing high invalids.
Same people still living in denial. Please, do press the ignore button......
Jump to: