Swedish ASIC miner company kncminer.com - page 1209.

Phoenix1969

legendary

Activity: 938

Merit: 1000

LIR DEV

Quote from: KnCMiningOp on October 26, 2013, 11:35:47 PM

Quote from: Phoenix1969 on October 26, 2013, 11:30:51 PM

no, Im saying the pressure brought a die back to life, wasnt making good contact

btw... that machine looks to be the fastest one now...

Oh nice! I saw that in this thread 20-30 pages back. Jupi 1 is the fastest

Yes, and I thank you for posting that...again

KnCMiningOp

sr. member

Activity: 448

Merit: 250

Quote from: Phoenix1969 on October 26, 2013, 11:30:51 PM

no, Im saying the pressure brought a die back to life, wasnt making good contact

btw... that machine looks to be the fastest one now...

Oh nice! I saw that in this thread 20-30 pages back. Jupi 1 is the fastest

DigginDeep

newbie

Activity: 59

Merit: 0

Quote from: Phoenix1969 on October 26, 2013, 11:11:59 PM

Quote from: KnCMiningOp on October 26, 2013, 09:08:43 PM

Anyone know why the voltages on our 3rd Jupi are higher than on the first two? I believe that as a result of the voltage being higher the temps are also higher. Also it is my understanding that if the Output Current is close to 0 than that die isn't hashing right? Also on this Jupiter I see a ton of these: "[time stamp] KnC: accepted by FPGA 1-21 works, but only 0 submitted"

I've tried .95, .96. .96.1 and .97 and .96 gives me the best performance so far, but at these voltages/temps. Also I did press gently on the copper bars of the heatsink and that seemed to have brought a couple die Output Current on par with the rest, but as you can see there is still a couple that are around 0. After downgrading to .96 this most recent time CGMiner restarts every 20 minutes, but the hash rate starts around 500-550 and drops to 350-380 before CGMiner restarts. You can see the stats here on Jupiter 3: http://54.243.221.120/

I've asked KnC for an RMA, but I'm hoping I can avoid that if there is a fix for this.

Any ideas?

YOU NAILED IT
I have a sat that has been acting funny, and had the temp phenomena...
I pressed on the copper bars, and instantly saw the jump.
I placed a wedge at the top of the heatsink to add a tad more pressure on the asic
it now works great.
Thank you for sharing that.....seriously!

So your saying a little more pressure on the ASIC helped? then maybe grinding a little off the spacers to help get it tighter might help as well. Or i wonder if taking a heat gun to the asic to heat it up would help. Though i sure wouldn't try it. I use to buy broken xbox 360's. And fix them with a heat gun. Hack them so they can play backups then sell them. but with most of them all i had to do was take a heat gun and a little liquid flux and heat up the the gpu carefully. Then when i put them back together i would use screws and spacers to hold the heat sink on so i could get it tighter. And would never have a problem with them after that.

Phoenix1969

legendary

Activity: 938

Merit: 1000

LIR DEV

no, Im saying the pressure brought a die back to life, wasnt making good contact

btw... that machine looks to be the fastest one now...

KnCMiningOp

sr. member

Activity: 448

Merit: 250

Quote from: Phoenix1969 on October 26, 2013, 11:11:59 PM

Quote from: KnCMiningOp on October 26, 2013, 09:08:43 PM

Anyone know why the voltages on our 3rd Jupi are higher than on the first two? I believe that as a result of the voltage being higher the temps are also higher. Also it is my understanding that if the Output Current is close to 0 than that die isn't hashing right? Also on this Jupiter I see a ton of these: "[time stamp] KnC: accepted by FPGA 1-21 works, but only 0 submitted"

I've tried .95, .96. .96.1 and .97 and .96 gives me the best performance so far, but at these voltages/temps. Also I did press gently on the copper bars of the heatsink and that seemed to have brought a couple die Output Current on par with the rest, but as you can see there is still a couple that are around 0. After downgrading to .96 this most recent time CGMiner restarts every 20 minutes, but the hash rate starts around 500-550 and drops to 350-380 before CGMiner restarts. You can see the stats here on Jupiter 3: http://54.243.221.120/

I've asked KnC for an RMA, but I'm hoping I can avoid that if there is a fix for this.

Any ideas?

