Swedish ASIC miner company kncminer.com

[soy]

I wonder about modules which lost fans in transit.  I wonder if they somehow saw a greater shock and as a result will have a higher disabled core rate.  If so that might indicate shock damage at the Ball Grid Array where the rubber meets the road, the ASIC meets the PCB.

My Mercury, with upgraded firmware to 0.96 and having ran enablecores.bin, ran all night on Slush's, never reached 100GH/s, only registered 75-77GH/s on Slush.  Can't see the cores without BertMod but the last time I did on 0.95 the cores were 0/75.0%, 1/95.8%, 2/89.6%, 3/91.7%.  Plenty of cooling (34.5°C).  Cgminer:  KnC 0:| 99.02G/99.10Gh/s | A:883542 R:5697 HW:370264 WU:1505.5/m which means HW is 41.9%.

Something of a disappointment after reading most Jupiters were getting well over 500GH/s.  And to think, the Merc's cost the customer more per GH/s than Saturns or Jupiters.

If the 1 sticker isn't wrong then perhaps a shock in transit damaged the BGA as the fan was off the one module.

Just tried firmware 0.90 with enablecores.bin

KnC 0: | 168.0G/109.9Gh/s | A:5014 R:257 HW:774 WU:1985.0/m

Previously the best WU: I could get were just above 1500.

It's only been up a few minutes but that's the first I've seen the average over 100!

a minute later...   KnC 0:   | 168.3G/121.1Gh/s | A:8254 R:500 HW:1048 WU:2060.0/m

KnC 0:| 161.3G/129.0Gh/s | A:23158 R:1067 HW:2166 WU:2099.0/m

root@Mercury-3DF:~# uptime
 17:46:50 up 13 min,  load average: 1.99, 1.84, 1.12

Smiley face isn't big enough for this hashrate, 129.0GH/s
------------------
root@Mercury-3DF:~# uptime
17:59:24 up 25 min,  load average: 1.99, 1.98, 1.61
KnC 0: | 143.9G/131.6Gh/s | A:49321 R:2525 HW:4234 WU:2130.3/m
-------------------

So, the load on the BBB?  I've heard mention those figures should be <1.0.

 KnC 0: | 154.0G/133.7Gh/s | A:78562 R:4469 HW:6893 WU:2150.3/m  Slush: 82625.522

[Phoenix1969]

Cool, that sounds easy...
is it made to run with 0.90, or can I try it with 0.96?

[squall1066]

Sorry for the noob question, Everyone in the crypto world assumes everyone can program 

I am getting my first KNC unit soon, I am not used to IP mining, Is it really as "plug and play" as I assume?

As far as I can tell, I look up the IP of the unit via my router,  put this in my browser, and click on mining and put in my pool details directly, and i'm done?

If I can see the stats via the IP address and the pool, Why are people configuring it to show on CGminer.

[Paladin69]

looks ok... but i'd use 0.96 asap
looks like it wasnt running for long?
takes about 15 mins to come up to par

yeah I heard that 96 does not bring up bad cores...but again ...was gonna wait see how it shakes out...I mean it is doing 535gh as ave so and yeah it was down I turned it off with ssh trgettig that going prob only up 1hr...i'll upgrade eventually but imho on these knc upgrades you prob sholdd like to every other one...the first users of such seem to get creamed imho

prob i'll see .97 come out...wait a bit then slip up to that (im still tramatized by how my unit arrived from DHL the fiends...I thought I had a block erruptor at best)

Searing

the cores enable/disable fine in 0.96...

WU theory.....peeps keep sayin' WU is most important...more is better.. I see opposite
as they fluctuate, wu's also change...
fact is...the one with the LEAST WU's is fastest always on mine

***I also wonder if trying slot 6 on those two boards may help?
is anyone experiencing different speeds changing slot plugins on the controller board?


edit:   0.96 also adds features to the gui

thanks I always appreciate your advice my speed is going past 550gh now so I'm still gonna sit on my hands...i'll eventually upgrade to .96 or beyond..but hey i'd like to get thru 1 full day w/o mucking something up which is usually the case....

what i'm really interested is in what the tweaks will be when the bfgminer version comes out

anyway has been quite the last couple days....looking at the hash rate and diff seems I made the right choice on getting rid of my 2nd unit Saturn ..because it would ship after the 16th the 520x..they allowed a full refund which I promptly took.....prob would not have gotten it till end of month at best w/shipping and of course all that low priced stuff nov 15th going out the door ...same tune next month....(arg shipping shudder feel the need to fly to Sweden and get next unit..the horror of my destroyed pkg by dhl)..anyway....already burnt by bfl and bailed out by the 150 some extra free GH from kncminer....breaking even is looking good maybe a bit better fyi....(still no units from bfl april order they do 1 day of order per day at current rate sometime in December.....the stuff is doorstops)

