It seems we are way better with orpahans, we still need a massive infusion of hashing power, though.
BTW, given that you're now using a faster virtual server, could you fireduck increase block size?
This would increase fees paid to block's solver which in the end should give people one more reason to join us.
spiccioli
Topic: [~32 TH] HHTT - Selected Diff/Stratum/PPLNS/Paid Stales/High Availability/Tor - page 10. (Read 29733 times)
September 30, 2013, 03:16:11 PM
September 26, 2013, 05:52:48 PM
Good start to the swing.
Well, let's hope 1E8xj fixes his troubles fast... or we're down 2 TH
spiccioli
September 26, 2013, 04:35:43 PM
Good start to the swing.
Well, let's hope 1E8xj fixes his troubles fast... or we're down 2 TH
spiccioli
September 26, 2013, 05:30:03 AM
Good start to the swing.
September 24, 2013, 03:30:51 PM
and the you wake up and...
https://bitcointalksearch.org/topic/m.3220533
btw, a new fake orpahan did show up yesterday
http://blockchain.info/search?search=0000000000000001ae09ea8b40865bc31a7f8605412b1ace4f5b7a6357d0416e
spiccioli
https://bitcointalksearch.org/topic/m.3220533
btw, a new fake orpahan did show up yesterday
http://blockchain.info/search?search=0000000000000001ae09ea8b40865bc31a7f8605412b1ace4f5b7a6357d0416e
spiccioli
Yeah, my GCE migration didn't fix everything. I now added a bunch of logging to SockThing so that I can track down exactly what was happening or not happening.
I saw an instance where two of my nodes didn't see a new block for a over a minute and then eventually learned it. So I took some steps to improve the p2p network and ensure that my nodes are connected at least to each other to increase coverage.
September 24, 2013, 02:09:32 AM
and the you wake up and...
https://bitcointalksearch.org/topic/m.3220533
btw, a new fake orpahan did show up yesterday
http://blockchain.info/search?search=0000000000000001ae09ea8b40865bc31a7f8605412b1ace4f5b7a6357d0416e
spiccioli
https://bitcointalksearch.org/topic/m.3220533
btw, a new fake orpahan did show up yesterday
http://blockchain.info/search?search=0000000000000001ae09ea8b40865bc31a7f8605412b1ace4f5b7a6357d0416e
spiccioli
September 23, 2013, 02:25:26 AM
I think one of the causes of orphans is that my bitcoind instances are taking 5-10 seconds to do a getblocktemplate so we end up working on the old block longer than we should.
I've done some testing and this seems to be due to not good disk latency on AWS EC2 instances. I've done testing with Google Compute Engine and numbers there are much better.
I've setup a test instance, us-central on GCE and am doing some production testing there. If it goes well, I'll switch everyone over to GCE probably this week.
I've done some testing and this seems to be due to not good disk latency on AWS EC2 instances. I've done testing with Google Compute Engine and numbers there are much better.
I've setup a test instance, us-central on GCE and am doing some production testing there. If it goes well, I'll switch everyone over to GCE probably this week.
New nodes are up. stratum.hhtt.1209k.com is pointing to them.
They are:
us-central-1.hhtt.1209k.com
us-central-2.hhtt.1209k.com
eu-west-1.hhtt.1209k.com
Extremely efficient pool operator that fireduck.
September 22, 2013, 11:42:48 PM
But we're still missing those 1.5 TH/s.
I'd like to know: why did he leave and where has he gone.
I'd like to know: why did he leave and where has he gone.
Talked with him again this past week. He no longer controls the hashpower is my understanding.
September 22, 2013, 10:27:29 PM
I think one of the causes of orphans is that my bitcoind instances are taking 5-10 seconds to do a getblocktemplate so we end up working on the old block longer than we should.
I've done some testing and this seems to be due to not good disk latency on AWS EC2 instances. I've done testing with Google Compute Engine and numbers there are much better.
I've setup a test instance, us-central on GCE and am doing some production testing there. If it goes well, I'll switch everyone over to GCE probably this week.
I've done some testing and this seems to be due to not good disk latency on AWS EC2 instances. I've done testing with Google Compute Engine and numbers there are much better.
I've setup a test instance, us-central on GCE and am doing some production testing there. If it goes well, I'll switch everyone over to GCE probably this week.
New nodes are up. stratum.hhtt.1209k.com is pointing to them.
They are:
us-central-1.hhtt.1209k.com
us-central-2.hhtt.1209k.com
eu-west-1.hhtt.1209k.com
September 22, 2013, 01:40:48 PM
I think one of the causes of orphans is that my bitcoind instances are taking 5-10 seconds to do a getblocktemplate so we end up working on the old block longer than we should.
I've done some testing and this seems to be due to not good disk latency on AWS EC2 instances. I've done testing with Google Compute Engine and numbers there are much better.
I've setup a test instance, us-central on GCE and am doing some production testing there. If it goes well, I'll switch everyone over to GCE probably this week.
I've done some testing and this seems to be due to not good disk latency on AWS EC2 instances. I've done testing with Google Compute Engine and numbers there are much better.
I've setup a test instance, us-central on GCE and am doing some production testing there. If it goes well, I'll switch everyone over to GCE probably this week.
Are you running the latest bitcoind? 5-10 seconds is a very long time, even for the crappy performance you get with AWS. GBT is very single-core CPU and HDD intensive, and AWS uses many-cores with relatively slow clock rates, and disk access speeds are always garbage.
Best specs you can get for GBT: High clock speed modern CPU (E3-1230v2 is beastly for this since it has a 3.7 Ghz turbo, 3.3 baseline), and SSD. Another alternative is storing the blockchain on a ramdisk, but that's only an option if you've got a dedicated machine with 32GB+ of RAM.
Yep, latest bitcoind. Yeah, GBT seems to be entirely disk latency based. I can't really afford the high memory machines for this project.
Anyways, with GCE I am getting 0.05 seconds for getblocktemplate which is quite an improvement for very similar price.
September 22, 2013, 01:26:15 PM
I think one of the causes of orphans is that my bitcoind instances are taking 5-10 seconds to do a getblocktemplate so we end up working on the old block longer than we should.
I've done some testing and this seems to be due to not good disk latency on AWS EC2 instances. I've done testing with Google Compute Engine and numbers there are much better.
I've setup a test instance, us-central on GCE and am doing some production testing there. If it goes well, I'll switch everyone over to GCE probably this week.
I've done some testing and this seems to be due to not good disk latency on AWS EC2 instances. I've done testing with Google Compute Engine and numbers there are much better.
I've setup a test instance, us-central on GCE and am doing some production testing there. If it goes well, I'll switch everyone over to GCE probably this week.
Are you running the latest bitcoind? 5-10 seconds is a very long time, even for the crappy performance you get with AWS. GBT is very single-core CPU and HDD intensive, and AWS uses many-cores with relatively slow clock rates, and disk access speeds are always garbage.
Best specs you can get for GBT: High clock speed modern CPU (E3-1230v2 is beastly for this since it has a 3.7 Ghz turbo, 3.3 baseline), and SSD. Another alternative is storing the blockchain on a ramdisk, but that's only an option if you've got a dedicated machine with 32GB+ of RAM.
September 22, 2013, 01:03:26 PM
I think one of the causes of orphans is that my bitcoind instances are taking 5-10 seconds to do a getblocktemplate so we end up working on the old block longer than we should.
I've done some testing and this seems to be due to not good disk latency on AWS EC2 instances. I've done testing with Google Compute Engine and numbers there are much better.
I've setup a test instance, us-central on GCE and am doing some production testing there. If it goes well, I'll switch everyone over to GCE probably this week.
I've done some testing and this seems to be due to not good disk latency on AWS EC2 instances. I've done testing with Google Compute Engine and numbers there are much better.
I've setup a test instance, us-central on GCE and am doing some production testing there. If it goes well, I'll switch everyone over to GCE probably this week.
September 22, 2013, 06:45:33 AM
Here's the discussion on my pool about the same same short block/orphan issue.
September 22, 2013, 04:59:25 AM
It looks like Blockchain.info does not update orphaned blocks fast enough "20 SEP" is the last orphan , or it could be here https://blockchain.info/rejected
September 22, 2013, 03:56:16 AM
it has the same hour of a found block, just a few seconds later, so was it not even submitted to the bitcoin network?
Is it a real orpahan?
I have had the same on my pool which uses the same stratum software as HHTT. I wonder if there's an issue somewhere. I'd get a 'block' with 20 seconds of another which is never submitted to the network. Is it a real orpahan?
September 22, 2013, 02:56:13 AM
Three blocks, but another "strange" orpahan, strange in that it is not found on blockchain.info
http://blockchain.info/search?search=00000000000000078b9fc485c97a58595752ef178dedb8ada97eb634212e21f4
it has the same hour of a found block, just a few seconds later, so was it not even submitted to the bitcoin network?
Is it a real orpahan?
spiccioli
http://blockchain.info/search?search=00000000000000078b9fc485c97a58595752ef178dedb8ada97eb634212e21f4
it has the same hour of a found block, just a few seconds later, so was it not even submitted to the bitcoin network?
Is it a real orpahan?
spiccioli
September 21, 2013, 01:26:21 PM
It seems we're talking about 6 TH/s which would double us (if they ever come) and make HHTT a little less the size of p2pool.
spiccioli
September 21, 2013, 12:41:58 AM
It looks like miners have their rigs on rotate.
September 20, 2013, 05:14:51 PM
Oh well,
I've left a call to arms...
If it really happens that a sizeable chunks of BitCentury customers points their miners here... well, dreaming costs nothing, doesn't it?
spiccioli
ps. A small pool like this finds it hard to have users joining it one after the other, because new users prefer to point their gears to a bigger one for reduced variance, but if five or ten TH/s (I don't know how many TH/s BitCentury sold) come here all at the same time, it should work, since everyone reduces the variance that the others feel.
I've left a call to arms...
If it really happens that a sizeable chunks of BitCentury customers points their miners here... well, dreaming costs nothing, doesn't it?
spiccioli
ps. A small pool like this finds it hard to have users joining it one after the other, because new users prefer to point their gears to a bigger one for reduced variance, but if five or ten TH/s (I don't know how many TH/s BitCentury sold) come here all at the same time, it should work, since everyone reduces the variance that the others feel.
September 19, 2013, 03:10:44 AM
Don't know what block you are looking at. Don't see that in the last few days of found blocks....
Redacted,
it's the last orpahan.
In march we had 6 orpahan though, so this is not the first time...
spiccioli
Jump to: