Author

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

hero member
Activity: 1092
Merit: 552
Retired IRCX God
...I think the only people that are making REAL money is the power companies.  They must really love us.

LOL my monthly bill is that of 5-7 neighboring households combined.  Cheesy
member
Activity: 118
Merit: 10
Is the pool being dragged down by sending shares to GPU  miners? Wouldn't it be better to send those shares to faster miners?
I randomly go and ban CPU/GPU miners - but haven't for a while.
They cause wasted bandwidth that will just about never produce a share.
Not gonna affect the luck - just wasted bandwidth.

With today's miners speed. What would be considered outdated equipment?  
I ask this because it just seems to me sending shares to equipment that is real slow pulls everything down.
We have 87 users under 1th. Of those, 7 of them are under 10.gh.   13 range from 90.gh to 10.26gh.  18 range from 430.gh to 100gh. And 49 1th to 430gh.
Well the pool doesn't send shares, it just sends 'random' work to 'miners'.
Sending out more work has no effect on anything but bandwidth.
At some point that does effect things if the pool is silly enough to support botnets of CPU/GPU mining - but I don't so it doesn't matter.
Anything under a few hundred GHs is pretty much a waste of time, but that's not related to CPU/GPU mining, so I (usually) just let them alone.

Okay. I guess I understand it a bit better now.
Hopefully we can pull in some more hash power and maybe keep up with the diff increase.
I think the only people that are making REAL money is the power companies.  They must really love us.
hero member
Activity: 1092
Merit: 552
Retired IRCX God
I'd think anything under 3008gb is a waste.

yeah, cuz f@%k me and my 2.7 LNs, right?  Undecided
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Is the pool being dragged down by sending shares to GPU  miners? Wouldn't it be better to send those shares to faster miners?
I randomly go and ban CPU/GPU miners - but haven't for a while.
They cause wasted bandwidth that will just about never produce a share.
Not gonna affect the luck - just wasted bandwidth.

With today's miners speed. What would be considered outdated equipment?  
I ask this because it just seems to me sending shares to equipment that is real slow pulls everything down.
We have 87 users under 1th. Of those, 7 of them are under 10.gh.   13 range from 90.gh to 10.26gh.  18 range from 430.gh to 100gh. And 49 1th to 430gh.
Well the pool doesn't send shares, it just sends 'random' work to 'miners'.
Sending out more work has no effect on anything but bandwidth.
At some point that does effect things if the pool is silly enough to support botnets of CPU/GPU mining - but I don't so it doesn't matter.
Anything under a few hundred GHs is pretty much a waste of time, but that's not related to CPU/GPU mining, so I (usually) just let them alone.
legendary
Activity: 1694
Merit: 1002
Go Big or Go Home.....
I'd think anything under 300gh is a waste.
member
Activity: 118
Merit: 10
Is the pool being dragged down by sending shares to GPU  miners? Wouldn't it be better to send those shares to faster miners?
I randomly go and ban CPU/GPU miners - but haven't for a while.
They cause wasted bandwidth that will just about never produce a share.
Not gonna affect the luck - just wasted bandwidth.

With today's miners speed. What would be considered outdated equipment? 
I ask this because it just seems to me sending shares to equipment that is real slow pulls everything down.
We have 87 users under 1th. Of those, 7 of them are under 10.gh.   13 range from 90.gh to 10.26gh.  18 range from 430.gh to 100gh. And 49 1th to 430gh.


legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Is the pool being dragged down by sending shares to GPU  miners? Wouldn't it be better to send those shares to faster miners?
I randomly go and ban CPU/GPU miners - but haven't for a while.
They cause wasted bandwidth that will just about never produce a share.
Not gonna affect the luck - just wasted bandwidth.
member
Activity: 118
Merit: 10
Is the pool being dragged down by sending shares to GPU  miners? Wouldn't it be better to send those shares to faster miners?
hero member
Activity: 1092
Merit: 552
Retired IRCX God
..
Yep S9v1 has indeed lost a lot - the most on this pool - 23.7%
Almost at the point where it would be hard to argue that it's random ...

Or, it could just be that they were a pile of shit not ready for production...  Huh
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
...
Quote
Code:
Name         CDF[Erl]
S9v1         0.994766  103.6 BDR   79 Blocks
strat 0.8.x  0.883100   15.0 BDR   11 Blocks
A6+?         0.881335   83.2 BDR   73 Blocks
proxy 1      0.776782    6.5 BDR    5 Blocks
A7v1         0.772224    6.5 BDR    5 Blocks
S7+S5+?(4.8) 0.627001  307.3 BDR  302 Blocks
ckpool                   5.7 BDR    6 Blocks
S?+? (4.7)   0.298274   16.5 BDR   19 Blocks
S9v2         0.223353   10.2 BDR   13 Blocks
A?+? (4.9)   0.040362  143.3 BDR  165 Blocks

