Tigggger
Legendary
Offline
Activity: 1098
Merit: 1000
|
|
July 01, 2014, 11:38:53 AM |
|
So we are finally going to have closed shifts with no blocks found...
Cry
|
|
|
|
guytechie
|
|
July 01, 2014, 11:44:43 AM Last edit: July 01, 2014, 11:55:26 AM by guytechie |
|
Has NMC moved one bit, too?
Edit: we found one finally! No 0 block yet closed yet, but it was damn close!
|
Put something in my tip jar if I made your day. BTC: 1MkmBHDjonAFXui6JEx9ZmEemfMtUo9Cmu
|
|
|
Sir Alan
|
|
July 01, 2014, 12:05:51 PM |
|
(Sigh) Over 12½ hours. I was just about to start sticking pins in a wax effigy of Ghash.io.
|
1Eeyore17YeHrbJW5Q3pSdV8sXujkdrrFc
|
|
|
Tigggger
Legendary
Offline
Activity: 1098
Merit: 1000
|
|
July 01, 2014, 12:09:50 PM |
|
Has NMC moved one bit, too?
Edit: we found one finally! No 0 block yet closed yet, but it was damn close!
It's on the stats page, and on the blockchain but not on the PPLNS stats, so we have a closed 0 shift after that block was found ?? EDIT: It just updated to show 1 block.
|
|
|
|
guytechie
|
|
July 01, 2014, 12:24:54 PM |
|
Has NMC moved one bit, too?
Edit: we found one finally! No 0 block yet closed yet, but it was damn close!
It's on the stats page, and on the blockchain but not on the PPLNS stats, so we have a closed 0 shift after that block was found ?? EDIT: It just updated to show 1 block. That's because the block was found when that shift was open. It's not when the block is confirmed.
|
Put something in my tip jar if I made your day. BTC: 1MkmBHDjonAFXui6JEx9ZmEemfMtUo9Cmu
|
|
|
kendog77
|
|
July 01, 2014, 01:16:26 PM |
|
Can we please go back to average luck? 80-90% luck seems like the new normal. I really don't want to switch over to the dark side (GHash.IO).
|
|
|
|
DaveF
Legendary
Offline
Activity: 3598
Merit: 6581
Crypto Swap Exchange
|
|
July 01, 2014, 03:50:33 PM |
|
Dev and IXC only add about 0.1% more to your profits and it's another coin you have to send to an exchange and then dump for Bitcoin (assuming you only want BTC). I think the uptime and security affording by this pool and others like Bitminter and Elegius exceed the paltry add on of those coins.
Not counting uptime/security (unlikely to be affected), the real issue is extra load on the servers. As you pointed out, DVC+IXC are virtually worthless. I'm not even sure if they're 0.1% actually. Adding extra coins to each pool server means each server will be wasting time accessing the SSDs/RAM for those coins, a few CPU cycles, and some bandwidth every time they get a block. That will at least minimally impact bitcoind performance. How much? I can't say, and nobody else really can either. But it is a non-0 impact, and for how worthless they are, I'm not willing to risk ANY performance for junk coins on BTC Guild. I'm asking this because I don't know / understand not to be a pain: Could they were on a physically separate server? With some of the databases I deal with 90%+ of the work is done on the main box 10% is done on other ones. The 10% does not "matter" it's what we term "live irrelevant data". It's for the programmers to use live data / connections to test work, if it all goes boom or lags behind no big deal the main database servers don't even know about it. The front end application servers here (I'm assuming the stratum servers for you) know about it and talk to it at the lowest priority, but if the test back end fails no big deal. I don't know enough about the stratum protocol to know if that's even possible. And no, I don't think it's worth the time to mine the other coins, but I do want to understand more. -Dave
|
|
|
|
guytechie
|
|
July 01, 2014, 05:39:04 PM |
|
Can we please go back to average luck? 80-90% luck seems like the new normal. I really don't want to switch over to the dark side (GHash.IO). If this keeps up, it's no wonder why our pool hash is dropping. Probably for ghash... It's going to take a buttload of good luck to dig us out of this 80-90% new norm.
|
Put something in my tip jar if I made your day. BTC: 1MkmBHDjonAFXui6JEx9ZmEemfMtUo9Cmu
|
|
|
sconklin321
Sr. Member
Offline
Activity: 543
Merit: 250
Orjinal üyelik ToRiKaN banlanalı asır ol
|
|
July 02, 2014, 12:49:43 AM |
|
Dev and IXC only add about 0.1% more to your profits and it's another coin you have to send to an exchange and then dump for Bitcoin (assuming you only want BTC). I think the uptime and security affording by this pool and others like Bitminter and Elegius exceed the paltry add on of those coins.
Not counting uptime/security (unlikely to be affected), the real issue is extra load on the servers. As you pointed out, DVC+IXC are virtually worthless. I'm not even sure if they're 0.1% actually. Adding extra coins to each pool server means each server will be wasting time accessing the SSDs/RAM for those coins, a few CPU cycles, and some bandwidth every time they get a block. That will at least minimally impact bitcoind performance. How much? I can't say, and nobody else really can either. But it is a non-0 impact, and for how worthless they are, I'm not willing to risk ANY performance for junk coins on BTC Guild. I'm asking this because I don't know / understand not to be a pain: Could they were on a physically separate server? With some of the databases I deal with 90%+ of the work is done on the main box 10% is done on other ones. The 10% does not "matter" it's what we term "live irrelevant data". It's for the programmers to use live data / connections to test work, if it all goes boom or lags behind no big deal the main database servers don't even know about it. The front end application servers here (I'm assuming the stratum servers for you) know about it and talk to it at the lowest priority, but if the test back end fails no big deal. I don't know enough about the stratum protocol to know if that's even possible. And no, I don't think it's worth the time to mine the other coins, but I do want to understand more. -Dave I'm not 100% sure here, but I think a lot of this comes down to just mitigating the sheer latency. To start with, it is my understanding that the second a new block is found, all the work that is currently being worked on for the old expires. So you lose clock cycles/bandwidth there, trying to send out new work to all the workers currently connected so that they are all working on the current block. Definitely don't want to be wasting clock cycles checking/updating work to worthless coins then. Also, when you find a block, you need to get this from the accepted share that found it, to the blockchain and broadcast it as fast as the server/network will allow this. Sometimes, a matter of a few fractions of a second could be the difference between a block being accepted or orphaned. Better to keep the resources available for the coins that are worth it than waste it on coins that are more or less worthless.
|
|
|
|
incin
|
|
July 02, 2014, 01:09:46 AM |
|
Like today when BTCGuild lost block 308770 to slush.
|
|
|
|
Majixagi
Member
Offline
Activity: 98
Merit: 10
|
|
July 02, 2014, 01:11:46 AM |
|
Dev and IXC only add about 0.1% more to your profits and it's another coin you have to send to an exchange and then dump for Bitcoin (assuming you only want BTC). I think the uptime and security affording by this pool and others like Bitminter and Elegius exceed the paltry add on of those coins.
Not counting uptime/security (unlikely to be affected), the real issue is extra load on the servers. As you pointed out, DVC+IXC are virtually worthless. I'm not even sure if they're 0.1% actually. Adding extra coins to each pool server means each server will be wasting time accessing the SSDs/RAM for those coins, a few CPU cycles, and some bandwidth every time they get a block. That will at least minimally impact bitcoind performance. How much? I can't say, and nobody else really can either. But it is a non-0 impact, and for how worthless they are, I'm not willing to risk ANY performance for junk coins on BTC Guild. I'm asking this because I don't know / understand not to be a pain: Could they were on a physically separate server? With some of the databases I deal with 90%+ of the work is done on the main box 10% is done on other ones. The 10% does not "matter" it's what we term "live irrelevant data". It's for the programmers to use live data / connections to test work, if it all goes boom or lags behind no big deal the main database servers don't even know about it. The front end application servers here (I'm assuming the stratum servers for you) know about it and talk to it at the lowest priority, but if the test back end fails no big deal. I don't know enough about the stratum protocol to know if that's even possible. And no, I don't think it's worth the time to mine the other coins, but I do want to understand more. -Dave I'm not 100% sure here, but I think a lot of this comes down to just mitigating the sheer latency. To start with, it is my understanding that the second a new block is found, all the work that is currently being worked on for the old expires. So you lose clock cycles/bandwidth there, trying to send out new work to all the workers currently connected so that they are all working on the current block. Definitely don't want to be wasting clock cycles checking/updating work to worthless coins then. Also, when you find a block, you need to get this from the accepted share that found it, to the blockchain and broadcast it as fast as the server/network will allow this. Sometimes, a matter of a few fractions of a second could be the difference between a block being accepted or orphaned. Better to keep the resources available for the coins that are worth it than waste it on coins that are more or less worthless. Look, all I'm saying is that ghash.io figured it out and does fairly well with over 4 times the hash rate of BTCGuild. mmpool.org figured it out with even more coins. BTCGuild should be able to figure it out. I'd just like to see more feature parity with the biggest pool because I don't think the current system is going to get better on its own. If I were making some amount of my income based on how much market share my pool had, I would be looking for any way possible to keep that income reasonably high without exceeding a certain threshold that would endanger the network. Pick ajax stats, split payouts, merged mining, something anything to close the gap. Just my 2 bits. Yes, I am currently mining here because it is the most stable pool there is. I'm also mining here because I want this pool to survive. As the mining corporations gather more network share, more private miners will tend to consolidate to fewer higher hash rate pools to reduce their variance. p2pool and Eligius can survive because they don't rely on a fee to run. I'm just worried about BTCGuild eventually becoming an abandoned pool like a few others have. Maybe I'm thinking too far ahead or being alarmist, but I thought I would try to share my concerns while there is still a chance to do something about it. It really has much less to do with the income those coins would provide than it does with the perception of value the pool provides.
|
has not sold out
|
|
|
psahx
|
|
July 02, 2014, 03:11:21 AM |
|
|
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
July 02, 2014, 03:40:49 AM |
|
With only about 12 blocks/day expected, it doesn't take much to swing those numbers anymore. Yesterday's 13 hour block pretty much guaranteed the weekly average is going to stay low until that round rolls out of the average, yet it wasn't a record in terms of shares vs diff. It wasn't even 7x. Yet that single day had a multiple-percent impact on the 1-month average because of how small the sample size is becoming. During our last run of luck (Jun 18 - Jun 21) the 24H - 2W numbers were all over 100% again. You're going to see more extremes now, that's what happens when you're a smaller share of the overall network. The bad days will be extremely low, the good days will be much higher. Each block is ~13% of expectation, so getting 4 blocks more than expected is now huge (160%), whereas in the past it was only a minor bump (115-125%). In the same vein, 4 blocks less than expectation is now a 40% instead of 80%.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
sconklin321
Sr. Member
Offline
Activity: 543
Merit: 250
Orjinal üyelik ToRiKaN banlanalı asır ol
|
|
July 02, 2014, 05:14:38 AM |
|
Dev and IXC only add about 0.1% more to your profits and it's another coin you have to send to an exchange and then dump for Bitcoin (assuming you only want BTC). I think the uptime and security affording by this pool and others like Bitminter and Elegius exceed the paltry add on of those coins.
Not counting uptime/security (unlikely to be affected), the real issue is extra load on the servers. As you pointed out, DVC+IXC are virtually worthless. I'm not even sure if they're 0.1% actually. Adding extra coins to each pool server means each server will be wasting time accessing the SSDs/RAM for those coins, a few CPU cycles, and some bandwidth every time they get a block. That will at least minimally impact bitcoind performance. How much? I can't say, and nobody else really can either. But it is a non-0 impact, and for how worthless they are, I'm not willing to risk ANY performance for junk coins on BTC Guild. I'm asking this because I don't know / understand not to be a pain: Could they were on a physically separate server? With some of the databases I deal with 90%+ of the work is done on the main box 10% is done on other ones. The 10% does not "matter" it's what we term "live irrelevant data". It's for the programmers to use live data / connections to test work, if it all goes boom or lags behind no big deal the main database servers don't even know about it. The front end application servers here (I'm assuming the stratum servers for you) know about it and talk to it at the lowest priority, but if the test back end fails no big deal. I don't know enough about the stratum protocol to know if that's even possible. And no, I don't think it's worth the time to mine the other coins, but I do want to understand more. -Dave I'm not 100% sure here, but I think a lot of this comes down to just mitigating the sheer latency. To start with, it is my understanding that the second a new block is found, all the work that is currently being worked on for the old expires. So you lose clock cycles/bandwidth there, trying to send out new work to all the workers currently connected so that they are all working on the current block. Definitely don't want to be wasting clock cycles checking/updating work to worthless coins then. Also, when you find a block, you need to get this from the accepted share that found it, to the blockchain and broadcast it as fast as the server/network will allow this. Sometimes, a matter of a few fractions of a second could be the difference between a block being accepted or orphaned. Better to keep the resources available for the coins that are worth it than waste it on coins that are more or less worthless. Look, all I'm saying is that ghash.io figured it out and does fairly well with over 4 times the hash rate of BTCGuild. mmpool.org figured it out with even more coins. BTCGuild should be able to figure it out. I'd just like to see more feature parity with the biggest pool because I don't think the current system is going to get better on its own. If I were making some amount of my income based on how much market share my pool had, I would be looking for any way possible to keep that income reasonably high without exceeding a certain threshold that would endanger the network. Pick ajax stats, split payouts, merged mining, something anything to close the gap. Just my 2 bits. Yes, I am currently mining here because it is the most stable pool there is. I'm also mining here because I want this pool to survive. As the mining corporations gather more network share, more private miners will tend to consolidate to fewer higher hash rate pools to reduce their variance. p2pool and Eligius can survive because they don't rely on a fee to run. I'm just worried about BTCGuild eventually becoming an abandoned pool like a few others have. Maybe I'm thinking too far ahead or being alarmist, but I thought I would try to share my concerns while there is still a chance to do something about it. It really has much less to do with the income those coins would provide than it does with the perception of value the pool provides. I hear what you're saying, unfortunately we don't find the hashrate they do either. When you have over 1/3 of the hashrate you can minimize your latency risk because you have a 1 in 3 chance of finding the next block and preventing it from being orphaned. While we're at just shy of 10% of the network hashrate. So, we have a 1 in 10 chance of finding the next block, so we need every advantage we can get. Risking latency for some worthless coins isn't worth the risk of a block being orphaned because we're not likely to find the next block. I do get what you're saying though.
|
|
|
|
psahx
|
|
July 02, 2014, 05:44:03 AM |
|
You're going to see more extremes now, that's what happens when you're a smaller share of the overall network. The bad days will be extremely low, the good days will be much higher. Each block is ~13% of expectation, so getting 4 blocks more than expected is now huge (160%), whereas in the past it was only a minor bump (115-125%). In the same vein, 4 blocks less than expectation is now a 40% instead of 80%.
Thanks Then, let's hope for good days to came sooner. Cheers!
|
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
July 02, 2014, 05:48:45 AM |
|
Look, all I'm saying is that ghash.io figured it out and does fairly well with over 4 times the hash rate of BTCGuild. mmpool.org figured it out with even more coins.
They didn't "figure it out". There is the very real chance that one or more of their Bitcoin orphans were the result of worthless crapcoin daemons adding extra latency to their pool knowing of a new block or pushing out a new block. Like today when BTCGuild lost block 308770 to slush. That was just adding insult to injury after last night's block . But our luck with orphans has been fairly good, that was our first orphan in the last 300 blocks.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
-ck
Legendary
Offline
Activity: 4228
Merit: 1644
Ruu \o/
|
|
July 02, 2014, 07:25:08 AM |
|
This: Look, all I'm saying is that ghash.io figured it out and does fairly well with over 4 times the hash rate of BTCGuild. mmpool.org figured it out with even more coins.
and this: Yes, I am currently mining here because it is the most stable pool there is. are contradicting themselves, no?
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
Majixagi
Member
Offline
Activity: 98
Merit: 10
|
|
July 02, 2014, 10:41:04 AM |
|
This: Look, all I'm saying is that ghash.io figured it out and does fairly well with over 4 times the hash rate of BTCGuild. mmpool.org figured it out with even more coins.
and this: Yes, I am currently mining here because it is the most stable pool there is. are contradicting themselves, no? There is no contradiction whatsoever in those statements. If anything it is a validation of what eleuthria said about stability here. I have always attributed the stability of BTCGuild to eleuthria's skills as an operator and suspect that if he were running ghash.io it would be more stable. I still think that is the case, but I also believe him when he says that keeping merged mining simple is a significant reason for that stability here. The marketing message to newer or less informed miners is that ghash.io has more value because of its lower variance and merged mining. It doesn't matter if that reason should not be significant, it only matters that the marketing works. People believe it and mine there. Just sad to see the industrialization of mining. I am nostalgic for the time when it took effort and thought instead of just capital to get involved.
|
has not sold out
|
|
|
Minor Miner
Legendary
Offline
Activity: 2408
Merit: 1019
Be A Digital Miner
|
|
July 02, 2014, 12:21:18 PM |
|
Can anyone tell me if I am completely missing something here? If I go to bitcoinwisdom.com and look at difficulty, it predicts the next adjustment as being +13% even though the average block time is 10 minutes. I realize their predictions are not accurate for the first days of a change, but is the average is 10 minutes shouldn't they be predicting 0%?
|
|
|
|
os2sam
Legendary
Offline
Activity: 3582
Merit: 1094
Think for yourself
|
|
July 02, 2014, 12:30:01 PM |
|
Can anyone tell me if I am completely missing something here? If I go to bitcoinwisdom.com and look at difficulty, it predicts the next adjustment as being +13% even though the average block time is 10 minutes. I realize their predictions are not accurate for the first days of a change, but is the average is 10 minutes shouldn't they be predicting 0%?
We're only a quarter of the way into this difficulty. So there is allot of room to go either way. But yes, if 6 blocks per hour is maintained all the way through then difficulty would stay the same, pretty much. But I doubt that will happen and they probably doubt it too.
|
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
|
|