spiccioli (OP)
Legendary
 Offline
Activity: 1378
Merit: 1003
nec sine labore
|
 |
September 17, 2013, 09:56:16 AM |
|
Sure!
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 mean, we should know why people leave otherwise in a couple of difficulty jumps mining here and mining solo will mostly be the same...
spiccioli
|
|
|
|
|
|
|
|
|
|
"There should not be any signed int. If you've found a signed int
somewhere, please tell me (within the next 25 years please) and I'll
change it to unsigned int." -- Satoshi
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
JorgePasada
Member
Offline
Activity: 61
Merit: 10
|
|
September 17, 2013, 11:59:14 PM |
|
Sure!
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 mean, we should know why people leave otherwise in a couple of difficulty jumps mining here and mining solo will mostly be the same...
spiccioli
If it's who I think it is, I might be seeing him tonight, I'll try and coax him back on the pool. Not positive it is though. People seem to be pretty fickle about jumping hash power when pools get unlucky. I don't understand it, either just split it and keep it split or don't move it. It all averages out and nobody is good at 'picking winners'. |
|
|
|
|
spiccioli (OP)
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
September 18, 2013, 06:14:36 AM |
|
If it's who I think it is, I might be seeing him tonight, I'll try and coax him back on the pool. Not positive it is though.
Well, even if he does not come back, I'd like to know why he moved and where he moved  We're in a chicken and egg situation, we need moar power to attract people which will add moar power which... spiccioli |
|
|
|
|
spiccioli (OP)
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
September 19, 2013, 06:40:38 AM |
|
One good today, but one orpahan yesterday... fireduck, can you verify all is working ok? I mean, for months we had 1 orpahan/month, our hashing power being more or less the same, in september alone we have 5 blocks plus one on august 31st.  spiccioli |
|
|
|
|
spiccioli (OP)
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
September 19, 2013, 06:43:40 AM |
|
|
|
|
|
|
|
-Redacted-
|
|
September 19, 2013, 07:04:00 AM |
|
Don't know what block you are looking at. Don't see that in the last few days of found blocks....
|
|
|
|
|
spiccioli (OP)
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
September 19, 2013, 07: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 |
|
|
|
|
spiccioli (OP)
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
September 20, 2013, 09: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. |
|
|
|
|
|
Polyatomic
|
|
September 21, 2013, 04:41:58 AM
Last edit: September 21, 2013, 11:41:08 PM by Polyatomic |
|
It looks like miners have their rigs on rotate.
|
|
|
|
|
spiccioli (OP)
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
September 21, 2013, 05: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 |
|
|
|
|
|
|
doublec
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
September 22, 2013, 07: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. |
|
|
|
|
|
|
doublec
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
September 22, 2013, 10:45:33 AM |
|
Here's the discussion on my pool about the same same short block/orphan issue. |
|
|
|
|
|
fireduck
|
|
September 22, 2013, 05: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.
|
Bitrated user: fireduck.
|
|
|
eleuthria
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
September 22, 2013, 05: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.
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. |
RIP BTC Guild, April 2011 - June 2015
|
|
|
|
fireduck
|
|
September 22, 2013, 05: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.
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. |
Bitrated user: fireduck.
|
|
|
|
fireduck
|
|
September 23, 2013, 02:27:29 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.
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 |
Bitrated user: fireduck.
|
|
|
JorgePasada
Member
Offline
Activity: 61
Merit: 10
|
|
September 23, 2013, 03:42:48 AM |
|
But we're still missing those 1.5 TH/s.
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. |
|
|
|
|
|
Polyatomic
|
|
September 23, 2013, 06: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.
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. |
|
|
|
|
|
