Topic: KanoPool kano.is lowest 0.9% fee 🐈 since 2014 - Worldwide - 2432 blocks - page 1574. (Read 5352367 times)

It's a technical term, up there with 'buttload' and 'yonks'... 

Is zillion an exact count?

 

It's good to wake up this morning and see Juvia, my princess getting our block!!!

I failed over briefly just before the block.

Yeah, I like that couple!! 

A restart Block; the 4th block by citronik!

grats citronik and juvia

It's meant to be the other way around ...
Don't bother reading the bottom half unless you're interested

Well the fix resolved getting a zillion messages, but still some auth data is getting in early so I had to roll it back - I don't like running code that does something I don't know why and thus leaving it running may have other unexpected effects.

2nd reload is running with the previous version and should complete in the next 5 minutes.

Edit: 2nd reload complete.

You need a tl;dr for your tl;dr section as it is longer than the "main" body of text. 

A follow up from the last CKDB restart a few days ago:

I'll be restarting CKDB again in roughly 40 minutes (~23:30 UTC)
As usual, no miners will be affected.
The web page will show lotsa '?' for about 10 minutes.

Last restart I found the new code was a lot faster in all areas I changed and used a lot less RAM.
Hopefully this fix solves the minor problem from before.

If it doesn't solve the problem, I'll just go back a version again like before which means about double the restart time or about 20mins.

tl;dr;
This is an 'attempted' fix at the problem I found with the last restart and had to go back to the previous version.
The problem doesn't affect any data, just the 'sequence' processing gets out of alignment and then spews out 100's/1000's of messages.
The sequence code I wrote is somewhat complex and adding more threading into the mix allowed a few 'later' auth records to get processed early and exceed the limits on how far apart sequence numbers can be.
Processing still continues as normal, but with zillions of messages about the sequence numbers (for a few minutes)
Hopefully this fixes that.
I can't fully test if it clears the warnings, since it needs a full pool and data to cause the warning.
The code is of course tested to make sure all is OK, just can't check if it also resolves the messages except on the live pool since it needs such a high work load to cause it.

carrgo is our new youtube friend I believe. Perhaps first block is worth a video.. lol

Way to go carrgo with 12.2THs!  Welcome to the Acclaim Board with your first kano block!

Carrgo shipping in a block for us!  Schweet!

block

Just finished reading the entire thread "SPV mining and how to slow it down...if you care"
https://bitcointalksearch.org/topic/spv-mining-and-how-to-slow-it-down-if-you-care-to-1274066
Very enlightening...suggested reading for any other newbies like me.
Glad I'm here on Kano's pool, even if it's only with my tiny 4.7th

[edit] Got a good laugh when someone suggested that Kano really didn't understand mining. At the risk of sounding like a sycophant, that's kinda like saying "Michelangelo, I really don't think understand how to paint a ceiling."

Definetely no. indeec444 has only S7s at his farm. Right now his Avalon6 he won here is in my basement, running at solo.ckpool. 

Congrats! Dunno...does one consider Kaua'i Island "the west?"

Here is the strategy I've been using for my profitability test:

1) I always put my orders under 100% PPS rate.  Right now that means 5% (2% after fees) and 8% (5% after fees).  Originally I used 5-10-15 after fees, but the 10 and 15 just were not being hit enough to bother with.  My thought is that even if the orders are not always on, it is their average rate that I am paying for and that average that I will paid for at the pool.  Yes, that means occasional gaps will result in some shares falling off the N range and being paid less than 5 times due to luck, but an equal number should pile up within the N range and get paid 6+ times due to luck.  If there are no other confounding variables (more on that in a moment), the math says it should all average out to 102% to 105% in the end if I am paying 2% to 5% below market after fees.

2) Once the orders are made I never touch them except to refill.  This lets them work their way up to near the top of their price bracket during their 15 day run.  An order near the top of 0.0029 is hit nearly as often as one at the bottom of 0.0030 but costs about 3% less, so it doesn't pay to adjust orders to chase the price.

Now about confounding variables-- this assume all others renting to point hash here are following a similar rational strategy.  In reality that is not the case-- luck chasers exist who will rent well above market just to chase the luck when the pool is "hot".  Of course, I know past luck doesn't predict future results, but it does still alter the distribution of my not renting periods.  Theoretically it shouldn't matter-- they are renting for an unpredictable future-- when they win I should lose and when they lose I should win.  When that happens should be totally random in the end.  

That said, I have some experience on the flip side of this issue-- selling hash rather than renting it.  A year ago I did a similar experiment to what I'm doing now except on the selling side to determine where to set my profit switch (p=) point for selling to WH.  Like now, everything *should* have been random meaning I should have lost in profit switching as much as I gained.  The reality *was* different though, and I concluded that any profit switching below +25% consistently resulted in losses for me.  I never identified exactly what caused the phenomenon except to note that there was possibly a correlation with luck chasing at the pool.  Maybe I just didn't let the test play out long enough to see a better result.

Another confounding variable is whether or not the rented hash is legitimate hash.  Now that we have seen witholding attacks in the wild, it really raises the possibility that bad gear does hide on the rental services.  If so, increases in the percentage of rented hash on the pool (correlated with times of low rental rates when my and others rentals turn on) would result in decreases in pool luck and would directly affect my rental strategy.  Still, my intuition says this risk is low due to the combination of multiple probabilities involved (probability of dud hash existing and the probability of it getting assigned to a rental here).  If I knew the percentage of bad gear on NH/WH it would be possible to run this through Bayes' therom and get an exact percent effect on the pool (it should be less than 1% though).  

Part of my experiment is to track this carefully to make sure it isn't observable in my rental/reward data.  I only have two weeks of data when I strip out the early 5-10-15 method, so obviously I can't draw any conclusions yet.  So far a majority of my rental periods do fall within dips in reward count on my graph, but it is inconsistent as to whether they are on the leading or falling edge of the bad luck.  Of course I'm not capturing the rental activity above my threshold, so others' 0.0030+ rentals could fill that out and I wouldn't know.  I really need to be logging LRP over time, not just my own activity if I want to answer that question (but my main concern has been the viability of my strategy, not with the quality of hash available, so I haven't kept that level of detail). My rental activity was rewarded 5+ times in only 31.5% of shifts.  The average reward count on my rental shifts is now 4.228.  If the rentals are legitimate, I expect an average reward of 5 when the variance moves into my favor resulting in a profit.  If it doesn't, then there may be an issue with the quality of rentals to consider.

Anyone see any flaws?

This is a nice progression in the number of blocks the kano pool has been hitting for the past couple of months...and we should add a couple more today and tomorrow  

Month      Total   Bl/d 12/2015    39.00   1.26    01/2016    78.00   2.52    02/2016   103.00   3.55    03/2016   120.00   4.00

  nice we needed it