anyway knc has been very good on my Saturn return chased it down from processing and everything..i may just sit stuff out till feb/march ...by that time it will probably be all shares in cloudhashing....who could keep up at this rate with the purchase of miners vs delivery vs holding the bag on risk?.....interesting times

Searing

Cloudhashing would never see ROI for himself so therefore it would never be a good deal either as he will try to sell you at a much higher $ per GH.  All cloud mining companies will do this.

I would watch the recent price increase and have funds ready at an exchange.  I think there will be a correction.  Everyone should get refunds and consider this.  You will get yourself far more BTC and be much happier in 2-3 years from now.

[soy]

Cool, that sounds easy...
is it made to run with 0.90, or can I try it with 0.96?

I was getting high 90'sGH/s on 0.95 then went to 0.96 and ran enablecores.bin and overnight only got to 99GH/s.

Of course it could have been something less clear.  Since I'm using a cheap 12vdc switching supply along with a BeagleBone barrel connector power supply patched to a 4 pin molex that also had the 12v from the other supply, I had shut down for a short time to try an old computer switching supply only to the 4 pin molex - this because the voltage from the BBB wall wart was 5.18v or so and the old supply put out 5.02v and the BBB needs cooling and I thought it would need less cooling with 5.02v instead of 5.18v.  It didn't work out and wouldn't bring up a web page.  So I went back to my earlier configuration and went to the 0.90 and enablecores.bin

Earlier today I tried running for an hour at 12.5v to the PCIE and then an hour at 10.0v to the PCIE.  With the 0.96 and no BertMod I could only tell there was not much difference, it stayed around 99.xGH/s avg on cgminer never reaching 100GH/s avg and with 50% HW error rate.  WUs dropped at 10.0v from 1508 on 12.5v down to 1500 on 10.0v.

WUs are stable 2151 then up to 2154 then back to 2151 @ 133.6GH/s avg.  Slush: 84651.455

The high rejects seem to increment up with a Duplicate Share notice.  I believe that was corrected in a later firmware but I'm sticking with what I have now for now.

[Phoenix1969]

you were correct in assuming the enablecores.bin does not work with 0.96....it runs, but no results or difference......but

I did it your way....0.90...and..

it worked.
my slowest saturn was 255, now 280...

trying the others now...

edit...lt Did NOT help Saturn #2...  slowed it from 265ish to 255ish....
sat 3 is ok at 276 all the time, so ill leave it be...  but coolz it worked on the slowest one, its still saying 277 avg, when it was always 255 before... with 1000 more WU's

[FiatKiller]

Cool, that sounds easy...
is it made to run with 0.90, or can I try it with 0.96?

I ran the enablecores thru the upgrade screen without disconnecting anything.

The basic concept of WU is that you can hash all you want, but if you don't find anything shareworthy then it is meaningless. Imagine a gerbil in a wheel. lol

[soy]

Cool, that sounds easy...
is it made to run with 0.90, or can I try it with 0.96?

I ran the enablecores thru the upgrade screen without disconnecting anything.

The basic concept of WU is that you can hash all you want, but if you don't find anything shareworthy then it is meaningless. Imagine a gerbil in a wheel. lol

Ah, those of us with FAH experience have fond memories of WUs.

[Phoenix1969]

yeah, no unplugging was necessary
it helped the slowest saturn...by about 22 gh/s and 1000 WU's, but not the others

[Wesly]

Imagine a world where end of september means end of september and where your second order is expected to ship in the first week of october means it will be delivered in the first week of october instead of still being in progress....
Brave new world that would be.

Imagine a world where 250 Giga-Hash means you receive 250 Giga-Hash and where 1.6 Watts per Gigahash means 2 watts per Giga-Hash at the wall instead of 500 Giga-Hash and 1.1 Watts/Giga-Hash at the wall....

What a Brave New World we live in!

[soy]

I wonder about modules which lost fans in transit.  I wonder if they somehow saw a greater shock and as a result will have a higher disabled core rate.  If so that might indicate shock damage at the Ball Grid Array where the rubber meets the road, the ASIC meets the PCB.

My Mercury, with upgraded firmware to 0.96 and having ran enablecores.bin, ran all night on Slush's, never reached 100GH/s, only registered 75-77GH/s on Slush.  Can't see the cores without BertMod but the last time I did on 0.95 the cores were 0/75.0%, 1/95.8%, 2/89.6%, 3/91.7%.  Plenty of cooling (34.5°C).  Cgminer:  KnC 0:| 99.02G/99.10Gh/s | A:883542 R:5697 HW:370264 WU:1505.5/m which means HW is 41.9%.

Something of a disappointment after reading most Jupiters were getting well over 500GH/s.  And to think, the Merc's cost the customer more per GH/s than Saturns or Jupiters.

