Swedish ASIC miner company kncminer.com

[sickpig]

just updated my mercury from .98 to .98.1 and HW errors went from 6.9% to around 1.5%. also, rejected was 3% to 0% now!

definitely a good upgrade. all cores functioning as well. none are off.

UPDATE: been running .98.1 for 30 mins now, hw errors down to 1.1% and dropping. still no duplicate shares!

0.98.1 was intended for those with a dead die; die 0
There is no other difference as far as I know.

thats what i thought too man, but its made a big difference for me!

Hashrate @ the pool before and after?

[ASIC-K]

just updated my mercury from .98 to .98.1 and HW errors went from 6.9% to around 1.5%. also, rejected was 3% to 0% now!

definitely a good upgrade. all cores functioning as well. none are off.

UPDATE: been running .98.1 for 30 mins now, hw errors down to 1.1% and dropping. still no duplicate shares!

0.98.1 was intended for those with a dead die; die 0
There is no other difference as far as I know.

thats what i thought too man, but its made a big difference for me!

Hashrate @ the pool before and after?

im on eligius, and only been about an hour so far so too early to report. but ill get back to your in another two hours or so. honestly i didnt think it would make a difference, but it runs so much more stable now. temps are at 47 degrees steady too.

[CYPER]

Let's see what firmware they come up with Monday, because so far I'm far from impressed or satisfied with the product, not to mention the delay for which I still expect compensation.
Don't want to be nagging daily, but it seems that's the only way with KNC.

Jupiter 1 is hashing with 0.98.1(beta) at stable 564GH/s with 0.9% HW erros - no complaints there. The only thing that can be improved is the power consumption, but no big deal for now.

Jupiter 2 is still averaging 420GH/s with 0.98. The beta firmware did not help and it even reduced the hash speed to around 390-400GH/s. I expect improvements there.

[ASIC-K]

Let's see what firmware they come up with Monday, because so far I'm far from impressed or satisfied with the product, not to mention the delay for which I still expect compensation.
Don't want to be nagging daily, but it seems that's the only way with KNC.

Jupiter 1 is hashing with 0.98.1(beta) at stable 564GH/s with 0.9% HW erros - no complaints there. The only thing that can be improved is the power consumption, but no big deal for now.

Jupiter 2 is still averaging 420GH/s with 0.98. The beta firmware did not help and it even reduced the hash speed to around 390-400GH/s. I expect improvements there.

i wouldnt expect any kind of compensation for delays....kind of expected with this type of hardware. we are the guinea pigs! and im ok with that.

[CYPER]

Let's see what firmware they come up with Monday, because so far I'm far from impressed or satisfied with the product, not to mention the delay for which I still expect compensation.
Don't want to be nagging daily, but it seems that's the only way with KNC.

Jupiter 1 is hashing with 0.98.1(beta) at stable 564GH/s with 0.9% HW erros - no complaints there. The only thing that can be improved is the power consumption, but no big deal for now.

Jupiter 2 is still averaging 420GH/s with 0.98. The beta firmware did not help and it even reduced the hash speed to around 390-400GH/s. I expect improvements there.

i wouldnt expect any kind of compensation for delays....kind of expected with this type of hardware. we are the guinea pigs! and im ok with that.

I think there is a direct correlation between the number of days that one's order is delayed past the 15th October and the expectation for a compensation.
The longer the delay, the higher the expectation.
I am not surprised that people who endured a delay of less than 5 days are less inclined to argue over any compensation.
But I waited 14 days and while some people are half way to their ROI, I am nowhere near that, which makes me far from happy and satisfied as a KNCminer customer.

[The Avenger]

Let's see what firmware they come up with Monday, because so far I'm far from impressed or satisfied with the product, not to mention the delay for which I still expect compensation.
Don't want to be nagging daily, but it seems that's the only way with KNC.

Jupiter 1 is hashing with 0.98.1(beta) at stable 564GH/s with 0.9% HW erros - no complaints there. The only thing that can be improved is the power consumption, but no big deal for now.

Jupiter 2 is still averaging 420GH/s with 0.98. The beta firmware did not help and it even reduced the hash speed to around 390-400GH/s. I expect improvements there.

