Swedish ASIC miner company kncminer.com

[sickpig]

I've just created a kncminer branch on my github and have imported their most current code and built my first binary for this. It is not a full firmware and the only thing users may note is the hashrate won't lie with this one, as it won't count hardware errors as hashrate. Also my hardware error count is significantly lower with this on the Saturn dev machine I was sent.

Here's a direct link to the binary:
http://ck.kolivas.org/apps/cgminer/kncminer/cgminer

You'll have to ssh into the kncminer and copy and use that file directly. Hopefully the libraries all match between my dev environment and the default kncminer operating system which means the binary should just work if you run it like on any other OS.

Any guidance for those of us who like to compile our own software on building for ARM?  Are you building on-device or cross compiling on your x86?  I've not built your project before, but I see you've got the kncminer branch in github.  Thanks!

those are instructions to compile bfgminer from source:

http://codepad.org/QKSeO5zh

basically it explains how to add a few repos from which download pre-compiled stuff (library/tools/dev pakg etc etc), hopefully it could help to build cgminer using directly your miner without the need to cross compile.

[-ck]

@ckolivas

I am trying your 3.6.6 build on my problem jupiter (which has been downgraded back to 0.95 after worse performance on .96, .961, .97)

I notice the same flushwork hashrate drop with your build on 0.95 and was wondering if only fw 0.97 will fix that issue ?

thanks

Flush speed is fpga firmware related. I've done what I can to minimise software interference but the firmware is the key there.

good to know.

Unluckily I'm not able to connect remotely to my miner at the moment, hence I can't test "orginal" cgminer. As soon as I re-gain access to the machine I will let you know.

In the meantime could some one share the sys load avg while running ckolivas' cgminer?

Withe the KnC version I got something aroung 1.92-1.98 all the time. Using bfgminer sys load lower to something like 1.48-1.52. it would be handy if the same happen with this brand new cgminer.

Top output while it's running:

Code:

Mem: 144880K used, 365692K free, 0K shrd, 3840K buff, 122056K cached
CPU:   2% usr   4% sys   0% nic  93% idle   0% io   0% irq   0% sirq
Load average: 1.93 1.97 2.07 1/77 25802
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
 8411  6829 root     S     120m  24%   2% ./cgminer -c config/cgminer.conf
   58     2 root     DW       0   0%   1% [spi1]
 6828  6827 root     S     2748   1%   0% {screen} SCREEN

cat /proc/loadavg
2.02 1.99 2.08 1/77 26030

Whatever's using CPU, it is not cgminer at <=2%

[sickpig]

@ckolivas

I am trying your 3.6.6 build on my problem jupiter (which has been downgraded back to 0.95 after worse performance on .96, .961, .97)

I notice the same flushwork hashrate drop with your build on 0.95 and was wondering if only fw 0.97 will fix that issue ?

thanks

Flush speed is fpga firmware related. I've done what I can to minimise software interference but the firmware is the key there.

good to know.

Unluckily I'm not able to connect remotely to my miner at the moment, hence I can't test "orginal" cgminer. As soon as I re-gain access to the machine I will let you know.

In the meantime could some one share the sys load avg while running ckolivas' cgminer?

Withe the KnC version I got something aroung 1.92-1.98 all the time. Using bfgminer sys load lower to something like 1.48-1.52. it would be handy if the same happen with this brand new cgminer.

Top output while it's running:

Code:

Mem: 144880K used, 365692K free, 0K shrd, 3840K buff, 122056K cached
CPU:   2% usr   4% sys   0% nic  93% idle   0% io   0% irq   0% sirq
Load average: 1.93 1.97 2.07 1/77 25802
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
 8411  6829 root     S     120m  24%   2% ./cgminer -c config/cgminer.conf
   58     2 root     DW       0   0%   1% [spi1]
 6828  6827 root     S     2748   1%   0% {screen} SCREEN

cat /proc/loadavg
2.02 1.99 2.08 1/77 26030

Whatever's using CPU, it is not cgminer at <=2%

Yeah it's not a matter of CPU time, since top output confute the theory for every version of cgminer/bfgminer I've tested so far. I rather think is something I/O related.

thanks for sharing!

[-ck]

Yeah it's not a matter of CPU time, since top output confute the theory for every version of cgminer/bfgminer I've tested so far. I rather think is something I/O related.