YOU NAILED IT
I have a sat that has been acting funny, and had the temp phenomena...
I pressed on the copper bars, and instantly saw the jump.
I placed a wedge at the top of the heatsink to add a tad more pressure on the asic
it now works great.
Thank you for sharing that.....seriously!

Sure, are you saying that by applying the constant pressure your temps go down?

Another issue: Now I can't SSH to Jupiter 1 and Web Gui isn't responding, but it is still hashing I confirmed via CGMiner and BTC Guild... Anyone know how to fix it with out rebooting? Jupi1 has been running around 554GH/s since day one and I don't want to reboot...

Phoenix1969

legendary

Activity: 938

Merit: 1000

LIR DEV

Quote from: KnCMiningOp on October 26, 2013, 09:08:43 PM

Anyone know why the voltages on our 3rd Jupi are higher than on the first two? I believe that as a result of the voltage being higher the temps are also higher. Also it is my understanding that if the Output Current is close to 0 than that die isn't hashing right? Also on this Jupiter I see a ton of these: "[time stamp] KnC: accepted by FPGA 1-21 works, but only 0 submitted"

I've tried .95, .96. .96.1 and .97 and .96 gives me the best performance so far, but at these voltages/temps. Also I did press gently on the copper bars of the heatsink and that seemed to have brought a couple die Output Current on par with the rest, but as you can see there is still a couple that are around 0. After downgrading to .96 this most recent time CGMiner restarts every 20 minutes, but the hash rate starts around 500-550 and drops to 350-380 before CGMiner restarts. You can see the stats here on Jupiter 3: http://54.243.221.120/

I've asked KnC for an RMA, but I'm hoping I can avoid that if there is a fix for this.

Any ideas?

YOU NAILED IT
I have a sat that has been acting funny, and had the temp phenomena...
I pressed on the copper bars, and instantly saw the jump.
I placed a wedge at the top of the heatsink to add a tad more pressure on the asic
it now works great.
Thank you for sharing that.....seriously!

isimme

member

Activity: 78

Merit: 10

Quote from: carlotech on October 26, 2013, 07:16:42 PM

what version of bertmod working on .95 firmware?

best regards.

bertmod_0_2_1_for_knc_0_94
works for 0.95
you have to refresh your browser a few times
before it will display your stats correctly(give about 30 sec between each refresh)

KnCMiningOp

sr. member

Activity: 448

Merit: 250

Quote from: eiliant on October 26, 2013, 10:07:36 PM

Could you delete the photos from the quote? It takes up unnecessary space for everyone.

Done.

eiliant

member

Activity: 84

Merit: 10

Could you delete the photos from the quote? It takes up unnecessary space for everyone.

KnCMiningOp

sr. member

Activity: 448

Merit: 250

Quote from: 1l1l11ll1l on October 26, 2013, 09:57:12 PM

Quote from: KnCMiningOp on October 26, 2013, 09:08:43 PM

Anyone know why the voltages on our 3rd Jupi are higher than on the first two? I believe that as a result of the voltage being higher the temps are also higher. Also it is my understanding that if the Output Current is close to 0 than that die isn't hashing right? Also on this Jupiter I see a ton of these: "[time stamp] KnC: accepted by FPGA 1-21 works, but only 0 submitted"

I've tried .95, .96. .96.1 and .97 and .96 gives me the best performance so far, but at these voltages/temps. Also I did press gently on the copper bars of the heatsink and that seemed to have brought a couple die Output Current on par with the rest, but as you can see there is still a couple that are around 0. After downgrading to .96 this most recent time CGMiner restarts every 20 minutes, but the hash rate starts around 500-550 and drops to 350-380 before CGMiner restarts. You can see the stats here on Jupiter 3: http://54.243.221.120/

I've asked KnC for an RMA, but I'm hoping I can avoid that if there is a fix for this.

Any ideas?

Your input voltage seems really low, have you tried a different PSU?

No I haven't, but I did plug that PSU into a PSU tester and the voltages are identical to one of the other PSU that is powering Jupiter 2. If the voltage is lower why is the Output current higher than my 2 other Jupiters?

1l1l11ll1l

legendary

Activity: 1274

Merit: 1000

Quote from: KnCMiningOp on October 26, 2013, 09:08:43 PM