i wouldnt expect any kind of compensation for delays....kind of expected with this type of hardware. we are the guinea pigs! and im ok with that.

I think there is a direct correlation between the number of days that one's order is delayed past the 15th October and the expectation for a compensation.
The longer the delay, the higher the expectation.
I am not surprised that people who endured a delay of less than 5 days are less inclined to argue over any compensation.
But I waited 14 days and while some people are half way to their ROI, I am nowhere near that, which makes me far from happy and satisfied as a KNCminer customer.

+1

I didn't sign up to be a guinea pig to test faulty hardware or the price should have reflected that.

As far as I can see, I paid a massively marked-up price to be supplied a professionally designed and built product on or before mid October 2013. I'm also less than impressed with the faulty goods I actually recieved well after that date.

[DimensionsOfHell]

just updated my mercury from .98 to .98.1 and HW errors went from 6.9% to around 1.5%. also, rejected was 3% to 0% now!

definitely a good upgrade. all cores functioning as well. none are off.

UPDATE: been running .98.1 for 30 mins now, hw errors down to 1.1% and dropping. still no duplicate shares!

0.98.1 was intended for those with a dead die; die 0
There is no other difference as far as I know.

It might be for people that has die 0, but I think it'll help everyone though.

I am, unfortunately one of the people with die 0, and the update did not fix the issue, although it did seem to help a lot of other people. Just my luck, that didn't help me either. I'm still at about 212GH/s stable with the 0.9.8.1 fw update. What I noticed was that, even though it didnt bring any dies back to life, it did have a big difference in error rates. I went from 5.4% HW rates to now 0.27% (according to bertmod stats), and went from device rejected/ pool rejected 2.4%/ 2.1% to 0.1410%/ 0.1388% respectively. My WU went from 2880/m to 2955/m.

So unless you are <2% error rate, I think it's worth upgrading for anyone. I haven't heard of many people having negative effects on this FW. And for the people who did, it slowly crept back up to their original hash rate, with a lower error rate.

That's just my 2 cents.


On a side note;
    I emailed KnC regarding my unit still not hashing properly after the 0.9.8 update last Tuesday, and they have yet to contact me back. I've also tried calling several times on Friday (as that was already 3 business days. They claim to reply back within 2) from 11AM to 5PM (their time), and I got no answer. I don't think they bother working on Fridays anymore. I also called the Friday before that, and no one picked up.
It's great that so many people are getting 280+ gh/s on their Saturns, but it's just so frustrating for me.

From Friday Oct 22nd (when I got my unit), I was hashing at 150GH/s, until Tuesday Oct 26th (when fw 0.9.8 came out). That is BTC0.66 (280-150= 130. So BTC0.1678 X 4 days = BTC0.66) I lost in those 4 days.
Since Oct 26th, I've been hashing at 212GH/s. So since the 26th, I've lost an additional BTC0.6123. At current rate, I've lost over $265, and still losing. And thats not even counting the delay. This sucks.


EDIT: Also of note, according to bertmod, 100% of all my cores are running, so I don't know what the problem is with the hash rate, some of the cores are just not getting enough power due to the bad VRMs?

[rolling]

just updated my mercury from .98 to .98.1 and HW errors went from 6.9% to around 1.5%. also, rejected was 3% to 0% now!

definitely a good upgrade. all cores functioning as well. none are off.

UPDATE: been running .98.1 for 30 mins now, hw errors down to 1.1% and dropping. still no duplicate shares!

0.98.1 was intended for those with a dead die; die 0
There is no other difference as far as I know.

EDIT: Also of note, according to bertmod, 100% of all my cores are running, so I don't know what the problem is with the hash rate, some of the cores are just not getting enough power due to the bad VRMs?

If bertmod is showing really low amps for one of the VRMs, you can try to turn off the fan on that unit and let the heat rise to 75C or so.  Many people on the KNC forum have revived cores by doing this with .98.1.  It worked for one of my cores but I still have one that won't come on.

[Bogart]

just updated my mercury from .98 to .98.1 and HW errors went from 6.9% to around 1.5%. also, rejected was 3% to 0% now!

definitely a good upgrade. all cores functioning as well. none are off.

