Swedish ASIC miner company kncminer.com

[Searing]

Almost wishing i had a bad board to play with.  Mine are running so so...  once there are warm they error rates drop to about 7-9%  and usually hashes about 550-554   SO i don't want to go and make things worse.   Though if i had a board that i was sending back to RMA  i couldn't help my self but try and heat it up .   tomorrow i might check and see if a little more pressure dose help mine at all..  if so i might just grind off a little on the spacers.

I found a few screws that attach the heat sink to the board to be a tad loose and was able to get get a half to a full twist on them.

I already know mine are down tight.  I took mine apart the first day i had it...  witch is why Im thinking about grinding a little off the spacer to make it a bit more tight.    but first ill test tomorrow if any more pressure helps.   Would go ahead and try tonight.  But i had a couple drinks earlier....    And well drinking and tinkering with a 7k machine don't go to well together in my books lol.    Wait tell im nice and fresh tomorrow.

Haha right! Even when I'm 100% sober I feel nervous doing anything, to apply pressure on the heat sink took me almost 1.5 days to do.

@Phoenix1969 Glad to hear you found a "bug"

mine is now running 565gh after 6 days up...5% error rate on .95...only thing I need is to find the thread on how to put in 2nd pool manually because not on .95....my core temps are 27c 31c 34c and 42c ...and I have once in a great while a core enable and unenable itself (maybe 1x ever 4hrs or so I'd guess)

so I HAVE TOUCHED NOTHING ..in fact I walk by the beastie and I look downward and away less it get p/o'd at me and make it go CLUNK!

I will however have to look at the screws above to see if they are tight the next time it is powered off of which I plan for it to be NEVER if possible

anyway if anyone trips over the trick to get a 2nd pool in on .95 ..still looking for the link..pm me or post it here....if power goes out I have lots to check out
but until then GO BABY GO!

off to check the unit in the bsmt.....(must avert eyes...i'm not worthy)

Searing

[1714814258]

1714814258

[1714814258]

1714814258

[Phoenix1969]

nice...Id be scared to touch it too, thats great!
on the 2nd pool, I think you can just use putty to do it in cgminer, just remember to save to /config/cgminer.conf, and not the root/default directory. your default pool is pool 0, the backup is 1...

BTW... error rates, 1%, 3%, 3%. wow.

[sickpig]

nice...Id be scared to touch it too, thats great!
on the 2nd pool, I think you can just use putty to do it in cgminer, just remember to save to /config/cgminer.conf, and not the root/default directory. your default pool is pool 0, the backup is 1...

BTW... error rates, 1%, 3%, 3%. wow.

Dumb questions:

1) Did you apply all those hw tricks withe the machine switched on?
2) a part from makes VRM clicks and check the heatsink screws thre's something else to do?

Unreleated to this just wanna share that BB sys load lowered to 1.5 from 1.9 when using bfgminer instead of cgminer (bfgminer compiled fro source doeas not include  dynamic cores enable/disable mechanism committed on the 25)

[ElGabo]

Hi

Now after 24 hours my jup is going with 552ghs rock solid but I figured out something interesting.

If all my vrm output above 0.7 V the pool shows great 550-560Ghs, if just only 1 or 2 vrm output goes down under 0.7 V (for example 0.687V) the pool hashrate dorps down to 510-540. In cgminer still 552.

Any ideas?

[FeedbackLoop]

Hi

Now after 24 hours my jup is going with 552ghs rock solid but I figured out something interesting.

If all my vrm output above 0.7 V the pool shows great 550-560Ghs, if just only 1 or 2 vrm output goes down under 0.7 V (for example 0.687V) the pool hashrate dorps down to 510-540. In cgminer still 552.

Any ideas?

KNC's cgminer includes hardware errors in the reported hashing rate. Something not done by the other versions of cgminer. From the maker:
https://bitcointalk.org/index.php?topic=319533.0

Please compute your hashing rate from cgminer using:
2^32 * Accepted / Elapsed


What are your temps and HW in both circumstances?

[ElGabo]

Hi Feedbackloop!

Here is a picture. Everything is just the same. Only the vrm output changing nothing else. No hashrate drop, nothing. Ecerything is just fine...

[ElGabo]

Hi

Now after 24 hours my jup is going with 552ghs rock solid but I figured out something interesting.

If all my vrm output above 0.7 V the pool shows great 550-560Ghs, if just only 1 or 2 vrm output goes down under 0.7 V (for example 0.687V) the pool hashrate dorps down to 510-540. In cgminer still 552.

Any ideas?

KNC's cgminer includes hardware errors in the reported hashing rate. Something not done by the other versions of cgminer. From the maker:
https://bitcointalk.org/index.php?topic=319533.0

Please compute your hashing rate from cgminer using:
2^32 * Accepted / Elapsed


What are your temps and HW in both circumstances?

Now I understand I think.

IF Hw counts in the hasrate, when the output drops a bit, maybe the hw rate goes up a bit and the real hasrate goes down.

It would be great if we could control the output of the DC-s.... (And maybe the clock)