Anyone know why the voltages on our 3rd Jupi are higher than on the first two? I believe that as a result of the voltage being higher the temps are also higher. Also it is my understanding that if the Output Current is close to 0 than that die isn't hashing right? Also on this Jupiter I see a ton of these: "[time stamp] KnC: accepted by FPGA 1-21 works, but only 0 submitted"

I've tried .95, .96. .96.1 and .97 and .96 gives me the best performance so far, but at these voltages/temps. Also I did press gently on the copper bars of the heatsink and that seemed to have brought a couple die Output Current on par with the rest, but as you can see there is still a couple that are around 0. After downgrading to .96 this most recent time CGMiner restarts every 20 minutes, but the hash rate starts around 500-550 and drops to 350-380 before CGMiner restarts. You can see the stats here on Jupiter 3: http://54.243.221.120/

I've asked KnC for an RMA, but I'm hoping I can avoid that if there is a fix for this.

Any ideas?

Your input voltage seems really low, have you tried a different PSU?

bitly

newbie

Activity: 53

Merit: 0

Just set up my Jupiter and it's hashing at ~535 GH/s.

I'm pretty happy that I finally got it working, but at the same time, figured that I probably won't be able to make my money back with the current difficulty...

KnCMiningOp

sr. member

Activity: 448

Merit: 250

Anyone know why the voltages on our 3rd Jupi are higher than on the first two? I believe that as a result of the voltage being higher the temps are also higher. Also it is my understanding that if the Output Current is close to 0 than that die isn't hashing right? Also on this Jupiter I see a ton of these: "[time stamp] KnC: accepted by FPGA 1-21 works, but only 0 submitted"

I've tried .95, .96. .96.1 and .97 and .96 gives me the best performance so far, but at these voltages/temps. Also I did press gently on the copper bars of the heatsink and that seemed to have brought a couple die Output Current on par with the rest, but as you can see there is still a couple that are around 0. After downgrading to .96 this most recent time CGMiner restarts every 20 minutes, but the hash rate starts around 500-550 and drops to 350-380 before CGMiner restarts. You can see the stats here on Jupiter 3: http://54.243.221.120/

I've asked KnC for an RMA, but I'm hoping I can avoid that if there is a fix for this.

Any ideas?

tolip_wen

sr. member

Activity: 386

Merit: 250

Quote from: xyzzy099 on October 26, 2013, 12:42:09 PM

-SNIP-

That being said, I don't think it's impossible that whatever defect it is that makes the bad chips bad could be something that reacts to temperature. I just don't think the phenomena is explained by temperature inversion.

+1

Some have reported that the PCB is bowed down in the middle.
If this is a result of heatsink overtightening, nevermind.
If this is due to the ASIC package expanding more than the PCB at reflow, after cooling there may warpage...
This could possibly produce the wide range of symptoms observed.

It might instead/also be a COE difference between on die materials in a marginal area of the die.

This might explain what some have reported, (warmer/cooler/pointed at the moon) ASICS doing better.

What would Occam's razor say?

EDITed to improve clarity (I hope)

carlotech

member

Activity: 92

Merit: 10

what version of bertmod working on .95 firmware?

best regards.

timmmers

sr. member

Activity: 1176

Merit: 265

Quote from: opentoe on October 26, 2013, 01:59:47 PM

Quote from: Phoenix1969 on October 26, 2013, 12:40:35 AM

yeah, ultimately, KNC will need to tell us what the recommended temps really are... good point.
Happy Mining bro

I asked for what the normal operating temps were weeks ago, and several times. Either they don't know or just ignoring me. KNC have been MIA for a while now and I wouldn't expect them just to come around and answer any of our questions or give support to their products like a normal company.

Thing is, that was what they said they were going to do, have a number of customers that they could support well.

opentoe

legendary

Activity: 1274

Merit: 1000

Personal text my ass....

Quote from: Vyper on October 26, 2013, 08:29:19 AM

Please help me over here:
https://bitcointalksearch.org/topic/knc-asic-red-light-318747
The red light is lit and stays lit on the beaglebone board.

Kind regards Vyper

Dude, no need to start a whole new thread then post a link to that thread in the KNC thread. Just post it in here. This is the KNC thread.

opentoe

legendary