UPDATE: been running .98.1 for 30 mins now, hw errors down to 1.1% and dropping. still no duplicate shares!

0.98.1 was intended for those with a dead die; die 0
There is no other difference as far as I know.

thats what i thought too man, but its made a big difference for me!

My Saturn's currently running 0.98 with 1.2% hw errors, and only one core that keeps getting toggled on and off.

cgminer reports a long term average of 283.8Ghps.  Darned near the theoretical maximum of 284.  I'm not gonna touch it.

[RoadStress]

Let's see what firmware they come up with Monday, because so far I'm far from impressed or satisfied with the product, not to mention the delay for which I still expect compensation.
Don't want to be nagging daily, but it seems that's the only way with KNC.

Jupiter 1 is hashing with 0.98.1(beta) at stable 564GH/s with 0.9% HW erros - no complaints there. The only thing that can be improved is the power consumption, but no big deal for now.

Jupiter 2 is still averaging 420GH/s with 0.98. The beta firmware did not help and it even reduced the hash speed to around 390-400GH/s. I expect improvements there.

Man i really don't understand you people. All you do is just whine and bitch here on the forums. I wonder what's the actual percentage of KnC customers that are whining because i see the same 10-15 people around out of the ~3000 orders(?). Why should you receive compensation for your own laziness/lack of knowledge of using the RMA system. There is absolutely 0 reason for you to complain like an incapacitated child. If the product you bought is sub-par with what they advertise then grow up and RMA it and in a matter of days you will have your perfect product. In the long term you are losing more than the shipping and the time lost while waiting for the RMA.

Enjoy!

[DimensionsOfHell]

Tried to raise the temp on the unit that's showing two bad VRMs. Made no difference.





And to RoadStress:

    If you have nothing of value to input, please keep that to your self. You don't seem to comprehend the whole situation.

I've asked KnC to issue an RMA LAST TUESDAY. They have not yet replied to me in regards to it. I origianally asked them when I received my unit. They told me to wait for FW 0.9.8, because that would fix it. I emailed them back saying it didn't fix the problem, and they haven't replied yet.
So again, if you don't want to be helpful, please keep it to your self, otherwise you are just one of the "whiners." Stop whining about other people. This is a forum, designed for discussion, what we are doing here is discussing.

[docjunior]

Let's see what firmware they come up with Monday, because so far I'm far from impressed or satisfied with the product, not to mention the delay for which I still expect compensation.
Don't want to be nagging daily, but it seems that's the only way with KNC.

Hi Cyper,

I don't know if you have tried this, but after reading the KNC forums, I found a reference to the #kncminer channel on freenode IRC, where some of the orsoc developers tend to hang around. I had a serious problem with my miner that was not resolved by talking to support on the phone, but Henrik (hno) from Orsoc was on the IRC channel and promptly got the problem sorted! My miner was hosted, but perhaps he, or somebody else, mighy be able to fix your problem or at least help troubleshoot. Worth a try, and much more effective than posting here. I don't think anyone from KNC or Orsoc is reading this thread(?)

[CYPER]

Man i really don't understand you people. All you do is just whine and bitch here on the forums. I wonder what's the actual percentage of KnC customers that are whining because i see the same 10-15 people around out of the ~3000 orders(?). Why should you receive compensation for your own laziness/lack of knowledge of using the RMA system. There is absolutely 0 reason for you to complain like an incapacitated child. If the product you bought is sub-par with what they advertise then grow up and RMA it and in a matter of days you will have your perfect product. In the long term you are losing more than the shipping and the time lost while waiting for the RMA.

Because using the RMA system makes no sense from a financial point of view. You will make more BTC mining with 420GH/s now, than send the miner back in order to mine presumably with 550GH/s in 5-7 days.
I was given an RMA number on 31st and the next day Bitcoinorama was kind enough to give me the 0.98.1 Beta, which healed one of my Jupiters completely, which just shows that there is lack of communication internally between the different departments. While suggest a RMA, when there is a chance for a software fix?
Currently I am 99% convinced that my other Jupiter will be healed too, which makes me wonder why people decide to send boards back. That makes no sense.

Hi Cyper,