[edgar]

exactly

[Searing]

Hi

Now after 24 hours my jup is going with 552ghs rock solid but I figured out something interesting.

If all my vrm output above 0.7 V the pool shows great 550-560Ghs, if just only 1 or 2 vrm output goes down under 0.7 V (for example 0.687V) the pool hashrate dorps down to 510-540. In cgminer still 552.

Any ideas?

KNC's cgminer includes hardware errors in the reported hashing rate. Something not done by the other versions of cgminer. From the maker:
https://bitcointalk.org/index.php?topic=319533.0

Please compute your hashing rate from cgminer using:
2^32 * Accepted / Elapsed


What are your temps and HW in both circumstances?

using above formula mine is 7.15% I'm running 565ss 555ave on .95 temps 27c 40.5c and two at 33.5c so a bit higher then the 5.4% I got just using HW values

Searing

[jelin1984]

Which is these formula?

What I must write at cgminer at Jupiter to have it solid run??

[tunctioncloud]

Hopefully KNC latest drivers are always best.

Because it is hard to follow this discussion to have the best hashrate possible

[timmmers]

Hopefully KNC latest drivers are always best.

Because it is hard to follow this discussion to have the best hashrate possible

Have been for me. Not had a single problem yet .97 from the day after it was released (just to make sure if the latest version wasn't homicidal).
I don't get this .97 doesn't work stuff, how can that be the firmware for one rig and not for others?

[FeedbackLoop]

Which is these formula?

These formulae were posted by Kano in a KNC thread, they merely allow you to compute your hashrate properly:

https://bitcointalk.org/index.php?topic=306969.msg3309728#msg3309728

ElGabo has:

11213824*2^32/(25*3600+2.5*60)
   5.3425410e+11
534 GH/s in accepted shares.

420356*2^32/(25*3600+2.5*60)
   2.0026792e+10
20 GH/s in hardware errors for less than 5% HW

72191.*2^32/(25.*3600.+2.5*60)
   3.4393565e+09
3.4 GH/s in rejected shares (538 GH/s full hashrate).


Which are outstanding values compared with what many people here, including me, have. Unfortunately it's hard to figure out what factors affect the real hashrates as most people do not post the source of their numbers and some others, like edgar, will prefer to cover the thread in flame instead of making some effort to search the threads, understand and cooperate.

My other question was if temperatures affect the output in your machine ElGabo, and if that affects HW (positively or negatively) but your HW is so low that your machine doesn't seem good to test this. Unless when the temperature is high (seeing that your screenshot shows very low temperatures) your hardware error rate goes much higher  (which would be the opposite of what people including Phoenix and DigginDeep just above seem to be seeing). Then we could see if that VRM output correlates. Is that the case?


tunctioncloud: 0.97 is horrible for my machine and many others.

[timmmers]

Which is these formula?

These formulae were posted by Kano in a KNC thread, they merely allow you to compute your hashrate properly:

https://bitcointalk.org/index.php?topic=306969.msg3309728#msg3309728

ElGabo has:

11213824*2^32/(25*3600+2.5*60)
   5.3425410e+11
534 GH/s in accepted shares.

420356*2^32/(25*3600+2.5*60)
   2.0026792e+10
20 GH/s in hardware errors for less than 5% HW

72191.*2^32/(25.*3600.+2.5*60)
   3.4393565e+09
3.4 GH/s in rejected shares (538 GH/s full hashrate).


Which are outstanding values compared with what many people here, including me, have. Unfortunately it's hard to figure out what factors affect the real hashrates as most people do not post the source of their numbers and some others, like edgar, will prefer to cover the thread in flame instead of making some effort to search the threads, understand and cooperate.

My other question was if temperatures affect the output in your machine ElGabo, and if that affects HW (positively or negatively) but your HW is so low that your machine doesn't seem good to test this. Unless when the temperature is high (seeing that your screenshot shows very low temperatures) your hardware error rate goes much higher  (which would be the opposite of what people including Phoenix and DigginDeep just above seem to be seeing). Then we could see if that VRM output correlates. Is that the case?


tunctioncloud: 0.97 is horrible for my machine and many others.

It's s shame that there seems to be such a variance in build quality between rigs, things like slack screws make me think whoever assembled these things probably hadn't much experience. The temperature may just be causing better contact and compensating for these things and on two well made rigs may not have any effect at all. I've been lucky it seems, but if I had one of the rigs with problems I'd have it to bits and rebuild it and make sure things like thermal paste and contacts were all tickety boo. Like they should have when assembling them , which is not racket science really is it?

[fubly]

TEST_ASIC_BOARD_FOUND=FAIL

type only in your console when logged in:

cat /././var/log/initc.log


root@Jupiter-fuckoff:/var/volatile/log# cat initc.log
Return code = -11
TEST_READ_BBB_SN=OK
TEST_I2C_CONNECT=OK
TEST_LM75_TEST=OK
TEST_TPS65217_TEST=OK
TEST_TPS65217_CONFIG=OK
TEST_FPGA_CONFIG=OK
TEST_FPGA_TEST=OK
TEST_ONBOARD_EEPROM_EMPTY=OK
TEST_GET_SERIAL_NUMBER=OK
TEST_ONBOARD_EEPROM_WRITE=OK
TEST_MMC_REFLASH=OK
TEST_I2C_MUX_PROBE=OK
  TEST_ASIC_BOARD_FOUND=FAIL  
TEST_READ_IOBOARD_SN=OK
TEST_IOBOARD_SN_GOOD=OK
TEST_GET_CGMINER_CONFIG=OK
TEST_WRITE_CGMINER_CONFIG=OK

what can i do?

[Puppet]

It's s shame that there seems to be such a variance in build quality between rigs, things like slack screws make me think whoever assembled these things probably hadn't much experience.

I doubt its the assembly. Its almost certainly because they chose not to test and bin the chips. All wafers have defunct chips and chips of varying quality, thats a given. Almost all asic manufacturers test their chips on the wafer, and then again once they are packaged, tossing out the broken ones and binning the others according to how well they perform (power consumption, clock speed, if applicable, number of working cores) and use different bins for different products (think various AMD or Intel chips with different clockspeeds), or combine good and not so good chips to get a more predictable end product (afaik, thats what BFL does).

KnC seems to solder all their chips on a module, and they will do a final assembly functional test, but whether you get 4 excellent or 4 mediocre chips or a mix of both is just a matter of luck.

[jelin1984]

11213824*2^32/(25*3600+2.5*60)
   5.3425410e+11
534 GH/s in accepted shares.

420356*2^32/(25*3600+2.5*60)
   2.0026792e+10
20 GH/s in hardware errors for less than 5% HW

72191.*2^32/(25.*3600.+2.5*60)
   3.4393565e+09
3.4 GH/s in rejected shares (538 GH/s full hashrate).



Where I must write that ??

[crumbs]

It's s shame that there seems to be such a variance in build quality between rigs, things like slack screws make me think whoever assembled these things probably hadn't much experience.

I doubt its the assembly. Its almost certainly because they chose not to test and bin the chips. All wafers have defunct chips and chips of varying quality, thats a given. Almost all asic manufacturers test their chips on the wafer, and then again once they are packaged, tossing out the broken ones and binning the others according to how well they perform (power consumption, clock speed, if applicable, number of working cores) and use different bins for different products (think various AMD or Intel chips with different clockspeeds), or combine good and not so good chips to get a more predictable end product (afaik, thats what BFL does).

KnC seems to solder all their chips on a module, and they will do a final assembly functional test, but whether you get 4 excellent or 4 mediocre chips or a mix of both is just a matter of luck.

Sort-a like buying any CPU/GPU -- some take clock better than others, no cause for complaints as long as all manage the datasheet specs.
If it becomes profitable in the future, KNC will sell you "Deluxe 1337 Black Edition," with 100% good cores guaranteed

[FiatKiller]

Hotter is better! I had a supplemental house fan & turned it off. ASICs fans are unplugged. Only
left the tilted case fans on. FW 9.7 and Enablecores afterwards. No Bertmod yet. HW error rate
was 19% before. Hashrate was mid-250s before. WU was 3900ish before.
Considering putting the case back on also...
Edit: power is now only 298 watts. I just removed the fans entirely and put a long piece of closed cell foam
across the tops of both heatsinks. Will see what happens.
Credit goes to user FoolPartedWithMoney for pointing-out first that more heat may be the key!

[timmmers]

It's s shame that there seems to be such a variance in build quality between rigs, things like slack screws make me think whoever assembled these things probably hadn't much experience.

I doubt its the assembly. Its almost certainly because they chose not to test and bin the chips. All wafers have defunct chips and chips of varying quality, thats a given. Almost all asic manufacturers test their chips on the wafer, and then again once they are packaged, tossing out the broken ones and binning the others according to how well they perform (power consumption, clock speed, if applicable, number of working cores) and use different bins for different products (think various AMD or Intel chips with different clockspeeds), or combine good and not so good chips to get a more predictable end product (afaik, thats what BFL does).

KnC seems to solder all their chips on a module, and they will do a final assembly functional test, but whether you get 4 excellent or 4 mediocre chips or a mix of both is just a matter of luck.

Sort-a like buying any CPU/GPU -- some take clock better than others, no cause for complaints as long as all manage the datasheet specs.
If it becomes profitable in the future, KNC will sell you "Deluxe 1337 Black Edition," with 100% good cores guaranteed

Not what I meant really, the temperatures seem to have an effect on some machines but not others, they seem to all have a top end of about 140Gh per module but some take some help getting that.
True enough they rushed and didn't test the chips, but I don't think they assembled some rigs at all well at a basic level, and that's only what we can see. Leaving the sucking plastic on them doesn't show much attention to detail, so if they didn't do that simple thing what's the odds on thermal paste being well done? A few bent boards caused by the assembly or other minor defects could be why the heat makes such a change for some as they expand maybe I was thinking.

"Spoling the sheep for a hapeth of tar" my granny would say.