cavaliersrus
|
|
May 07, 2016, 04:41:18 PM |
|
think thats funny you should see the video of him doing volley ball its hilarious
|
|
|
|
Newko
|
|
May 07, 2016, 06:03:30 PM |
|
please understand newtons third law. That law presides over the entire universe and all energy contained within. This pool cannot defy newtons laws. For every action there is equal and opposite reaction. Stop denying this fact and you will see why there is the highs and lows.. Or perhaps be able to accept them better.
I'm hoping you're joking and I just haven't had enough coffee yet to see it. If you are not, then please allow me to correct your statements. While Newton's Third Law does indeed state that for every action there is an equal and opposite reaction, that has absolutely nothing to do with BTC mining. Just because you've had a good luck streak does not mean there is a corresponding bad luck streak, and vice-versa. But but but ... Newton's Third Law? Doesn't that just trump everything? Self-explainatory - when bad luck comes .... it comes no matter what. https://www.youtube.com/watch?v=VFhCFOmmglcThat's hysterical! (and demonstrates your point perfectly).
|
|
|
|
Newko
|
|
May 07, 2016, 06:08:52 PM |
|
think thats funny you should see the video of him doing volley ball its hilarious Send us the link - I want to laugh even more!
|
|
|
|
citronick
Legendary
Offline
Activity: 1834
Merit: 1080
---- winter*juvia -----
|
|
May 07, 2016, 06:22:03 PM |
|
think thats funny you should see the video of him doing volley ball its hilarious Send us the link - I want to laugh even more! https://www.youtube.com/watch?v=zuQPmleaFrc
|
If I provided you good and useful info or just a smile to your day, consider sending me merit points to further validate this Bitcointalk account ~ useful for future account recovery...
|
|
|
klamp
Newbie
Offline
Activity: 33
Merit: 0
|
|
May 07, 2016, 06:35:06 PM |
|
"mining is as mining does", I'm going over to AntPoo
|
|
|
|
Sierra8561
|
|
May 07, 2016, 06:38:42 PM |
|
"mining is as mining does", I'm going over to AntPoo
Best of luck to you
|
|
|
|
citronick
Legendary
Offline
Activity: 1834
Merit: 1080
---- winter*juvia -----
|
|
May 07, 2016, 06:44:43 PM |
|
"mining is as mining does", I'm going over to AntPoo
“PATIENCE YOU MUST HAVE my young padawan”
|
If I provided you good and useful info or just a smile to your day, consider sending me merit points to further validate this Bitcointalk account ~ useful for future account recovery...
|
|
|
Sierra8561
|
|
May 07, 2016, 06:56:20 PM |
|
"mining is as mining does", I'm going over to AntPoo
“PATIENCE YOU MUST HAVE my young padawan” Although I wouldn't ever support a pool of that size and power. If someone is content with average performance then it's a good place "although I would recommend a smaller pool to help level the playing field". Personally I prefer above average performance and this pool does just that. You can't judge Kano.is by a few weeks performance especially when it's long term track record proves the exact opposite. I'll take a little less money over the last few weeks for substantially more in the long term.
|
|
|
|
hoosier_13
Member
Offline
Activity: 62
Merit: 10
|
|
May 07, 2016, 07:00:44 PM |
|
Kano, it seems at some point this performance becomes questionable. I have quite a bit of hash power on the pool. I got burned on block withholding before - have you ruled that out for sure. Love the pool but going to need some assurance it is not block withholding soon. Thanks for any information you can provide.
|
Bitrated user: TICH13.
|
|
|
Gren
Member
Offline
Activity: 97
Merit: 10
|
|
May 07, 2016, 07:34:07 PM |
|
eh, i'm movin most of my miners back over to antpoo as well,it's not as much as here on good days, but its pretty steady i need to set aside some $$ for power supplies, i had one loose its magic smoke, i'm pushing a pair of evga 1300w g2's to max in its absence good luck to you all You guys need to tie Scott Sterling on top of the server so we can get some more blocks
|
|
|
|
Sierra8561
|
|
May 07, 2016, 08:02:36 PM |
|
Say over the next couple weeks we get back to average on all counts. That's going to be a bunch of blocks.
|
|
|
|
Newko
|
|
May 07, 2016, 08:41:30 PM |
|
That was great - thanks Ok, back to business....how about a block guys? [Edit] and gals
|
|
|
|
clgrissom3
Legendary
Offline
Activity: 1722
Merit: 1032
Carl, aka Sonny :)
|
|
May 07, 2016, 10:24:35 PM Last edit: May 07, 2016, 10:41:12 PM by clgrissom3 |
|
Block by kcmines with 20.60THs! Welcome to the Acclaim Board with your first kano block! EDIT: Dang, this block opened up the floodgates by confirming 4 payout blocks!
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4508
Merit: 1815
Linux since 1997 RedHat 4
|
|
May 07, 2016, 10:24:54 PM |
|
Kano, it seems at some point this performance becomes questionable. I have quite a bit of hash power on the pool. I got burned on block withholding before - have you ruled that out for sure. Love the pool but going to need some assurance it is not block withholding soon. Thanks for any information you can provide.
I run a luck check before every payout. The main issue with that of course is that it's not possible to detect problems smaller than a certain amount. However, the top 10 hash rates on the pool are obviously OK. ... block ... Will type more later
|
|
|
|
hoosier_13
Member
Offline
Activity: 62
Merit: 10
|
|
May 07, 2016, 10:27:08 PM |
|
Thanks appreciate it
|
Bitrated user: TICH13.
|
|
|
dance191
|
|
May 07, 2016, 10:46:51 PM |
|
Just throwing out an idea out there...
Is it possible that some bug has been introduced into the system in the last 2 weeks or so? Is there anything that changed about 2 weeks ago?
Overall, this pool is amazing, but this recent string of luck does look a little unusual? The CDF for the last 25 blocks is .9984, so there is about a 0.16% chance of that happening. The time interval is 10.3 days, so this 10.3 day string of luck should happen once every 6,437.5 days (unless I am reading it wrong) and that does appear high. In addition, the luck very suddenly changed about 2 weeks ago and has been pretty stable for that last 2 weeks. This makes me think something changed 2 weeks ago.
Working on and keeping a complicated system working at 100% is very, very difficult. Not only does the code change but daemons crash, memory leaks (and changes without ECC), packets get lost, etc. There are 1,000's of things to go wrong and only 1 way to get it right.
Kano, are blocks being found on all servers people connect to (in the correct ratios), nothing changing in the mining code 2 weeks ago, etc? I know with small sample sizes the numbers may not be statistically significant, but you know what looks right and what looks suspicious.
When things appear to change, it at least is worth entertaining the possibility that something changed. I am not suspicious of any foul play, but you gotta make sure things are running at 100%. I am sure Kano is looking into the system and making sure it is at 100%, just bringing it up for discussion.
|
|
|
|
thedreamer
Legendary
Offline
Activity: 1694
Merit: 1002
Go Big or Go Home.....
|
|
May 07, 2016, 10:48:19 PM |
|
I agree , quoting Newton's Third Law here is just pretty... Umm.... ... Let's just say 'wrong' and unrelated, to stay civil. On that note, I had to pull my stuff off here as I was already a lot in the hole. Sorry guyz.. I stuck it out with the bad luck and long blocks in the past, but almost a week's worth hurt enough to buy a used car, so I had to go (Not a BMW, but still). If things get back to normal I'll hook back up here. Good luck you guys (and gals). So on the one hand you discount the idea that past luck determines future luck and on the other hand you move your miners due to bad luck? Do you by any chance detect any cognitive dissonance happening in your mind? You seriously just asked that? Please read my other posts and support for this pool and then make a proper comment will ya? Unless your losses are in the thousands, no input from the peanut gallery, thank you.
|
Go Big or Go Home.
|
|
|
kano (OP)
Legendary
Offline
Activity: 4508
Merit: 1815
Linux since 1997 RedHat 4
|
|
May 07, 2016, 11:02:20 PM |
|
Kano, it seems at some point this performance becomes questionable. I have quite a bit of hash power on the pool. I got burned on block withholding before - have you ruled that out for sure. Love the pool but going to need some assurance it is not block withholding soon. Thanks for any information you can provide.
I run a luck check before every payout. The main issue with that of course is that it's not possible to detect problems smaller than a certain amount. However, the top 10 hash rates on the pool are obviously OK. ... block ... Will type more later For the top miners, most of them have their own hardware, so would be silly for them to withhold. Looking at the luck report for the top miners, most of them have Block to BDR ratios above 1. Any that are below 1 are well within statistical expectation. BDR - Block Diff Ratio (a name I call it) is the DiffAccepted for the miner as a % of a block, given each share as a % of a block at the time it was submitted, then add them all up. Shares are summarised into shifts, and shifts don't cross a difficulty boundary, so it's not an impossibly large calculation to do. The Block to BDR ratio is 1 for 100% luck, greater than 1 for > 100% luck and less than 1 for < 100% luck e.g. 12TM has found 23 Blocks with a BDR of 19.21 - so yep that's REALLY good for the pool ... 23/19.21 = 1.20 GLORYTrading has found 21 Blocks with a BDR of 11.15 ... to be blunt, fucking awesome ... 21/11.15 = 1.88 (The BDR stats currently only go back to Feb last year) However, there is of course the issue of IP subnets and rentals. I've detected problems on IP subnets before and they are always in my list I check for each time and block. I'm making some more changes, over the next few weeks, to deal with detecting problems more easily if people are trying to hide them. That will, of course, include checking these over past history, which will take some effort to calculate. There are other checks I do, like how many high diff shares people submit vs their DiffAcc, their value ranges, and I also keep a close eye on any accounts that have any numbers that, although they may be within statistical expectation, are on the high side of bad luck. So far as I can see, this is indeed some unfortunate bad luck, but I'm still working on ways to analyse it better.
|
|
|
|
thedreamer
Legendary
Offline
Activity: 1694
Merit: 1002
Go Big or Go Home.....
|
|
May 07, 2016, 11:09:24 PM |
|
Kano, it seems at some point this performance becomes questionable. I have quite a bit of hash power on the pool. I got burned on block withholding before - have you ruled that out for sure. Love the pool but going to need some assurance it is not block withholding soon. Thanks for any information you can provide.
I run a luck check before every payout. The main issue with that of course is that it's not possible to detect problems smaller than a certain amount. However, the top 10 hash rates on the pool are obviously OK. ... block ... Will type more later For the top miners, most of them have their own hardware, so would be silly for them to withhold. Looking at the luck report for the top miners, most of them have Block to BDR ratios above 1. Any that are below 1 are well within statistical expectation. BDR - Block Diff Ratio (a name I call it) is the DiffAccepted for the miner as a % of a block, given each share as a % of a block at the time it was submitted, then add them all up. Shares are summarised into shifts, and shifts don't cross a difficulty boundary, so it's not an impossibly large calculation to do. The Block to BDR ratio is 1 for 100% luck, greater than 1 for > 100% luck and less than 1 for < 100% luck e.g. 12TM has found 23 Blocks with a BDR of 19.21 - so yep that's REALLY good for the pool ... 23/19.21 = 1.20 GLORYTrading has found 21 Blocks with a BDR of 11.15 ... to be blunt, fucking awesome ... 21/11.15 = 1.88 (The BDR stats currently only go back to Feb last year) However, there is of course the issue of IP subnets and rentals. I've detected problems on IP subnets before and they are always in my list I check for each time and block. I'm making some more changes, over the next few weeks, to deal with detecting problems more easily if people are trying to hide them. That will, of course, include checking these over past history, which will take some effort to calculate. There are other checks I do, like how many high diff shares people submit vs their DiffAcc, their value ranges, and I also keep a close eye on any accounts that have any numbers that, although they may be within statistical expectation, are on the high side of bad luck. So far as I can see, this is indeed some unfortunate bad luck, but I'm still working on ways to analyse it better. Good to hear. Once things go back to the normal block days, I'm switching back to here, just had to leave to pucker up my cheeks a bit after the past week's losses and the BW / Orphan drama with FUPool. I wouldn't put it past a large chinese person/org to hoze a successful 'competitor' in spite.. WOuldn't be the first time I saw this..
|
Go Big or Go Home.
|
|
|
kano (OP)
Legendary
Offline
Activity: 4508
Merit: 1815
Linux since 1997 RedHat 4
|
|
May 07, 2016, 11:20:18 PM |
|
Just throwing out an idea out there...
Is it possible that some bug has been introduced into the system in the last 2 weeks or so? Is there anything that changed about 2 weeks ago?
...
CKDB also checks every share that CKPool gets and also reports on the console shares within 5% of being a block, no matter what error state they have. 2 independent programs and pieces of code doing the checks. So if, completely unexpectedly, CKPool didn't recognise a share that was block worthy, it would still show up in CKDB on the console. I also have a command to check the console logs for them that I run every so often to see if we are finding 'near misses'. The last near miss was: [2016-05-04 13:18:20.627+10] Share ok Diff 95.1% (169849029387/178659257772.5) --- Pool 251079832299.0 251G 140.54%
There are of course other scenarios if say a share got lost and never made it to CKDB, but even then CKDB tracks that also. Each message generated to be sent to CKDB from CKPool has 2 sequence numbers, one for all messages and one for each message type. These are checked in CKDB also and reported if any are ever missing. They actually go through 3 stages that are all reported, if a number is out of sequence for more than a few seconds. Transient, Missing, Lost. That's the code that caused me some trouble with the threading changes that I finally fixed. Yeah it's a little complicated Of course all code has bugs, and indeed there are some rather unexpected ways shares could be lost, but of course that exists in any system, and I go to a lot of effort in CKDB to detect anything missing.
|
|
|
|
|