I don't know if you have tried this, but after reading the KNC forums, I found a reference to the #kncminer channel on freenode IRC, where some of the orsoc developers tend to hang around. I had a serious problem with my miner that was not resolved by talking to support on the phone, but Henrik (hno) from Orsoc was on the IRC channel and promptly got the problem sorted! My miner was hosted, but perhaps he, or somebody else, mighy be able to fix your problem or at least help troubleshoot. Worth a try, and much more effective than posting here. I don't think anyone from KNC or Orsoc is reading this thread(?)

I hang there quite often and has spoken with hno just yesterday, but he hasn't suggested anything that can fix my 2nd Jupiter.

[Phoenix1969]

Tried to raise the temp on the unit that's showing two bad VRMs. Made no difference.

[
And to RoadStress:

    If you have nothing of value to input, please keep that to your self. You don't seem to comprehend the whole situation.

I've asked KnC to issue an RMA LAST TUESDAY. They have not yet replied to me in regards to it. I origianally asked them when I received my unit. They told me to wait for FW 0.9.8, because that would fix it. I emailed them back saying it didn't fix the problem, and they haven't replied yet.
So again, if you don't want to be helpful, please keep it to your self, otherwise you are just one of the "whiners." Stop whining about other people. This is a forum, designed for discussion, what we are doing here is discussing.

to what temp?

[timmmers]

just updated my mercury from .98 to .98.1 and HW errors went from 6.9% to around 1.5%. also, rejected was 3% to 0% now!

definitely a good upgrade. all cores functioning as well. none are off.

UPDATE: been running .98.1 for 30 mins now, hw errors down to 1.1% and dropping. still no duplicate shares!

0.98.1 was intended for those with a dead die; die 0
There is no other difference as far as I know.

thats what i thought too man, but its made a big difference for me!

My Saturn's currently running 0.98 with 1.2% hw errors, and only one core that keeps getting toggled on and off.

cgminer reports a long term average of 283.8Ghps.  Darned near the theoretical maximum of 284.  I'm not gonna touch it.

I must have missed something but where did that theorectical max info come from ? I was wondering what that was.

[xyzzy099]

just updated my mercury from .98 to .98.1 and HW errors went from 6.9% to around 1.5%. also, rejected was 3% to 0% now!

definitely a good upgrade. all cores functioning as well. none are off.

UPDATE: been running .98.1 for 30 mins now, hw errors down to 1.1% and dropping. still no duplicate shares!

0.98.1 was intended for those with a dead die; die 0
There is no other difference as far as I know.

thats what i thought too man, but its made a big difference for me!

My Saturn's currently running 0.98 with 1.2% hw errors, and only one core that keeps getting toggled on and off.

cgminer reports a long term average of 283.8Ghps.  Darned near the theoretical maximum of 284.  I'm not gonna touch it.

I must have missed something but where did that theorectical max info come from ? I was wondering what that was.

Basically, each hash module has 192 cores that hash at 750MH/s each, so 144 GH/s per module.

From http://forum.kncminer.com/forum/main-category/hardware/13049-read-me-first-known-issues-slow-performance-dc-dc-problem-bad-core-map-etc :

What kind of performance should I expect from each model?

Each ASIC module is made up up 4 dies, of 48 cores per die, each die connected and powered by unique power and connectivity. See a good picture of the ASIC module here: https://www.kncminer.com/news/news-30

MERCURY

    Made up of (1) ASIC modules, 192 cores
    100% of cores functional, expected performance up to 144GH.
    75% of cores functional, expected performance up to 108GH

SATURN

    Made up of (2) ASIC modules, 384 cores
    100% of cores functional, expected performance up to 288GH.
    75% of cores functional, expected performance up to 216GH

JUPITER

    Made up of (4) ASIC modules, 768 cores
    100% of cores functional, expected performance up to 576GH.
    75% of cores functional, expected performance up to 432GH

[DimensionsOfHell]

to what temp?

I got it up to 90c before I put the fan back on. I didn't wanna risk letting get any higher. I know the limit is supposed to be about 105c, but why risk it right?
Anyway, I noticed that when it got to around 90, all the VRMs showed an output of 0A. So I let it cool down, and when it got to about 51c, the two normally working VRMs kicked back in. I let it slowly climb back up by blocking airflow. I noticed when it gets to 75.5c, a third VRM kicks in. Its not until it hits 80c, that the 4th VRM kicks in.

As soon as the 4th VRM kick in, the temps get to 83c, and then every VRM drops back down to 0A.

So from this experiment; I've gotta figure out somehow to keep one of the boards under 55c (thats where it hashes the best, and the other one between 80c - 82c, which is freaking difficult. Just a bit of airflow makes more then 2 degrees of difference.

[Phoenix1969]

to what temp?

I got it up to 90c before I put the fan back on. I didn't wanna risk letting get any higher. I know the limit is supposed to be about 105c, but why risk it right?
Anyway, I noticed that when it got to around 90, all the VRMs showed an output of 0A. So I let it cool down, and when it got to about 51c, the two normally working VRMs kicked back in. I let it slowly climb back up by blocking airflow. I noticed when it gets to 75.5c, a third VRM kicks in. Its not until it hits 80c, that the 4th VRM kicks in.

As soon as the 4th VRM kick in, the temps get to 83c, and then every VRM drops back down to 0A.

So from this experiment; I've gotta figure out somehow to keep one of the boards under 55c (thats where it hashes the best, and the other one between 80c - 82c, which is freaking difficult. Just a bit of airflow makes more then 2 degrees of difference.

Roger that... 80 should have been enough I would think...

[CYPER]

to what temp?

I got it up to 90c before I put the fan back on. I didn't wanna risk letting get any higher. I know the limit is supposed to be about 105c, but why risk it right?
Anyway, I noticed that when it got to around 90, all the VRMs showed an output of 0A. So I let it cool down, and when it got to about 51c, the two normally working VRMs kicked back in. I let it slowly climb back up by blocking airflow. I noticed when it gets to 75.5c, a third VRM kicks in. Its not until it hits 80c, that the 4th VRM kicks in.

As soon as the 4th VRM kick in, the temps get to 83c, and then every VRM drops back down to 0A.

So from this experiment; I've gotta figure out somehow to keep one of the boards under 55c (thats where it hashes the best, and the other one between 80c - 82c, which is freaking difficult. Just a bit of airflow makes more then 2 degrees of difference.

I would suggest waiting for the next firmware, which should hopefully fix all problems.
I mean we shouldn't make our own fixes, right?

[timmmers]

just updated my mercury from .98 to .98.1 and HW errors went from 6.9% to around 1.5%. also, rejected was 3% to 0% now!

definitely a good upgrade. all cores functioning as well. none are off.

UPDATE: been running .98.1 for 30 mins now, hw errors down to 1.1% and dropping. still no duplicate shares!

0.98.1 was intended for those with a dead die; die 0
There is no other difference as far as I know.

thats what i thought too man, but its made a big difference for me!

My Saturn's currently running 0.98 with 1.2% hw errors, and only one core that keeps getting toggled on and off.

cgminer reports a long term average of 283.8Ghps.  Darned near the theoretical maximum of 284.  I'm not gonna touch it.

I must have missed something but where did that theorectical max info come from ? I was wondering what that was.

Basically, each hash module has 192 cores that hash at 750MH/s each, so 144 GH/s per module.

From http://forum.kncminer.com/forum/main-category/hardware/13049-read-me-first-known-issues-slow-performance-dc-dc-problem-bad-core-map-etc :

What kind of performance should I expect from each model?

Each ASIC module is made up up 4 dies, of 48 cores per die, each die connected and powered by unique power and connectivity. See a good picture of the ASIC module here: https://www.kncminer.com/news/news-30

MERCURY

    Made up of (1) ASIC modules, 192 cores
    100% of cores functional, expected performance up to 144GH.
    75% of cores functional, expected performance up to 108GH

SATURN

    Made up of (2) ASIC modules, 384 cores
    100% of cores functional, expected performance up to 288GH.
    75% of cores functional, expected performance up to 216GH

JUPITER

    Made up of (4) ASIC modules, 768 cores
    100% of cores functional, expected performance up to 576GH.
    75% of cores functional, expected performance up to 432GH

Cheers mate. I did miss that.
Mine a hair off that 142-143Gh  . 39 degrees.
Been lucky