If the 1 sticker isn't wrong then perhaps a shock in transit damaged the BGA as the fan was off the one module.

Just tried firmware 0.90 with enablecores.bin

KnC 0: | 168.0G/109.9Gh/s | A:5014 R:257 HW:774 WU:1985.0/m

Previously the best WU: I could get were just above 1500.

It's only been up a few minutes but that's the first I've seen the average over 100!

a minute later...   KnC 0:   | 168.3G/121.1Gh/s | A:8254 R:500 HW:1048 WU:2060.0/m

KnC 0:| 161.3G/129.0Gh/s | A:23158 R:1067 HW:2166 WU:2099.0/m

root@Mercury-3DF:~# uptime
 17:46:50 up 13 min,  load average: 1.99, 1.84, 1.12

Smiley face isn't big enough for this hashrate, 129.0GH/s
------------------
root@Mercury-3DF:~# uptime
17:59:24 up 25 min,  load average: 1.99, 1.98, 1.61
KnC 0: | 143.9G/131.6Gh/s | A:49321 R:2525 HW:4234 WU:2130.3/m
-------------------

So, the load on the BBB?  I've heard mention those figures should be <1.0.

 KnC 0: | 154.0G/133.7Gh/s | A:78562 R:4469 HW:6893 WU:2150.3/m  Slush: 82625.522

Good news, Slush now has the Merc up to 128268.002MH/s!  and climbing.....

 KnC 0:| 141.4G/133.7Gh/s | A:157213 R:9815 HW:14340 WU:2160.9/m

Also, I just noticed that my power consumption at the wall, which had been up to 160 watts @99GH/s, is now up to 271watts @133.9GH/s.

But then I'm using a cheap switching supply the efficiency of which isn't great.  When I would read 140 watts at the wall I'd see 94 watts on BertMod.  Then again I have a 120VAC fan plugged into the power strip and 2 additional 12v fans on the supply all of which is (all of which are?) being read at the wall by kill-a-watt.

[adrd]

Sorry for the noob question, Everyone in the crypto world assumes everyone can program 

I am getting my first KNC unit soon, I am not used to IP mining, Is it really as "plug and play" as I assume?

As far as I can tell, I look up the IP of the unit via my router,  put this in my browser, and click on mining and put in my pool details directly, and i'm done?

If I can see the stats via the IP address and the pool, Why are people configuring it to show on CGminer.

If you filled in your pool info on KNCsite it will be already filled on miner, so if you plug and start it, it will start mining. On web interface (you run it just like router options) you can change your pool info and on .96 you can see some stats + can add backup pool. People configure SSH to look at CGminer for more stats.

[Bitcoinorama]

Hey Bitcoinrama or KnC will we be able to upgrade the cgminer in the future?

In Berlin, will ask when next in Stkhlm.

[joeventura]

I wonder how my miner is enjoying Ohio, now that it has spent 2 days there.

Maybe it is seeing the sights and visiting a few museums

[FiatKiller]

Sorry for the noob question, Everyone in the crypto world assumes everyone can program 

I am getting my first KNC unit soon, I am not used to IP mining, Is it really as "plug and play" as I assume?

As far as I can tell, I look up the IP of the unit via my router,  put this in my browser, and click on mining and put in my pool details directly, and i'm done?

If I can see the stats via the IP address and the pool, Why are people configuring it to show on CGminer.

If you filled in your pool info on KNCsite it will be already filled on miner, so if you plug and start it, it will start mining. On web interface (you run it just like router options) you can change your pool info and on .96 you can see some stats + can add backup pool. People configure SSH to look at CGminer for more stats.

when you add a pool is it failover only?  or shared?

[soy]

BertMod 0.1 for 0.93 works well with firmware 0.90 and shows the Merc using 183 watts @ MHS av=134461.07 although  Slush now has the Merc at 143489.394MH/s.

[CanaryInTheMine]

I wonder how my miner is enjoying Ohio, now that it has spent 2 days there.

Maybe it is seeing the sights and visiting a few museums

did you call DHL?

[Tigggger]

when you add a pool is it failover only?  or shared?

It's failover, if you want one of the other options you can change it through cgminer.

[Phoenix1969]

BertMod 0.1 for 0.93 works well with firmware 0.90 and shows the Merc using 183 watts @ MHS av=134461.07 although  Slush now has the Merc at 143489.394MH/s.

sounds sweet soy..
the enablecore tweak is on 2 of 3 miners now, on 0.90 & the tweak
 the 3rd gets severe errors with 0.90, but it was the fastest one at 275 on 9.6, so there it stays.
the other two seem to be happily hashing at 275... so all 3 now at 275 is cool!

you have to power cycle the machine after applying the .bin file tho.

[DPoS]

Both running .96
One has a dead & a weak die

good miner:





bad miner: