Swedish ASIC miner company kncminer.com

[Luke-Jr]

Code:

cat >/etc/opkg/feeds.conf <<\EOF
src/gz noarch http://feeds.angstrom-distribution.org/feeds/v2013.06/ipk/eglibc/all/
src/gz base http://feeds.angstrom-distribution.org/feeds/v2013.06/ipk/eglibc/cortexa8hf-vfp-neon/base/
src/gz debug http://feeds.angstrom-distribution.org/feeds/v2013.06/ipk/eglibc/cortexa8hf-vfp-neon/debug/
src/gz beaglebone http://feeds.angstrom-distribution.org/feeds/v2013.06/ipk/eglibc/cortexa8hf-vfp-neon/machine/beaglebone/
src/gz perl http://feeds.angstrom-distribution.org/feeds/v2013.06/ipk/eglibc/cortexa8hf-vfp-neon/perl/
src/gz python http://feeds.angstrom-distribution.org/feeds/v2013.06/ipk/eglibc/cortexa8hf-vfp-neon/python/
EOF
opkg update
opkg install angstrom-feed-configs
rm /etc/opkg/feeds.conf
opkg update

opkg install update-alternatives
opkg install automake autoconf make gcc cpp binutils git less pkgconfig-dev ncurses-dev libtool nano bash i2c-tools-dev
while ! opkg install libcurl-dev; do true; done
ln -s aclocal-1.12 /usr/share/aclocal

curl http://www.digip.org/jansson/releases/jansson-2.0.1.tar.bz2 | tar -xjvp
cd jansson-2.0.1
./configure --prefix=/usr CC=arm-angstrom-linux-gnueabi-gcc --disable-static NM=arm-angstrom-linux-gnueabi-nm
make install && ldconfig
cd ..

git clone git://github.com/luke-jr/bfgminer -b knc
cd bfgminer
./autogen.sh
git clone git://github.com/troydhanson/uthash
./configure --host=arm-angstrom-linux-gnueabi --enable-knc CFLAGS=-I$PWD/uthash/src
make AR=arm-angstrom-linux-gnueabi-ar

./bfgminer -S knc:auto -c /config/cgminer.conf

[1713511577]

1713511577

[1713511577]

1713511577

[1713511577]

1713511577

[1713511577]

1713511577

[Luke-Jr]

Any performance/flushwork/etc benefits with BFGminer right now vs. the stock cgminer?

Seems to perform at least as well. More time is needed to figure out if it's notably better.

Code:

 bfgminer version 3.3.0 - Started: [2013-10-22 04:02:28] - [  0 days 02:14:20]
 [M]anage devices [P]ool management [S]ettings [D]isplay options  [H]elp [Q]uit 
 Connected to stratum.mining.eligius.st diff 64 with stratum as user 14cbTxT4nN1AFQzEdFURb9co
 Block: ...ed7f12e1 #265245  Diff:268M ( 1.92Ph/s)  Started: [06:23:33]
 ST:2  F:0  NB:29  AS:0  BW:[141/126 B/s]  E:457.72  I:20.14mBTC/hr  BS:939k
 2/379  60.0C | 267.0/269.3/255.2Gh/s | A:6847 R:28+0(.40%) HW:14839/3.0%
--------------------------------------------------------------------------------
 KNC 0: 60.0C | 134.1/131.7/123.3Gh/s | A:3286 R:19+0(.55%) HW:12796/5.2%
 KNC 1: 55.0C | 140.4/137.7/131.9Gh/s | A:3564 R: 9+0(.25%) HW: 2044/.82%

Also, I seem to be unable to connect using a socks5 proxy with the built-in cgminer, any comment on that, perhaps the compiled curl versions was a problem... How about BFGminer re: socks5/TOR connectivity?

I've not heard any reports of proxy problems with BFGMiner.

[paranoidx]

Okay, received my jupiter today.  Wast getting about 450gh/s with temperatures around 60 degrees C.
I updated to .96 and my temps went down to 40 degrees C. Hashrate stayed about the same.
I loaded up enablecore.bin and it gave me an error while rebooting.  Now everytime I try to go to the miners setup page, it gives me a 404 page not found.