Agreed. I think it's probably the way the spi communication is accounted, yet it doesn't show up in top, and since I happen to have written a few load average meters over the years with the various kernel schedulers I wrote for linux, I know better than most how hard it is to know exactly how much CPU time is in use and where.

[sickpig]

Yeah it's not a matter of CPU time, since top output confute the theory for every version of cgminer/bfgminer I've tested so far. I rather think is something I/O related.

Agreed. I think it's probably the way the spi communication is accounted, yet it doesn't show up in top, and since I happen to have written a few load average meters over the years with the various kernel schedulers I wrote for linux, I know better than most how hard it is to know exactly how much CPU time is in use and where.

spi could be the hidden culprit here   time will tell especially when/if knc will release FGPA firmware source code.

On a related note as a long time BFS user I really appreciate the work you've done in the linux kernel

[demonmaestro]

So i was able to get ahold of them and this is what was said when i asked the status of my miner. It shows in progress. I was like okay well i had recived an email stating that it will ship thursday of last week. they said that that should never been sent via email however they will email me later on today once they find out the status of the factory today.

what kind of BS is that crap?

[Nemo1024]

Judging by this https://bitcointalk.org/index.php?topic=249065.0 , the latest hosted order that got deployed was 38xx for yuriygeorge on the 25th of October
The latest shipped order was 586x for DobZombie

My hosted order is 39xx still has "Paid" status.

I am now watching like a hawk if faetos and dunchy (400x and 421x) would report their hosted units as deployed.

If that happens, I'll be demanding refund.

[DigginDeep]

Though on a side note my hardware error rate is slowly creeping back up to 6.8 already.  Going to try and downgrade to 9.6.1 my self and see if its any better.

Also bear in mind that if the hashrate looks higher artificially on the kncminer version, then the hardware error % rate will also look artificially lower.

Thanks...  So i take it i have to keep putty running to keep this version of cgminer? i notice when i close putty my miner stops and i got to reboot it to get it back online again.  Or is there a way to run this so i don't have to have my laptop on?  Also is there a way so it starts with this version after a restart?   thanks

[-ck]

Though on a side note my hardware error rate is slowly creeping back up to 6.8 already.  Going to try and downgrade to 9.6.1 my self and see if its any better.

Also bear in mind that if the hashrate looks higher artificially on the kncminer version, then the hardware error % rate will also look artificially lower.

Thanks...  So i take it i have to keep putty running to keep this version of cgminer? i notice when i close putty my miner stops and i got to reboot it to get it back online again.  Or is there a way to run this so i don't have to have my laptop on?  Also is there a way so it starts with this version after a restart?   thanks

If you start cgminer with this instead:

Code:

screen -dm ./cgminer -c cgminer.conf

it will start in the background in a "screen session" so it will keep running.

Then you can "attach" to the screen with

Code:

screen -d -r

to see what's happening

Even if you close your ssh session or putty it will keep on running.

[FUKT]

Judging by this https://bitcointalk.org/index.php?topic=249065.0 , the latest hosted order that got deployed was 38xx for yuriygeorge on the 25th of October
The latest shipped order was 586x for DobZombie

My hosted order is 39xx still has "Paid" status.

I am now watching like a hawk if faetos and dunchy (400x and 421x) would report their hosted units as deployed.

If that happens, I'll be demanding refund.

I know of a hosted order 42XX that is up and running . . . if it helps.

[sickpig]

So final
The Jupiter work better when is harm or when is it cold???

Someone suggested aiming a hair drier at it, done CAREFULLY  that would give you a good indication.

They certainly run waaay better at 55-65, than at 35-45.

just to another datapoint the following are bfgminer stats for my jup

 KNC 0: 50.5C | 135.0/131.7/123.1Gh/s | A:230 R:112+0(2.4%) HW:2216/5.4%
 KNC 1: 50.5C | 133.3/130.3/126.5Gh/s | A:214 R: 80+0(1.8%) HW:1041/2.6%
 KNC 2: 47.0C | 134.4/131.9/126.0Gh/s | A:226 R: 85+0(1.7%) HW:1285/3.2%
 KNC 3: 39.0C | 142.5/139.4/134.4Gh/s | A:218 R:101+0(2.2%) HW: 481/1.1%

the coolest chip run faster and with less HW errors.

it could be due to a lot if reasons: the right controller plug, the better production quality, the position on the miner etc. etc.