Activity: 1274

Merit: 1000

Personal text my ass....

Quote from: Phoenix1969 on October 26, 2013, 12:40:35 AM

yeah, ultimately, KNC will need to tell us what the recommended temps really are... good point.
Happy Mining bro

I asked for what the normal operating temps were weeks ago, and several times. Either they don't know or just ignoring me. KNC have been MIA for a while now and I wouldn't expect them just to come around and answer any of our questions or give support to their products like a normal company.

xyzzy099

legendary

Activity: 1066

Merit: 1098

Quote from: Phoenix1969 on October 26, 2013, 01:36:22 PM

Quote from: xyzzy099 on October 26, 2013, 01:31:01 PM

Quote from: Phoenix1969 on October 26, 2013, 01:20:45 PM

Quote from: xyzzy099 on October 26, 2013, 01:16:15 PM

Quote from: Phoenix1969 on October 26, 2013, 01:12:44 PM

Payout que is like this...
set the threshold....
balance reaches threshold, enters que
que is 8-10 blocks long
end of que, you get paid everything you've earned to that point.
simple.

Wow, are you really getting queued 8-10 blocks back???

I don't think I have ever had more than 1 or two blocks delay on there.

I know there are plenty of circumstances where a fail-safe will kick in and stop payouts completely until Wizkid restarts it manually, and payout will get backed up then - but when he restarts it, he manually does the payout also, so you don't have to wait for the queue to clear.

it seems larger quantities take a bit longer..... but yes..it varies.. my payments over a btc take a day, while small ones are within 4 -5 blocks... I said 8 to save any frustration...

If there is more than 25BTC worth of payout due, the payouts are done in order of how old the balance is. If your payout is set too low, where you get paid very frequently, you will get queued when there is more than one block's worth of BTC to be paid out. If you set it to get 1 or two payouts a day, you should not find yourself 8-10 blocks back.

That sounds legit, but it's just not how I've been getting payouts from eligius...
I have it set to trigger que at .03, which is well below what I earn per round.
With that said, I re-enter que after every payment, yet I get paid 1 or 2 times a day.
Just how it is....don't know the specifics why.

That's why you are qetting queued.

I have 1/3 your hash power (300GH/s) and I have mine set to pay at 0.25BTC. That way I hit the payout threshold roughly twice a day, and I don't get queued. I guess the end effect is the same though, either way. You have to wait on the queue, and I have to wait on my balance to hit the threshold.

Phoenix1969

legendary

Activity: 938

Merit: 1000

LIR DEV

Quote from: xyzzy099 on October 26, 2013, 01:31:01 PM

Quote from: Phoenix1969 on October 26, 2013, 01:20:45 PM

Quote from: xyzzy099 on October 26, 2013, 01:16:15 PM

Quote from: Phoenix1969 on October 26, 2013, 01:12:44 PM

Payout que is like this...
set the threshold....
balance reaches threshold, enters que
que is 8-10 blocks long
end of que, you get paid everything you've earned to that point.
simple.

Wow, are you really getting queued 8-10 blocks back???

I don't think I have ever had more than 1 or two blocks delay on there.

I know there are plenty of circumstances where a fail-safe will kick in and stop payouts completely until Wizkid restarts it manually, and payout will get backed up then - but when he restarts it, he manually does the payout also, so you don't have to wait for the queue to clear.

it seems larger quantities take a bit longer..... but yes..it varies.. my payments over a btc take a day, while small ones are within 4 -5 blocks... I said 8 to save any frustration...

If there is more than 25BTC worth of payout due, the payouts are done in order of how old the balance is. If your payout is set too low, where you get paid very frequently, you will get queued when there is more than one block's worth of BTC to be paid out. If you set it to get 1 or two payouts a day, you should not find yourself 8-10 blocks back.

That sounds legit, but it's just not how I've been getting payouts from eligius...
I have it set to trigger que at .03, which is well below what I earn per round.
With that said, I re-enter que after every payment, yet I get paid 1 or 2 times a day.
Just how it is....don't know the specifics why.
It probably just takes that long to get to the last payout met before it entered the que

BTW... 3 sats so far... 15+BTC, and 45 NMC...

Topic: Swedish ASIC miner company kncminer.com - page 1209. (Read 3049524 times)