Any ideas??


**** Ignore ^. A hard reset did the trick.
Averaging 480 gh/s with temps around 50.

[texaslabrat]

Okay, received my jupiter today.  Wast getting about 450gh/s with temperatures around 60 degrees C.
I updated to .96 and my temps went down to 40 degrees C. Hashrate stayed about the same.
I loaded up enablecore.bin and it gave me an error while rebooting.  Now everytime I try to go to the miners setup page, it gives me a 404 page not found.

Any ideas??

Clear your browser cache

[sbfree]

Okay, received my jupiter today.  Wast getting about 450gh/s with temperatures around 60 degrees C.
I updated to .96 and my temps went down to 40 degrees C. Hashrate stayed about the same.
I loaded up enablecore.bin and it gave me an error while rebooting.  Now everytime I try to go to the miners setup page, it gives me a 404 page not found.

Any ideas??


**** Ignore ^. A hard reset did the trick.
Averaging 480 gh/s with temps around 50.

clear your cache, or use a different browser....

[sickpig]

Code:

 bfgminer version 3.3.0 - Started: [2013-10-22 04:02:28] - [  0 days 02:14:20]
 [M]anage devices [P]ool management [S]ettings [D]isplay options  [H]elp [Q]uit 
 Connected to stratum.mining.eligius.st diff 64 with stratum as user 14cbTxT4nN1AFQzEdFURb9co
 Block: ...ed7f12e1 #265245  Diff:268M ( 1.92Ph/s)  Started: [06:23:33]
 ST:2  F:0  NB:29  AS:0  BW:[141/126 B/s]  E:457.72  I:20.14mBTC/hr  BS:939k
 2/379  60.0C | 267.0/269.3/255.2Gh/s | A:6847 R:28+0(.40%) HW:14839/3.0%
--------------------------------------------------------------------------------
 KNC 0: 60.0C | 134.1/131.7/123.3Gh/s | A:3286 R:19+0(.55%) HW:12796/5.2%
 KNC 1: 55.0C | 140.4/137.7/131.9Gh/s | A:3564 R: 9+0(.25%) HW: 2044/.82%

Kudos! You're fast

I really appreciate that BFGminer split stats per asic slot, very useful.
So from the statistics you reported here it seems that the core with higher temp perform worse and has a lot of HW error more.
I'm really looking forward to use BFGminer on my jups.

[trepex]

I tried the bfgminer installation from Luke-Jr on my Saturn running 0.96.

Installation & compilation went through fine.
"bfgminer -h" works

Starting bfgminer as described (of course I "q"uit the original cgminer first) results in a Segmentation fault and
the TTY settings broken and a cleared screen.

"<ctrl-j> stty sane <ctrl-j>" fixed this.

Started the bfgminer with "| less" to see what's happening:

[2013-10-22 08:23:27] Started bfgminer 3.3.0
[2013-10-22 08:23:27] Loaded configuration file /config/cgminer.conf
[2013-10-22 08:23:27] Probing for an alive pool
[2013-10-22 08:23:28] Switching to pool 1 http://stratum.bitcoin.cz:3333 - first alive pool
[2013-10-22 08:23:28] Network difficulty changed to 268M ( 1.92Ph/s)
[2013-10-22 08:23:28] Stratum from pool 1 detected new block
[2013-10-22 08:23:28] Pool 1 is hiding block contents from us
[2013-10-22 08:23:29] Pool 0 http://mint.bitminter.com:3333 alive
[2013-10-22 08:23:29] Switching to pool 0 http://mint.bitminter.com:3333
[2013-10-22 08:23:29] Stratum from pool 0 requested work update
[2013-10-22 08:23:29] Pool 0 is hiding block contents from us
Segmentation fault

