Impressive.

I'm a newbie in this kind of work but I do appriciate the dataset you've provided. Did you extract this info directly from the blockchain using custom made tools?

After quick glance I've noticed that btc guild, among the big pools, doesn't provide block luck. Have you any insights on the possible reasons?

Sure you're right.

With a miner your BTCs will be "released" slowly, solved block after solved block, and you will not be able to sell all your "potential" BTCs all at once under the influence of your emotions.

Though, I wonder how high it would be the price someone is willing to pay to get this "safety" measure in place. Mine, at the end of the road, will be somewhat between 8 to 10 BTCs plus the cost of the miner (7500$), definitely a high price to pay.

Taken into account tha I've not even considered energy and maintenance costs in my back-of-the-envelope calculation.

Yeah 28 is more likely.

Anyway I'm not good at make diff predictions. When I was deciding if buying or not from KNC I've estimated a diff of 55 mil by mid September, what I naive I was. Luckily enough my btc value estimate was wrong either, by a ten fold, but in the right direction and of course KnC hashrate over-delivering come handy

Speaking of hypoetical hashrate if CT/HF/Bitmine had released on time... dunno, mind blowing for sure.  

sorry guys but I can't find anywhere such a bold estimate for the next jump, every place I look I found something between 1.7 and 1.8 bln (~ 24%), where did you find 40% prediction for the next adjustment? (of course also 24% is a hell of a lot but better than 40)

One of them is 'Orama, isn't he?

Look, I've bought a KnC jupiter batch1 when 1BTC was equal to 108$. It cost me 7500$ (jup+psu+delivery) ~= 70 BTC.

Since I've received the miner I started to mining for a total of 52BTC as of now. I could have mined more, but you know, theory and real life are quite different: my miner wasn't fully working in the beginning (die 0 issue solved at some point), initial fw releases were sub-optimal, psu failures, pools downtime etc etc.

To that, add maintenance cost, energy cost.

As last point, I really don't know if I will be able to mine another 18 BTC before running my jup will cost me more in terms of electricity than the btc it will produce.

In retrospect I should have bought BTC without any doubts.

 

blockchained.com:


what's your source ?

You should, really. No offence. Or at least work harder to improve your english.

Mind you we're on the same boat since I'm not a native english speaker and I know how difficult it is to gain a foreign language skill.

To make a long story short: the better you express yourself, the better we will able to help you, the higher your miners hashrate

ps.: I've just used google translate to make my post better

That chart is based on solved blocks. So it's function of variance (i.e. luck) and pool's hashrate. 24h timespan it's not the best choice, though.

Jelin, we need to understand what you're trying to say, for being able to help you.

Did you edit /etc/init.d/cgminer.sh or did you make a copy in config and used that copy to overclock your borads?

Anyway paste here, inside a "code" block, the script you're using.

No, at least in my expirience.

Every time I've increased voltage I've had higher Amps and Watts.

One quest though: how did you check hashrate at die level?

I have heard more than once hno (on IRC) and 'Orama (here @btctalk) referring to unexplainable situations related to KnC miners with phrases like "it's like chasing ghost".

And the situation described here seems to be rightly ascribed to this kind of "phenomena"

it seems worthy to give it a try.


Is there some brave souls out there who are running with 241/251 ?

I think you've just found the ghost hno/orama were referring to :-)

Yeah it could be, I'm going to check the knc thread...

edit: found the thread I was referring to. it seems I was right (strange:) they were talking about Amps. Though 'orama said thea we can push our October VRM till 64 Amps (wow).

don't worry too much. I've seen poeple reporting Amps quitre near to 60 or even above, not to mention their temperature.

I say that 50 Amps per die cause a long time ago on the main knc thread 'Orama said that the ASIC board was designed for a maximum total Amps of 200 (50 x 4 dies). But then again 'Orama quite recently revised the advice saying that we can run our die over the 50 Amps limit.

The fact is that I'm not a risk lover and I want to play on the safe side. But if you think about the how the total net hashrate is growing maybe it's worthy to risk a little bit more now rather than play it safe..  

Another thing that is keeping me from pushing harder is the fact that my miner it's not near my house, my colo is almost 40 Km away and  if something happen I've to drive through there and you know of life is.. work, family and everything... so it's not that I can run away in the middle of the day without any notice in advance.

The error rate is almost 10%, what's your hash rate @ the pool?

'Orama a few weeks ago on the main knc thread said you have to increase both voltage and frequency for SPI in case you're OCing. if memory serves my settings for valtage is 2.05, I can't remember the freq value (maybe around 29KHz, I'll check as soos as I'll get back home).

With this value I get ~ 1.5% hw error rate

edit: SPI freq value -> 290707 Hz

8 VRMs... so october jup I suppose. When you increase the clock for your ASICs they need more power to work  correctly, so you need to increase voltage settings for each dies. Ideally u should be able to get an idea of what are the dies with the higher numbers of disabled core looking at the Amps comsumption on the advanced tab, the lower the amps the higher the number of disabled  ores, the higher u need to set the voltage for that die. Something near 50 Amps per die is ok.

To get a more accurate idea of disabled  cores you should use bertmod, but pay attention cause it seems to me that it overwrites cgminer.sh.

btcguild have grown 1.2PH/s in 25 days.

on Dec the 11 pool hashrate was 2PH, now they're crunching at 3.26PH/s