Swedish ASIC miner company kncminer.com

[FiatKiller]

Interesting... applied 9.6.1 and it still shows 9.6 and initially everything was worse than 9.6

So I applied enablecores again and too early to say for sure, but looking very good.

I've also noticed an interesting phenomena of "bad boots". Sometimes after a restart things are not up to par, but if you keep trying you will hit a "golden boot" that works much better. I recommend for people having trouble to try this!

Never seen this much speed before, but too early to say how it will stabilize:

https://dl.dropboxusercontent.com/u/40920348/KNC961EC.jpg

your WU is very good. I've 7475 for my jup.

Right now, but what happens is that the difficulty keeps going up to over 4 mill and the WU drops to 3700ish. We will see what happens. Going to let it ride without screwing around with it any further for awhile.  lol

[1713485557]

1713485557

[1713485557]

1713485557

[1713485557]

1713485557

[1713485557]

1713485557

[1713485557]

1713485557

[1713485557]

1713485557

[timmmers]

Merc arrived, 10 mins unpacking and checking (using the various lists posted here so I didn't forget anything ..BIG THANKS FOR THAT)
Well packed and undamaged. They learned. Oh, no ethernet cable if you don't have a spare.

Everything whirring away...no stats in the KNC page...not hashing.

2nd screen with pool details didn't have cgminer enabled, did that restarted cgminer and we're off. Firmware .96 on it when it arrived.

Now been running about 10 mins at 110 to 139 Gh and 39 C with no extra cooling.
Feeling confident ish

Cat in box. He says it's a quality box and he knows these things

[xyzzy099]

Interesting... applied 9.6.1 and it still shows 9.6 and initially everything was worse than 9.6

So I applied enablecores again and too early to say for sure, but looking very good.

I've also noticed an interesting phenomena of "bad boots". Sometimes after a restart things are not up to par, but if you keep trying you will hit a "golden boot" that works much better. I recommend for people having trouble to try this!

Never seen this much speed before, but too early to say how it will stabilize:

https://dl.dropboxusercontent.com/u/40920348/KNC961EC.jpg

your WU is very good. I've 7475 for my jup.

Right now, but what happens is that the difficulty keeps going up to over 4 mill and the WU drops to 3700ish. We will see what happens. Going to let it ride without screwing around with it any further for awhile.  lol

Difficulty has nothing to do with WU.

[opentoe]

All I want is to break even...if that is even a small possibility now or not. I paid $4k for my Saturn. If things are static and stay the same it will take me 60 days or so to break even, I can deal with that. But so many more hashing power coming out its just gonna kill me/us. What to do. Would it even be wise to upgrade my Saturn to a Jupiter? If I do that, I'll be in the same boat, having spent more money. Yea, a little more hashing power but more cash out of my pocket. Oh, what to do.

[FiatKiller]

"Difficulty has nothing to do with WU."

Sure it does. The miner has to work harder to do the calcs and is therefore less efficient.
How do you explain that WU has an inverse relationship for me then? WU always starts
greater than 4K and drops to as low as 3.6K

[xyzzy099]

"Difficulty has nothing to do with WU."

Sure it does. The miner has to work harder to do the calcs and is therefore less efficient.
How do you explain that WU has an inverse relationship for me then? WU always starts
greater than 4K and drops to as low as 3.6K

WU is just a ratio of accepted shares to rejected shares.  It depends only on your hash rate and (effectively) how many difficulty 1 shares you submit that get accepted.  Difficulty is not part of the calculation, and doesn't affect any of the factors that are.

Are you saying that your WU changes when difficulty changes?  It sounds like you are saying that your WU varies over time even with no difficulty change, so I don't understand where you are deriving the relationship to difficulty.  Diff only changes once ever 2016 blocks.

[texaslabrat]

"Difficulty has nothing to do with WU."

Sure it does. The miner has to work harder to do the calcs and is therefore less efficient.
How do you explain that WU has an inverse relationship for me then? WU always starts
greater than 4K and drops to as low as 3.6K

The KnC version of cgminer includes the HW errors as part of the WU calculation.  So, when you first start the miner, I'm guessing yours acts like mine and has all the bad cores running that it has to disable due to 10 errors in a row.  While they are spewing garbage, those errors are being added to the WU number and thus artificially inflating it.

As was mentioned before, the difficulty of the block is irrelevant.  You are not working on a block, you are working on a share of fixed difficulty.  Now, if you want to change the pool difficulty up and down and document your relative HW error rate compared to Accepted shares...that I could see where the "it's working harder therefore less efficient" argument might be made depending on the results.

[FiatKiller]

"Difficulty has nothing to do with WU."

Sure it does. The miner has to work harder to do the calcs and is therefore less efficient.
How do you explain that WU has an inverse relationship for me then? WU always starts
greater than 4K and drops to as low as 3.6K

WU is just a ratio of accepted shares to rejected shares.  It depends only on your hash rate and (effectively) how many difficulty 1 shares you submit that get accepted.  Difficulty is not part of the calculation, and doesn't affect any of the factors that are.

Are you saying that your WU changes when difficulty changes?  It sounds like you are saying that your WU varies over time even with no difficulty change, so I don't understand where you are deriving the relationship to difficulty.  Diff only changes once ever 2016 blocks.

The difficulty from this pic:(ALWAYS starts low and rises constantly with time. WU starts high, and lowers over time)

[xyzzy099]

"Difficulty has nothing to do with WU."

Sure it does. The miner has to work harder to do the calcs and is therefore less efficient.
How do you explain that WU has an inverse relationship for me then? WU always starts
greater than 4K and drops to as low as 3.6K

WU is just a ratio of accepted shares to rejected shares.  It depends only on your hash rate and (effectively) how many difficulty 1 shares you submit that get accepted.  Difficulty is not part of the calculation, and doesn't affect any of the factors that are.

Are you saying that your WU changes when difficulty changes?  It sounds like you are saying that your WU varies over time even with no difficulty change, so I don't understand where you are deriving the relationship to difficulty.  Diff only changes once ever 2016 blocks.

The difficulty from this pic:(ALWAYS starts low and rises constantly with time. WU starts high, and lowers over time)

That number is just the number of shares you have had accepted at the current difficulty, not the actual mining difficulty itself.

[Altomesi]

Code:

bfgminer version 3.3.0 - Started: [2013-10-22 04:02:28] - [  0 days 02:14:20]
 [M]anage devices [P]ool management [S]ettings [D]isplay options  [H]elp [Q]uit
 Connected to stratum.mining.eligius.st diff 64 with stratum as user 14cbTxT4nN1AFQzEdFURb9co
 Block: ...ed7f12e1 #265245  Diff:268M ( 1.92Ph/s)  Started: [06:23:33]
 ST:2  F:0  NB:29  AS:0  BW:[141/126 B/s]  E:457.72  I:20.14mBTC/hr  BS:939k
 2/379  60.0C | 267.0/269.3/255.2Gh/s | A:6847 R:28+0(.40%) HW:14839/3.0%
--------------------------------------------------------------------------------
 KNC 0: 60.0C | 134.1/131.7/123.3Gh/s | A:3286 R:19+0(.55%) HW:12796/5.2%
 KNC 1: 55.0C | 140.4/137.7/131.9Gh/s | A:3564 R: 9+0(.25%) HW: 2044/.82%

Kudos! You're fast

I really appreciate that BFGminer split stats per asic slot, very useful.
So from the statistics you reported here it seems that the core with higher temp perform worse and has a lot of HW error more.
I'm really looking forward to use BFGminer on my jups.

Working like a champ on a .96 Mercury. seeing better results on HW errors initially, will see if long term it stays less. Donation coming your way Luke-Jr.

[Luke-Jr]

Starting bfgminer as described (of course I "q"uit the original cgminer first) results in a Segmentation fault and the TTY settings broken and a cleared screen.

Code:

opkg install gdb
gdb --args ./bfgminer -S knc:auto -c /config/cgminer.conf -T -D
run

... wait for the crash ...

Code:

bt

[FiatKiller]

"Difficulty has nothing to do with WU."

Sure it does. The miner has to work harder to do the calcs and is therefore less efficient.
How do you explain that WU has an inverse relationship for me then? WU always starts
greater than 4K and drops to as low as 3.6K

WU is just a ratio of accepted shares to rejected shares.  It depends only on your hash rate and (effectively) how many difficulty 1 shares you submit that get accepted.  Difficulty is not part of the calculation, and doesn't affect any of the factors that are.

Are you saying that your WU changes when difficulty changes?  It sounds like you are saying that your WU varies over time even with no difficulty change, so I don't understand where you are deriving the relationship to difficulty.  Diff only changes once ever 2016 blocks.

The difficulty from this pic:(ALWAYS starts low and rises constantly with time. WU starts high, and lowers over time)

That number is just the number of shares you have had accepted at the current difficulty, not the actual mining difficulty itself.

Ah, shares, not difficulty... got it. Thanks! Duh...  lol

[Phoenix1969]

Just wanted to check whether everyone received your miners (100 BTC/Jupiter) so far, able to earn at least 75 BTC/Jupiter?

Because next week, November miners due for release which are only 25 BTC/Jupiter.

So, what's the moral of the story?

The moral is....     your math sucks. Btc is 200 now, so takes 35 BTC to make 7 grand, not 75...lol

[idee2013]

I noticed something interesting with my Mercury that I was hoping others could confirm. My miner has been running at about 120GHs with 1 core disabled pulling 117W of power at about 36C per bertmod. I stuck the miner in the Garage yesterday since it's getting cold here now and this morning I check and it's running about 138Ghs pulling 109W of power at about 27C and only 1 core disabled. I've read several posts on here from 'ormoma that the temperatures don't matter but this clearly shows that a 10C drop in ambient temperature gave me a significant boost in hashing power that has been sustained ever since the temperature change not to mention the lower power draw...

they matter. basta..same here with 2 miners

[c1010010]

So, talk performance.  How are they?  Not posted perf, but actual.

My Jupiter has been running for just under 23 hours.  cgminer shows an average of 547Gh/s and 2.5% error rate.  That translates to a pool speed of 533GH/s.

Bertmod (monitoring software) says the chips are taking 480 watts.  Plus the power for the beaglebone.

Good data point, thanks.

[Xialla]

Just wanted to check whether everyone received your miners (100 BTC/Jupiter) so far, able to earn at least 75 BTC/Jupiter?

Because next week, November miners due for release which are only 25 BTC/Jupiter.

So, what's the moral of the story?

The moral is....     your math sucks. Btc is 200 now, so takes 35 BTC to make 7 grand, not 75...lol

doesn't matter about BTC/$ value. I paid 86BTC for Jupiter, VAT and shipping and never will mine my 86BTC back.

[mgio]

Why does the web interface report my KNC hashrate at an average of 508 GH/s but Eligius's (mining pool) stats page say the average is only 484 GH/s.

Why the discrepancy? These numbers match for my Avalon and my other miners.

[Syke]

What happened to daily shipping updates? I need to know how much to cry.

[Phoenix1969]

I noticed something interesting with my Mercury that I was hoping others could confirm. My miner has been running at about 120GHs with 1 core disabled pulling 117W of power at about 36C per bertmod. I stuck the miner in the Garage yesterday since it's getting cold here now and this morning I check and it's running about 138Ghs pulling 109W of power at about 27C and only 1 core disabled. I've read several posts on here from 'ormoma that the temperatures don't matter but this clearly shows that a 10C drop in ambient temperature gave me a significant boost in hashing power that has been sustained ever since the temperature change not to mention the lower power draw...

honestly, some of the problems in here are caused by too much fiddling. Example : re-flashing An Aussie Jupiter with .096 last night...  seemingly slowed the rate to around 400 from 550!... BUT... slowly, gh by gh, overnight, it climbed up all the way back to 550
it did this on original setup as well.

[Phoenix1969]

Interesting... applied 9.6.1 and it still shows 9.6 and initially everything was worse than 9.6

So I applied enablecores again and too early to say for sure, but looking very good.

I've also noticed an interesting phenomena of "bad boots". Sometimes after a restart things are not up to par, but if you keep trying you will hit a "golden boot" that works much better. I recommend for people having trouble to try this!

Never seen this much speed before, but too early to say how it will stabilize:

it still showed 0.96, because you didnt clear your browser cashe after you flashed.
Letting the unit burn in for 24-48 hours with 0.96 will produce better results than tweaking units right away before you even have base numbers....
just sayin', because it happened to many units

example...

the 150Gh drop at the end is where we reflashed

but yes.. have noticed the "Golden boot phenomena" early in meddling... usually after a cold start... warm reboots do almost nothing for me.