ESC)0ESC7ESC[?47hESC[1;40rESC[mESC[4lESC[mESC[?1hESC=ESC[mESC[mESC[HESC[2JESC[8B [2013-10-22 08:23:27] Started bfgminer 3.3.0^MESC[2B [2013-10-22 08:23:27] Loaded configuration file /config/cgminer.conf^MESC[1B [2013-10-22 08:23:27] Probing for an alive pool^MESC[1B [2013-10-22 08:23:28] Switching to pool 1 http://stratum.bitcoin.cz:3333 - first alive pool^MESC[1B [2013-10-22 08:23:28] Network difficulty changed to 268M ( 1.92Ph/s)^MESC[1B [2013-10-22 08:23:28] Stratum from pool 1 detected new block^MESC[1B [2013-10-22 08:23:28] Pool 1 is hiding block contents from us^MESC[1B [2013-10-22 08:23:29] Pool 0 http://mint.bitminter.com:3333 alive^MESC[1B [2013-10-22 08:23:29] Switching to pool 0 http://mint.bitminter.com:3333^MESC[1B [2013-10-22 08:23:29] Stratum from pool 0 requested work update^M
                                                                                        ^MESC[1B [2013-10-22 08:23:29] Pool 0 is hiding block contents from usESC[HESC[2J
                          (END)Segmentation fault

Problem could be reproduced.

I switched back to the original cgminer.

My config has 2 pools in there: Bitminter/Slush (bitcoin.cz)
Bitminter uses a "min. diff" of 256.

trepex / Ralf

[btcusr]

Just wanted to check whether everyone received your miners (100 BTC/Jupiter) so far, able to earn at least 75 BTC/Jupiter?

Because next week, November miners due for release which are only 25 BTC/Jupiter.

So, what's the moral of the story?

[demonmaestro]

i still havent recived my miner.

[The Avenger]

Just wanted to check whether everyone received your miners (100 BTC/Jupiter) so far, able to earn at least 75 BTC/Jupiter?

Because next week, November miners due for release which are only 25 BTC/Jupiter.

So, what's the moral of the story?

We're all being fucked by a greedy bunch of lying bastards in Sweden?

16th October
After yesterday’s factory output we can now say we are currently 3-5 days behind in the factory

That was 5 working days ago.

Can't wait for today's bullshit-sandwich "daily" news update!

[Rampion]

If anyone is interested I'm selling Jupiters in hand, immediate delivery: https://bitcointalk.org/index.php?topic=315781

(shameless plug)

[trepex]

Update: The regular flushworks are pulling down the performance.
Please ignore my post / idea.

Hi,

I just noticed something very interesting while trying to get bfgminer work:

I "q"uit cgminer and the screen session terminated.
I then started cgminer manually with

# cgminer -c /config/cgminer.conf

As a result the BertMod tool is not working anymore but on the other hand, the performance did go up
like 4GH (on a Saturn) to 274.4-275. A value that I never managed to see stable for a long time.
Of course I don't have any long-term experience yet. Maybe someone else wants to try this.

cgminer is currently not running in a screen session but directly. Might be a reason for the better performance as well.

[demonmaestro]

That was 5 working days ago.

Can't wait for today's bullshit-sandwich "daily" news update!

we didnt even get an update yesterday

And i am starting to get pissed off with this  "In progress" crap! 

[timmmers]

Someone's doing their job well. Mine's in a van and looking like making it in under 24 hours. Fingers crossed it's functioning.
This like having a bloody baby.

[jmevz]

That was 5 working days ago.

Can't wait for today's bullshit-sandwich "daily" news update!

we didnt even get an update yesterday

I want an update! Getting edgy...

[sickpig]

Hi,

I just noticed something very interesting while trying to get bfgminer work:

I "q"uit cgminer and the screen session terminated.
I then started cgminer manually with

# cgminer -c /config/cgminer.conf

As a result the BertMod tool is not working anymore but on the other hand, the performance did go up
like 4GH (on a Saturn) to 274.4-275. A value that I never managed to see stable for a long time.
Of course I don't have any long-term experience yet. Maybe someone else wants to try this.

cgminer is currently not running in a screen session but directly. Might be a reason for the better performance as well.

Hi trepex,

thanks for the info. Anyway it happens to me all the time I've to restart cgminer agter the few mins to get to stable state I've always have better performance than long running cgimer session (8-10GH/s on jup)

[FUKT]

Update: Es sind die flushworks, die die Performance im Mittel einbrechen lassen.
Please ignore my post / idea.

Hi,

I just noticed something very interesting while trying to get bfgminer work:

I "q"uit cgminer and the screen session terminated.
I then started cgminer manually with

# cgminer -c /config/cgminer.conf

As a result the BertMod tool is not working anymore but on the other hand, the performance did go up
like 4GH (on a Saturn) to 274.4-275. A value that I never managed to see stable for a long time.
Of course I don't have any long-term experience yet. Maybe someone else wants to try this.

cgminer is currently not running in a screen session but directly. Might be a reason for the better performance as well.

HAHA, that shade of yellow is offensive.

[robix]

https://www.kncminer.com/news/news-55

[Nemo1024]

That was 5 working days ago.

Can't wait for today's bullshit-sandwich "daily" news update!

we didnt even get an update yesterday

And i am starting to get pissed off with this  "In progress" crap!  

At least you have "In progress" and not "Paid"  

I have a theory: I purchased hosting later with order 58xx, while my Saturn is 39xx. It might be that I got pushed down the queue as I saw a couple of orders in the 39xx-41xx range which got shipped yesterday, while mine still says "Paid".

[sickpig]

Was getting a 486ghs(avg) in CG now getting after a few min 516ghs(avg) WOAH!! All I did was stop CGminer by pressing q inside it, then I applied the enablecores.bin and rebooted. I'm an 8 VRM Jupiter guys DO THIS, stop waiting.

so let check if I understand this correctly.

1) u where running on 0.94 @ 486GH/s
2) you have a die on one of your ASIC slot with all 48cores disabled.
3) you stopped cgminer
4) apply enablecore.bin from web interface
5) click on the reboot link in the web interface.
6) after that you're mining @ 516GH/s

is it right ?

The die that came back was Die "1" on my slot 4, below is a current bertmod output of it. I have 12 other cores out across the other chips for 13 total now and usually they almost all turn on after 2 hours. I still have this damn power down slide after 6 hours but it slides only to 500 ghs in the five second instead of 440ghs or less as it use to before enablecores.bin usage.  

(5s):541.7G (avg):519.5Gh/s NOW!

Temperature sensor: 38.5 C

Die ID   Cores ON   Cores OFF   %
0   48   0   100
1   47   1   97.9
2   48   0   100
3   48   0   100
DC/DC ID   ON/OFF   Status   Input Voltage   Output Voltage   Output Current
0   ON   OK   11.8 V   0.744 V   35.5 A (26.4 W)
1   OFF   OFF   11.8 V   0.712 V   0 A
2   ON   OK   11.8 V   0.738 V   38.5 A (28.4 W)
3   OFF   OFF   11.8 V   0.747 V   0 A
4   ON   OK   12 V   0.745 V   38.2 A (28.5 W)
5   OFF   OFF   11.9 V   0.695 V   0 A
6   OFF   OFF   11.8 V   0.739 V   0 A
7   ON   OK   11.8 V   0.732 V   40.3 A (29.5 W)
Total DC/DC power output: 446 W

Finally I've rolled the dice and have applied enablecore.bin remotely.

it works

It has resurrected my dead die (for both jups), this the number I got after 20 min

  cgminer version 3.4.0 - Started: [2013-10-22 09:42:08]
--------------------------------------------------------------------------------
 (5s):547.1G (avg):509.1Gh/s | A:174812  R:1030  HW:11986  WU:7354.1/m


a few things tho share enablecore.bin just do this:

Code:

#!/bin/sh
for i in 0 1 2 3 4 5 ; do
        ./enable_all_cores $i >/dev/null 2>&1
        if [ $? = 0 ] ; then
                echo ASIC board \#$i: All cores enabled\</br\>
        else
                echo ASIC board \#$i: not found\</br\>
        fi
done
sync

this is pure speculation someway it removes the map of faulty cores from the asic eeprom, because it requires a reboot to take effect. Just running the above don't change anything in terms of hashrate, the real effect take place at the next reboot.

edit: I forgot to add that probably one of my dies die due fw 0.90 putting to much stress to the machine (to high voltage)