Swedish ASIC miner company kncminer.com

[sickpig]

Don't stuck with Bitcoin.
Underperformed Saturn 180 GH/s
Bitcoin Mining BTCGuild 0,23 BTC (Daily)
PPcoin Solo mining Found 3 Blocks 3 X 207 PPC = 621 PPC X 0.0020200 (Cryptsy Price) = 1.25442 BTC (Daily)
Terracoin Solo Mining 0,3342 BTC (Daily)
 And without difficulty worries!!!

dunno if I'm using it correctly, this calculator

http://www.coinwarz.com/calculators/ppcoin-mining-calculator/?h=500000.00&p=500.00&pc=0&pf=0.00&d=5941288.50405274&r=202.52862206&er=0.00196000&hc=0.00

says me that if I use a jup (circa 500GH/s) to mine PPCoins I'll get 0.67202545 BTC a day at current PPC/BTC exchange rate.

Using the same hashpower mining btc could bring me 0.6432 BTC.

Am I missing something obvious?

Solo mining depends on luck. The calculators use different maths.

Very true the former. Wrong the latter. Math is the same.

And for the exact same reason you could have earned 0 btc...

[1714059471]

1714059471

[1714059471]

1714059471

[1714059471]

1714059471

[AussieHash]

@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

[-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.

[demonmaestro]

still getting voicemail 

[AussieHash]

If cgminer 3.6.6 were to crash, I assume that it would not restart automatically?

For some reason I don't understand, on cgminer restarts my primary and secondary (bitminter) pool are "dead" for about 60-90 seconds, but my tertiary pool is alive from the beginning so mining starts there, before switching back to pool 0

Therefore every time cgminer crash/restarts (not that often) I receive an email from pool 2 that my worker has stopped submitting shares.

[-ck]

If cgminer 3.6.6 were to crash, I assume that it would not restart automatically?

For some reason I don't understand, on cgminer restarts my primary and secondary (bitminter) pool are "dead" for about 60-90 seconds, but my tertiary pool is alive from the beginning so mining starts there, before switching back to pool 0

Therefore every time cgminer crash/restarts (not that often) I receive an email from pool 2 that my worker has stopped submitting shares.

If you specify a stratum pool without the stratum+tcp:// prefix, cgminer tries a few different ways to connect first. Some pools don't like this and it can take a while before cgminer can connect. So to speed up the connections, add the prefix.

[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.

[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.