if I had physical access to the machine I would try to raise the temp of the 4th chip just to verify if I would have even better perf, but I think I'll have to wait till wednesday afternoon.


edit: using fw 0.95

[djcoin]

Though on a side note my hardware error rate is slowly creeping back up to 6.8 already.  Going to try and downgrade to 9.6.1 my self and see if its any better.

Also bear in mind that if the hashrate looks higher artificially on the kncminer version, then the hardware error % rate will also look artificially lower.

Thanks...  So i take it i have to keep putty running to keep this version of cgminer? i notice when i close putty my miner stops and i got to reboot it to get it back online again.  Or is there a way to run this so i don't have to have my laptop on?  Also is there a way so it starts with this version after a restart?   thanks

If you start cgminer with this instead:

Code:

screen -dm ./cgminer cgminer.conf

it will start in the background in a "screen session" so it will keep running.

Then you can "attach" to the screen with

Code:

screen -d -r

to see what's happening

Even if you close your ssh session or putty it will keep on running.

Fixing typo in the example above,  -c

Code:

screen -dm ./cgminer -c /config/cgminer.conf

[-ck]

Fixing typo in the example above,  -c

Code:

screen -dm ./cgminer -c /config/cgminer.conf

Edited original post, thanks.

[600watt]

exactly since 25th october midnight my knc-hosted miners who were running at stable 3200 Gh/s for almost two weeks went down to 2950 (stable) - what could have caused it ?

[Xialla]

exactly since 25th october midnight my knc-hosted miners who were running at stable 3200 Gh/s for almost two weeks went down to 2950 (stable) - what could have caused it ?

maybe .97 firmware upgrade? I have got very similar drop on my Jupiter with .97

[jelin1984]

So final have or not have less how errors
With ckcolivas cgminer??

[btc_uzr]

I've just created a kncminer branch on my github and have imported their most current code and built my first binary for this. It is not a full firmware and the only thing users may note is the hashrate won't lie with this one, as it won't count hardware errors as hashrate. Also my hardware error count is significantly lower with this on the Saturn dev machine I was sent.

Here's a direct link to the binary:
http://ck.kolivas.org/apps/cgminer/kncminer/cgminer

You'll have to ssh into the kncminer and copy and use that file directly. Hopefully the libraries all match between my dev environment and the default kncminer operating system which means the binary should just work if you run it like on any other OS.

Sorry, I have to disagree on 'only thing users may note is the hashrate won't lie'.

Not even running cgminer v3.6.6 for 12h now and I have to report my hashrate increases
I'm runinng Jupiter with firmware v0.95 and 72h avg hashrate graph went from 520-535 GH/s up to 553GH/s still climbing, yay!!

as hint for others:
it took some time until increase in hashrate was noticeable, the first 30-60min I didn't see a change, then went to bed - when checking stats today I was surprised by the obvious hashrate increase


yo ckolivas, a donation will hit your wallet soon, will mine a little into your pocket this evening - hope others will do so as well

In order to do so, just add an additional pool for some time to cgminer, like eligius with his wallet id as username and use balanced workload distribution
You can use the following example to mine with ~ 1/3 of your total hashing rate into his wallet for some time.

Code:

cgminer -o http://your_1st_default_pool:port -u user -p pass \
              -o http://your_2nd_default_pool:port -u user -p pass \
              -o stratum+tcp://stratum.mining.eligius.st:3334 -u 148KkS2vgVi4VzUi4JcKzM2PMaMVPi3nnq  -p none \
              --balance

Thanks for the good work!

[Mota]

So final have or not have less how errors
With ckcolivas cgminer??

Yes. 1 Jupiter running with 8% HW on standard 0.97.
       1 Jupiter running with 5.7% HW from 13% on ckcolivas 0.97  
       -> Hashrate improved too from ~510 to 550
       1 Jupiter running with 2.5% HW from 9% on ckcolivas 0.97
       -> Hashrate improved too from ~550 to 570

I will do a BFG test with 0.97 on the first one later on. If there are considerable changes I will let you know.

[jelin1984]

Ok step by step details for install it ckcolivas?

[optimator]

I've just created a kncminer branch on my github .... and the only thing users may note is the hashrate won't lie with this one, as it won't count hardware errors as hashrate.

And the

Code:

devs

API command actually return useful information!

Thanks ckolivas!