Shazam!!!
Full Member
Offline
Activity: 350
Merit: 158
#takeminingback
|
|
April 12, 2018, 07:35:10 PM |
|
BTCamm!!!
|
Click these links to learn some truth about Big Corporate mining pools stealing your money and centralizing BTCitcoin!!! Help support the BTCitcoin community!!! Mine your BTCitcoin at a non-Corporate pool!!! BTC: 1ShazamjsPnpWDNnk3n2tAiKGMdXaSjay
|
|
|
BSGMiner
Member
Offline
Activity: 490
Merit: 16
1xA921 + 1xA741 + Backup-->1xA6 ;)
|
|
April 12, 2018, 07:51:06 PM |
|
BTCBTCBTCLLL000CCCKKK!!!Thanks, MicroBalrog!
|
The BTCest mining pool (<1% fee): KanoPool***PPLNS rewards averaged over the 5Nd to reduce variance***
|
|
|
firetreeactual
Legendary
Offline
Activity: 952
Merit: 1003
|
|
April 12, 2018, 08:01:38 PM |
|
BTCBTCBTCLLL000CCCKKK!!!Thanks, MicroBalrog! Ditto...I can get used to this...
|
To infinity and beyond...on two 741s and one of only 3...nope, make that 4...full nodes in Hawaii...on <30A. (I have other gear on the Hoth ice planet)
|
|
|
minergain.com
Member
Offline
Activity: 285
Merit: 10
Free mining equipment tracking and reporting
|
|
April 12, 2018, 08:09:01 PM |
|
If you have a bunch of inputs from pool mining (doesn't have to be here), might as well merge them all together into one larger input with these fee rates, which are practically 0.
To give you an idea, a couple months ago when activity was high, $100 for a dozen transactions sent within a few hours was commonplace. If you had a single transaction, it would be 1/12th of that. Right now you can send a dozen transactions for under a dollar most of the time.
|
|
|
|
VRobb
|
|
April 12, 2018, 08:13:00 PM |
|
One (small) Block to rule them all! Cheers MicroBalrog! Block Party Thursday is ON!
|
I don't believe in superstition because it's bad luck: 13thF1oor6CAwyzyxXPNnRvu3nhhYeqZdc These aren't the Droids you're looking for: S5 & S7 (Sold), R4B2, R4B4 (RIP), 2x S9 obsolete, 2xS15-28, S17-56, S17-70 Pushing a whopping 1/5 PH! Oh The SPEED!!!
|
|
|
nazzer
Member
Offline
Activity: 238
Merit: 11
|
|
April 12, 2018, 08:15:32 PM |
|
Hey, whaddya know we're back to 100% for the month. Now we just need to be 100% for the last 5 blocks
|
Vega 56 | Vega 64 | RX580 | GTX1070 | 1050Ti | S9 | L3+
|
|
|
kano (OP)
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
April 12, 2018, 08:20:29 PM |
|
Anyone interested in a run down of the KDB problem the other day ... Note this is a TL;DR; for most The cause was related to the pool size, not a bug in my KDB code 'as such' The sequence number code allows tracking 2^20 (~1mill) sequence numbers for shares. This tracking is needed for out of order data, but the code of course doesn't keep that data forever, it reuses the data when it needs more space. This reuse means that it can only track ~1 million different share sequence numbers at any one time. This is way more than needed for normal running, but during a reload there's a sizeable time difference between the start of the reload and the data coming in from the pool code. The catch comes when the reload has completed, then it starts processing the queue of data from the pool that arrived while it was reloading. This can't be more than ~1 million shares apart, which again is normally OK but can be a problem for a slow (long) reload done on the live server. The extremely large log shows this is the cause of problem, but there was so much data in the log file that it wasn't obvious at first why it happened. The fix is 2 fold: 1) if I ever need to roll back the database to correct or generate missing shift data, don't do it, use the backup server to generate it and copy it across like I did, except the first time during the problem. 2) I'll increase the share sequence tracking size by another 8x before I restart KDB again Mine on!
|
|
|
|
nazzer
Member
Offline
Activity: 238
Merit: 11
|
|
April 12, 2018, 08:30:39 PM |
|
Anyone interested in a run down of the KDB problem the other day ... Note this is a TL;DR; for most This can't be more than ~1 million shares apart, which again is normally OK but can be a problem for a slow (long) reload done on the live server. The extremely large log shows this is the cause of problem, but there was so much data in the log file that it wasn't obvious at first why it happened. The fix is 2 fold: 1) if I ever need to roll back the database to correct or generate missing shift data, don't do it, use the backup server to generate it and copy it across like I did, except the first time during the problem. 2) I'll increase the share tracking size by another 8x before I restart KDB again Mine on! TL;DR - 1,000,000 shares ought to be enough for anyone Good to know the root cause, thanks Kano
|
Vega 56 | Vega 64 | RX580 | GTX1070 | 1050Ti | S9 | L3+
|
|
|
rockmoney
|
|
April 12, 2018, 08:48:23 PM |
|
Kano Pool is on the move! Currently 147,489.77 TH/s and has been increasing. I don't know why anyone would mine elsewhere with this pools unheard of PPLNS 0.9% fee! Everyone point there miners at ' stratum+tcp://stratum.kano.is:3333 ', and let's GET PAID!
|
|
|
|
rifleman74
Member
Offline
Activity: 658
Merit: 21
4 s9's 2 821's
|
|
April 12, 2018, 08:57:12 PM |
|
Anyone interested in a run down of the KDB problem the other day ... Note this is a TL;DR; for most The cause was related to the pool size, not a bug in my KDB code 'as such' The sequence number code allows tracking 2^20 (~1mill) sequence numbers for shares. This tracking is needed for out of order data, but the code of course doesn't keep that data forever, it reuses the data when it needs more space. This reuse means that it can only track ~1 million different share sequence numbers at any one time. This is way more than needed for normal running, but during a reload there's a sizeable time difference between the start of the reload and the data coming in from the pool code. The catch comes when the reload has completed, then it starts processing the queue of data from the pool that arrived while it was reloading. This can't be more than ~1 million shares apart, which again is normally OK but can be a problem for a slow (long) reload done on the live server. The extremely large log shows this is the cause of problem, but there was so much data in the log file that it wasn't obvious at first why it happened. The fix is 2 fold: 1) if I ever need to roll back the database to correct or generate missing shift data, don't do it, use the backup server to generate it and copy it across like I did, except the first time during the problem. 2) I'll increase the share sequence tracking size by another 8x before I restart KDB again Mine on! Yep, that tracking size increase should solve that problem. Thanks for the update KANO! MINE THE F ON WITH KANO-SAN!!!
|
|
|
|
sruyle
Newbie
Offline
Activity: 65
Merit: 0
|
|
April 12, 2018, 09:00:55 PM Last edit: April 12, 2018, 09:26:24 PM by sruyle |
|
Hempfrog:
You have been randomly chosen for 5 days of my S7. Starting now.
Congratulations.
Yes, I decided to add to the pass the hash bonus and chose a random number 1-100 from the bottom of the stats page for the giveaway. You won.
|
|
|
|
jhoren
Newbie
Offline
Activity: 65
Merit: 0
|
|
April 12, 2018, 09:08:08 PM |
|
Doing the math here, I think I'll even be ok during summer pricing, which goes just over 12 cents/kWh.
Although, I have been wondering about the peak pricing option. Not worrying about it now, because I don't have enough machines yet, but if I had considerably more would it be beneficial to switch to the peak pricing and then shut down for five hours M - F. That's 25 hours of downtime out of 168 hours, skips 30+ cents/kWh and runs during off-peak for lower 7 cents/kWh.
If I ran straight through, the average would be about 12.05 cents/kWh. Less than the normal pricing by about .5 cents.
Sounds like more math. Let me take a swing at it using a 13.5TH 1452 (at the wall) Watts as a basis. Of course, everything would scale linearly with that. Lets calc on a week. 168 hours at $0.1205 = $20.24 for power and yields 13.5TH * 168 hours = 8.1648 EHashes = $2.4789/EHash 143 hours at $0.07 = $10.01 for power and yields 13.5Th * 143 hours = 6.9498 Hashes = $1.44/EHash That is the cost side. You need to figure your profit side, subtract the cost, and see which is better. Thank you ccgllc. I think my main question might be how ramp down/up with five hours of off time might affect it. I don't think it would be noticeable but I wonder how I might be able to calculate that.
|
|
|
|
wavelengthsf
|
|
April 12, 2018, 10:18:03 PM |
|
Thank you ccgllc. I think my main question might be how ramp down/up with five hours of off time might affect it. I don't think it would be noticeable but I wonder how I might be able to calculate that.
If you turned your miners off for 5 hours every day, they'd be mining 19 hours. That's roughly 20% less hash rate. You can take your hash rate and subtract 20% from that and run your calculations. The ramp up and ramp down won't really matter.
|
|
|
|
rifleman74
Member
Offline
Activity: 658
Merit: 21
4 s9's 2 821's
|
|
April 12, 2018, 10:23:28 PM |
|
If you have a bunch of inputs from pool mining (doesn't have to be here), might as well merge them all together into one larger input with these fee rates, which are practically 0.
To give you an idea, a couple months ago when activity was high, $100 for a dozen transactions sent within a few hours was commonplace. If you had a single transaction, it would be 1/12th of that. Right now you can send a dozen transactions for under a dollar most of the time. It's much less than a dollar, this was at least 20 inputs from March, plus whatever we had in April. Really really cheap, date of the previous consolidation was on 2/27/18. 35 cents for combine all of that.
|
|
|
|
jhoren
Newbie
Offline
Activity: 65
Merit: 0
|
|
April 12, 2018, 10:38:19 PM |
|
Thank you ccgllc. I think my main question might be how ramp down/up with five hours of off time might affect it. I don't think it would be noticeable but I wonder how I might be able to calculate that.
If you turned your miners off for 5 hours every day, they'd be mining 19 hours. That's roughly 20% less hash rate. You can take your hash rate and subtract 20% from that and run your calculations. The ramp up and ramp down won't really matter. Thank you. I ran my calculations basing it on the total hash rate of the pool for the week and then of my % of that. With a single machine there's about a $2.25 difference per week at the current BTC-USD rate. Maybe worth it if I get more machines running. I ran it also if I ran it during the very expensive portion of the peak time and I would lose $.25 per week there. So, I could probably talk myself into giving the pool that hash and not stop it. But I'd still be saving using the peak/off-peak instead of just the straight cost.
|
|
|
|
ricknamer
Jr. Member
Offline
Activity: 126
Merit: 1
|
|
April 12, 2018, 11:18:33 PM |
|
For anyone looking to order from Bitmain. Especially us Kano guys!
I just placed an order now.
They are now accepting BCH, BTC and LTC as payment.
First I have seen this.
|
|
|
|
perfectplus174
Jr. Member
Offline
Activity: 168
Merit: 2
|
|
April 12, 2018, 11:24:56 PM |
|
For anyone looking to order from Bitmain. Especially us Kano guys!
I just placed an order now.
They are now accepting BCH, BTC and LTC as payment.
First I have seen this.
Yeah, I ordered one with BCH and one with BTC. Will be buying more when the rest of my BCH is available. Luckily I stocked up when everything was down so it's like an extra coupon
|
Nothing happens until something moves.
MINE ON WITH KANO........except DPoS2
|
|
|
kano (OP)
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
April 12, 2018, 11:25:52 PM |
|
Thank you ccgllc. I think my main question might be how ramp down/up with five hours of off time might affect it. I don't think it would be noticeable but I wonder how I might be able to calculate that.
If you turned your miners off for 5 hours every day, they'd be mining 19 hours. That's roughly 20% less hash rate. You can take your hash rate and subtract 20% from that and run your calculations. The ramp up and ramp down won't really matter. Thank you. I ran my calculations basing it on the total hash rate of the pool for the week and then of my % of that. With a single machine there's about a $2.25 difference per week at the current BTC-USD rate. Maybe worth it if I get more machines running. I ran it also if I ran it during the very expensive portion of the peak time and I would lose $.25 per week there. So, I could probably talk myself into giving the pool that hash and not stop it. But I'd still be saving using the peak/off-peak instead of just the straight cost. Also to work out what to expect to lose from mining 80% of the time, as stated above that's 20% less expected reward. How the ramp down and up works is that instead of losing 20% on the next block, and of course the luck of single block finding has very high variance, you instead lose it over 5Nd - i.e. you expect that 20% loss spread out over 5Nd after the outage - or 4% each 100% expected block If it's a daily thing, then you should see the rewards settle close to the expected 80% each block reward as the daily 4%s overlap.
|
|
|
|
dzimmerm56
Member
Offline
Activity: 118
Merit: 14
|
|
April 12, 2018, 11:37:25 PM |
|
For anyone looking to order from Bitmain. Especially us Kano guys!
I just placed an order now.
They are now accepting BCH, BTC and LTC as payment.
First I have seen this.
Interesting. With the almost over USA tax season and The great underground empire taking bitcoin for miners again, I expect the price of bitcoin to start upward. Lets watch and see, ... Mine On!
|
1 S9, 2 A741s, 1 A821, 3 A841s, and full bitcoin node About 80THash/sec
|
|
|
ricknamer
Jr. Member
Offline
Activity: 126
Merit: 1
|
|
April 12, 2018, 11:42:11 PM |
|
For anyone looking to order from Bitmain. Especially us Kano guys!
I just placed an order now.
They are now accepting BCH, BTC and LTC as payment.
First I have seen this.
Interesting. With the almost over USA tax season and The great underground empire taking bitcoin for miners again, I expect the price of bitcoin to start upward. Lets watch and see, ... Mine On! The only thing I can think of is they see a bottom. Low crypto prices = more crypto required for a purchase. If they are expecting a spike they'd do anything to get more crypto in the wallets before that happens - ride the upside.
|
|
|
|
|