strat 0.5/0.6            0.4 BDR    0 Blocks

Total 668.1 BDR  678 Blocks
'strat' is stratehm stratum proxy

The total stats since May is:
Block finders: 753.8 BDR  750 Blocks
Non-block Finders: 3.5 BDR
...
BDR is effectively how many blocks they are expected to have found.
Block Diff Ratio

Yep S9v1 has indeed lost a lot - the most on this pool - 23.7%
Almost at the point where it would be hard to argue that it's random ...
legendary
Activity: 1694
Merit: 1002
Go Big or Go Home.....
I got out of BTC pool mining after the drop in luck throughout the net after the S9 release. I'm sad for the people still mining though , hope somehow it recovers for you all.
legendary
Activity: 1726
Merit: 1018

I have always been after this type of data, or more to the point the raw data underneath. I am not sure what BDR is or what the math is behind your CDF figure but given the raw data is it possible for you to confirm that all of the devices are finding a similar number of blocks on average for the same amount of work. I want to put to bed the conspiracy that a particular type of miner firmware could send a low number of successful blocks to a different IP than the pool it is working for.  A single UDP packet containing a small simply encrypted string to a common range of IP addresses such as one in AWS would be difficult to spot but 1 in a 100 or so additional found blocks would certainly help a pool out. Data like this would help to spot an underperforming type of miner.


I don't mean to be rude but to believe this "conspiracy" requires ignorance about how mining actually works.  My miners could supply the solution share that was high enough difficulty to make it "a block" to anybody in the world, but it would really only be useful to the pool that sent my miner the work, because only that pool has everything else that is required to make it an actual block on the network. Miners don't work with all of the actual data that comprises a block, if they did, the bandwidth required for mining would be enormous and it would essentially make pool mining pointless anyway.  The full block data also includes the payout address or addresses.  The solution share is only a solution for the specific data the pool is working with, meaning the specific set of transactions, including the payout transactions.  So in other words, a "block" on the miner side is only an actual block on the bitcoin network when you have both the specific transaction pool (which the mining pool has and which is constantly changing as other bitcoin blocks are mined and new bitcoin transactions are made) and the solution share (which the hardware miner finds).  So again, the solution is only a solution for the pool that provided the work.  You might have some confusion based on the fact that it is common to talk about how a miner finds a block when in fact what the miner finds is a solution share to a set of data that only the pool has.

If you want an actual conspiracy idea then ponder the notion that the firmware is dropping certain solution shares instead of submitting them to the pool (whether by design or by accident).  You can't directly help another pool that way but you could hurt the pool you are on (and if you are a hardware manufacturer who also runs a pool then you can sell these miners to your competition and hurt them).  This is why that data that Kano posted is useful.  S9 firmware with BMminer v 1.0 appears unlucky.  So the only question is, how likely is that luck?  The recent luck on this pool has certainly deviated into the realm of unlikely but is it unlikely enough to say something is definitely amiss?  It's pretty unlikely that your life will come to an end due to the actions of a crocodile, and yet some humans do meet their end that way.  Even very unlikely things happen.

One thing to note, new firmware for S9's that includes BMminer v 2.0 does work on the old miners (assuming the firmware upgrade succeeds.)  BMminer v 2.0 does not appear unlucky in Kano's data.   But of course this is only data from one small pool.  BMminer v 1.0 might have average luck when a larger data set is seen.
legendary
Activity: 952
Merit: 1003
We go through this angst-ridden experience whenever we get a bad luck run. However, it's still the...

newbie
Activity: 65
Merit: 0
Well in case anyone was wondering about pool changes (and someone commented before)

Blocks have been found since all changes that have occurred.
i.e. the pool does find blocks with the current configuration.
I'm not using any of the current ckpool git segwit which doesn't work.

The bad luck itself (as I posted before) has quite clearly been since the last block in November.

Now for some statistics (since the middle of May) I mentioned I'd post sooner or later:
Code:
Name         CDF[Erl]
S9v1         0.994766  103.6 BDR   79 Blocks
strat 0.8.x  0.883100   15.0 BDR   11 Blocks
A6+?         0.881335   83.2 BDR   73 Blocks
proxy 1      0.776782    6.5 BDR    5 Blocks
A7v1         0.772224    6.5 BDR    5 Blocks
S7+S5+?(4.8) 0.627001  307.3 BDR  302 Blocks
ckpool                   5.7 BDR    6 Blocks
S?+? (4.7)   0.298274   16.5 BDR   19 Blocks
S9v2         0.223353   10.2 BDR   13 Blocks
A?+? (4.9)   0.040362  143.3 BDR  165 Blocks

strat 0.5/0.6            0.4 BDR    0 Blocks

Total 668.1 BDR  678 Blocks
'strat' is stratehm stratum proxy

The total stats since May is:
Block finders: 753.8 BDR  750 Blocks
Non-block Finders: 3.5 BDR


Exactly this, plus slush's pool fee is 2% compared to 0.9%, this over a long period of time accumulates to a pretty significant sum. Plus I'd rather my fees go toward someone who contributed and still contributes to open source BTC mining software.

kano.is for life
Good point. I was almost thinking of jumping, but the more I read about other pools, the more I think that I made a solid decision with mining in this (kano.is) pool.
Cheers to more Blocks everyone!
member
Activity: 72
Merit: 10
Well in case anyone was wondering about pool changes (and someone commented before)

Blocks have been found since all changes that have occurred.
i.e. the pool does find blocks with the current configuration.
I'm not using any of the current ckpool git segwit which doesn't work.

The bad luck itself (as I posted before) has quite clearly been since the last block in November.

Now for some statistics (since the middle of May) I mentioned I'd post sooner or later:
Code:
Name         CDF[Erl]
S9v1         0.994766  103.6 BDR   79 Blocks
strat 0.8.x  0.883100   15.0 BDR   11 Blocks
A6+?         0.881335   83.2 BDR   73 Blocks
proxy 1      0.776782    6.5 BDR    5 Blocks
A7v1         0.772224    6.5 BDR    5 Blocks
S7+S5+?(4.8) 0.627001  307.3 BDR  302 Blocks
ckpool                   5.7 BDR    6 Blocks
S?+? (4.7)   0.298274   16.5 BDR   19 Blocks
S9v2         0.223353   10.2 BDR   13 Blocks
A?+? (4.9)   0.040362  143.3 BDR  165 Blocks

strat 0.5/0.6            0.4 BDR    0 Blocks

Total 668.1 BDR  678 Blocks
'strat' is stratehm stratum proxy

The total stats since May is:
Block finders: 753.8 BDR  750 Blocks
Non-block Finders: 3.5 BDR


Exactly this, plus slush's pool fee is 2% compared to 0.9%, this over a long period of time accumulates to a pretty significant sum. Plus I'd rather my fees go toward someone who contributed and still contributes to open source BTC mining software.

kano.is for life
hero member
Activity: 1092
Merit: 552
Retired IRCX God
... Sorry if I offended you in some way. Don't take it so hard.  Kiss
...

I'm not offended in the least, I'm just totally over (and have been for well over 6 months now) hearing how we need larger block sizes AND Bitmain is ruining Bitcoin with empty blocks. I can see the claim that x is a result of y; however, if the push is that sizes need to increase, Bitmain is helping push it in that direction (if in no other way than showing people the perils of transaction latency). We are in a realm where democracy rules and if the majority of people wanted it to change, it would; bitching about it while presenting no alternative solution to offer Bitmain's competitors, by way of an option of orphaning empty blocks, is nothing more than pissing into the wind and ranting about having pissed on your leg.
legendary
Activity: 1453
Merit: 1011
Bitcoin Talks Bullshit Walks
...antpoo poo....attack on btc network...

This dumb shit again?   Huh

Dumb to you maybe.  But very important to me and how I see the btc network. Maybe I could have done without the poo poo talk. Very childish I agree. Sorry if I offended you in some way. Don't take it so hard.  Kiss

BR
hero member
Activity: 1092
Merit: 552
Retired IRCX God
A 3800TH/s rig would be nice though.  Tongue
newbie
Activity: 59
Merit: 0
For all Avalon A6 owner's out there, I have updated my power supplies with this 2400watt Kits from Parallel, I've seen an hashing rate increase of 200mhs +- 30mhz per unit. The kit can power two A6 and two A7. http://www.parallelminer.com/product/delta-2400watt-platinum-94-efficiency-power-supply-208v240v/
200Mhs is nothing. Or do you mean Ghs or do you mean MHz. You mixed units there as well...

Sorry for the mistype I mean I'm getting 3800Ths constant. I was always at 3500 to 3650 before. I meant 150Ghs ... I guess I've playing with Zcash mining too much ... Sorry
Your correction is also wrong.  Your are getting 3.8TH/s... or 3800GH/s.  you most assuredly are not getting 3800TH/s from an A6.

I must be coffee drunk ! Yes you are correct 3800GH/s .... Oufff
legendary
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
For all Avalon A6 owner's out there, I have updated my power supplies with this 2400watt Kits from Parallel, I've seen an hashing rate increase of 200mhs +- 30mhz per unit. The kit can power two A6 and two A7. http://www.parallelminer.com/product/delta-2400watt-platinum-94-efficiency-power-supply-208v240v/
200Mhs is nothing. Or do you mean Ghs or do you mean MHz. You mixed units there as well...

Sorry for the mistype I mean I'm getting 3800Ths constant. I was always at 3500 to 3650 before. I meant 150Ghs ... I guess I've playing with Zcash mining too much ... Sorry
Your correction is also wrong.  Your are getting 3.8TH/s... or 3800GH/s.  you most assuredly are not getting 3800TH/s from an A6.
Jump to: