KnCMiner Jupiter Miner First Impressions

[Sitarow]

Here is the same results after not moving from the update tab for over 14 mins.

KnCMiner stats after 45 minutes.
https://i.imgur.com/WOCz6VX.jpg

are you using bertmode?

if yes pay attention because it has happened to me that the cgi that get the stats for the ASIC went in a loop consuming quite a few of resource, more to the point the script use i2c-get cli command that query the PCB about temp, consumption, enabled core etc etc  

to solve the issue i've just extracted the perl script contained in bertmode .bin (asic_status.pl) and tun it on the beaglebone.

on your desktop (I assume you're using linux) download bertmod_0_2_1_for_knc_0_94.bin  do the following:

Code:

tar xzf bertmod_0_2_1_for_knc_0_94.bin
scp asic_status.pl root@<ip_of_your_miner>:.
ssh root@<ip_of_your_miner>:.
perl ./asic_status.pl > status.html
exit
scp root@<ip_of_your_miner>:./status.html 
firefox status.html

hope it helps

As you have said I think this had occurred. I posted the details below.

Unfortunately for this experiment I am using windows 7 pro.

[Sitarow]

2 minutes before the hour I lost connection with the Jupiter. Both the pool and the cgminer status page had lost connection as well.

The web interface was responsive however ssh was not working.

After a few moments I was able to connect and cgminer logging page updated from 542Gh/s down to 511Gh/s

Their was no downtime or cgminer restart however it seemed that the beaglebone was stalled.

As you can see the system load was low. The power draw at the wall is 580 watts so I am not sure if this may have been due to the custom script to view the status of the vrm's. I may have to restart the system and not add the vrm monitor script.



I will keep an eye out and see if it does recover over the next hour to 542 GH/s

[sickpig]

Here is the same results after not moving from the update tab for over 14 mins.

KnCMiner stats after 45 minutes.
https://i.imgur.com/WOCz6VX.jpg

are you using bertmode?

if yes pay attention because it has happened to me that the cgi that get the stats for the ASIC went in a loop consuming quite a few of resource, more to the point the script use i2c-get cli command that query the PCB about temp, consumption, enabled core etc etc 

to solve the issue i've just extracted the perl script contained in bertmode .bin (asic_status.pl) and tun it on the beaglebone.

on your desktop (I assume you're using linux) download bertmod_0_2_1_for_knc_0_94.bin  do the following:

Code:

tar xzf bertmod_0_2_1_for_knc_0_94.bin
scp asic_status.pl root@<ip_of_your_miner>:.
ssh root@<ip_of_your_miner>:.
perl ./asic_status.pl > status.html
exit
scp root@<ip_of_your_miner>:./status.html 
firefox status.html

hope it helps

As you have said I think this had occurred. I posted the details above.

Unfortunately for this experiment I am using windows 7 pro.

i think winzip will deal with tar.gz quite nicely.

from the same place where you've downloaded putty you can download pscp, a command line to run from command prompt with the same exact syntax.

[sickpig]

2 minutes before the hour I lost connection with the Jupiter. Both the pool and the cgminer status page had lost connection as well.

The web interface was responsive however ssh was not working.

After a few moments I was able to connect and cgminer logging page updated from 542Gh/s down to 511Gh/s

Their was no downtime or cgminer restart however it seemed that the beaglebone was stalled.

As you can see the system load was low. The power draw at the wall is 580 watts so I am not sure if this may have been due to the custom script to view the status of the vrm's. I may have to restart the system and not add the vrm monitor script.



I will keep an eye out and see if it does recover over the next hour to 542 GH/s

just to be safe, once logged in via ssh, check if asic_status.pl is still running:

Code:

 ps | grep asic_status 

if yes just stop it using  kill command,

Code:

 kill <pid_of_asic_status.pl> 

the pid is the first number you'll see in the output of the first command that I typed. otherwihse you can use pidof.

[Sitarow]

It does not want to die!

  766 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  768 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  770 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  772 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  774 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  776 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  778 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  780 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  782 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  784 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  786 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  788 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  790 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  792 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  794 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  796 root      2152 S    grep asic_status
root@Jupiter-20E:~#


Edit: Okay will do.

[sickpig]

It does not want to die!

  766 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  768 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  770 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  772 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  774 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  776 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  778 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  780 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  782 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  784 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  786 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  788 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  790 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  792 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  794 root      2152 S    grep asic_status
root@Jupiter-20E:~# ps | grep asic_status
  796 root      2152 S    grep asic_status
root@Jupiter-20E:~#

this means there's no such process. actually grep is grepping itself.
try to use

Code:

ps  | grep asic_status | grep -v grep 

if you'll see no output you're safe

 

[sickpig]

I'm sure you guys are aware.. but if not:

http://www.kncminer.com/userfiles/file/kncminer-0.95.bin

yep thanks and also the first feedback seem encouraging

[Sitarow]

I'm sure you guys are aware.. but if not:

http://www.kncminer.com/userfiles/file/kncminer-0.95.bin

I may have killed it before when the system had stalled.


  PID USER       VSZ STAT COMMAND
    1 root      1652 S    init [5]
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    4 root         0 SW   [kworker/0:0]
    5 root         0 SW<  [kworker/0:0H]
    7 root         0 SW<  [kworker/u:0H]
    8 root         0 SW   [migration/0]
    9 root         0 SW   [rcu_bh]
   10 root         0 SW   [rcu_sched]
   11 root         0 SW   [watchdog/0]
   12 root         0 SW<  [khelper]
   13 root         0 SW   [kdevtmpfs]
   14 root         0 SW<  [netns]
   15 root         0 SW   [kworker/0:1]
   16 root         0 SW   [bdi-default]
   17 root         0 SW<  [kintegrityd]
   18 root         0 SW<  [kblockd]
   19 root         0 SW   [khubd]
   20 root         0 SW   [irq/86-44e0b000]
   21 root         0 SW   [kworker/u:1]
   24 root         0 SW   [irq/23-tps65217]
   27 root         0 SW   [irq/46-4819c000]
   36 root         0 SW   [irq/87-4802a000]
   39 root         0 SW<  [rpciod]
   41 root         0 SW   [khungtaskd]
   42 root         0 SW   [kswapd0]
   43 root         0 SW   [fsnotify_mark]
   44 root         0 SW<  [nfsiod]
   45 root         0 SW<  [crypto]
   48 root         0 SW<  [pencrypt]
   49 root         0 SW<  [pdecrypt]
   56 root         0 SW<  [OMAP UART0]
   58 root         0 DW   [spi1]
   61 root         0 SW   [spi2]
   64 root         0 SW<  [kpsmoused]
   65 root         0 SW   [irq/150-mmc0]
   77 root         0 SW<  [deferwq]
   78 root         0 SW   [kworker/u:2]
   79 root         0 SW   [mmcqd/1]
   80 root         0 SW   [mmcqd/1boot0]
   81 root         0 SW   [mmcqd/1boot1]
  114 root         0 SW<  [kworker/0:1H]
  321 root      2148 S    udhcpc -b -x hostname Jupiter-20E eth0
  335 root      2272 S    /usr/sbin/dropbear -r /config/dropbear_rsa_host_key
  338 root      3272 S    /usr/bin/ntpd -p /var/run/ntp.pid -g
  346 avahi     2820 S    avahi-daemon: running [Jupiter-20E.local]
  347 avahi     2728 S    avahi-daemon: chroot helper
  353 root      3108 S    /usr/sbin/lighttpd -f /etc/lighttpd.conf
 1144 root      2016 S    sleep 60
 1145 root      2328 R    ps
 1646 root      2772 S    /usr/sbin/dropbear -r /config/dropbear_rsa_host_key
 1677 root      2328 S    -sh
 1678 root      2616 S    screen -dr
 1704 root      2616 S    {screen} SCREEN -S cgminer -t cgminer -m -d /usr/bin
 1705 root      112m S    /usr/bin/cgminer --default-config /config/cgminer.co
 1708 root      1496 S    /usr/bin/monitor-pwbtn /usr/bin/factory_config_reset
 1725 root      1908 S    /sbin/getty 115200 ttyO0
 1726 root      1908 S    /sbin/getty 38400 tty1
 1727 root      2148 S    {monitordcdc} /bin/sh /sbin/monitordcdc
15845 root      2772 S    /usr/sbin/dropbear -r /config/dropbear_rsa_host_key
16363 root      2328 S    -sh
31784 root      2944 S    /usr/sbin/dropbear -r /config/dropbear_rsa_host_key
31838 root      2328 S    -sh
32463 root      2328 S    sh
32484 root      2328 S    sh -l
root@Jupiter-20E:~# ps | grep asic_status | grep -v grep
root@Jupiter-20E:~#

[DPoS]

I'm sure you guys are aware.. but if not:

http://www.kncminer.com/userfiles/file/kncminer-0.95.bin

yep thanks and also the first feedback seem encouraging

link?   a lot of us rather not roll the dice since they do not do any testing like Sitarow does.

They offer no metrics, nothing, but just say a few things.   Same reason they took off the 4 VRMs, since someone 'thought' it was better to not use them.

[Sitarow]

I'm sure you guys are aware.. but if not:

http://www.kncminer.com/userfiles/file/kncminer-0.95.bin

yep thanks and also the first feedback seem encouraging

link?   a lot of us rather not roll the dice since they do not do any testing like Sitarow does.

They offer no metrics, nothing, but just say a few things.   Same reason they took off the 4 VRMs, since someone 'thought' it was better to not use them.

That may be true. However this exercise is an attempt to get everyone up to speed including the manufacturer.

Hopefully it does work.

This is the last reading I am going to take using firmware v0.9.4

From the looks of it I would say that given time it would eventually get up to the average rate of 544 GH/s.

Let us see how 0.9.5 works.

[Sitarow]

Firmware v0.9.5 is necessary for those with 4 VRM on the asic modul. It is the only reasonable option at this time if you wish to use all 4 modules on a 850 watt power supply.

Asic Bords with 4 VRMs - bug - cool properly until FW fix arrives!
Today, 03:07 PM
The new asic bords with only 4 VRMs are using to much power.

KNC will release a bug fix for this in next (0.95?) Firmware hopefully arriving in short (Today?)

A Jupiter in this Config will use app. 890W. So it can be difficult to start with a 850W ATX. (You can still run them with only 3 boards conected)

The VRMs are also running over spec with app. 50+ A current each! They probably won't burn, but if you can cool them extra until the new firmware is realeased, do it!!
The Asics are tunning to hot (+70 deg C) as they get app, 0.9V instead of 0.7V as they are supposed to. Cool them as much as you can!!!

The Problem is due to the VRMs not working according to spec but KNC will be able to fix it with new firmware (we did our own patch for our miners yesterday).

Easiest fix to cool properly is to provide cool air, belo 20 deg C is a good idea. Open case + big fan will also work.

PS, this does not apply to 8 VRM asic boards. No worries here.

source

http://forum.kncminer.com/forum/main-category/hardware/6746-asic-bords-with-4-vrms-bug-cool-properly-until-fw-fix-arrives

[gnar1ta$]

I'm sure you guys are aware.. but if not:

http://www.kncminer.com/userfiles/file/kncminer-0.95.bin

This does nothing to help the poorly designed work restarts.

[Sitarow]

First results Firmware v0.9.5 power draw is 582 watts at the wall.

Case cover off and house fan put on top of unit.

[DPoS]

Firmware v0.9.5 is necessary for those with 4 VRM on the asic modul. It is the only reasonable option at this time if you wish to use all 4 modules on a 850 watt power supply.

Asic Bords with 4 VRMs - bug - cool properly until FW fix arrives!
Today, 03:07 PM
The new asic bords with only 4 VRMs are using to much power.

KNC will release a bug fix for this in next (0.95?) Firmware hopefully arriving in short (Today?)

A Jupiter in this Config will use app. 890W. So it can be difficult to start with a 850W ATX. (You can still run them with only 3 boards conected)

The VRMs are also running over spec with app. 50+ A current each! They probably won't burn, but if you can cool them extra until the new firmware is realeased, do it!!
The Asics are tunning to hot (+70 deg C) as they get app, 0.9V instead of 0.7V as they are supposed to. Cool them as much as you can!!!

The Problem is due to the VRMs not working according to spec but KNC will be able to fix it with new firmware (we did our own patch for our miners yesterday).

Easiest fix to cool properly is to provide cool air, belo 20 deg C is a good idea. Open case + big fan will also work.

PS, this does not apply to 8 VRM asic boards. No worries here.

source

http://forum.kncminer.com/forum/main-category/hardware/6746-asic-bords-with-4-vrms-bug-cool-properly-until-fw-fix-arrives

yeah it is a miracle I was able to cool my jupiter down enough that had all 4 boards with 4 VRMs using a 850 PSU and hash stable ~520  (770 watts)

but orama says I have horse ass for brains thinking cooling mattered

[DPoS]

I'm sure you guys are aware.. but if not:

http://www.kncminer.com/userfiles/file/kncminer-0.95.bin

This does nothing to help the poorly designed work restarts.

I will wait as well.  .93 is very good at bringing hash rate back up quickly

[Sitarow]

Here is the results after at least 10 minutes.

[r3animation]

Not sure if it matters but my WU/m is down with the new update. From 40xx WU/m to 37xx WU/m.

Pool hashrate is around the same and HW errors have dropped alot.

[DPoS]

Sitarow,  you might not see much of a performance jump with .95 since your Jupiters all have 8 VRMs right?

I may upgrade one of mine that has all boards with 4 VRMs since it is really pushing my 850psu at 770 watts

[Xialla]

Not sure if it matters but my WU/m is down with the new update. From 40xx WU/m to 37xx WU/m.

Pool hashrate is around the same and HW errors have dropped alot.

yeah, same here. WU is lower..don't know if it is good or bad mark.) less HW errors and ~545Gh/s average hashrate. Will see tomorrow.

[jelin1984]

MINE CORE work only with 0.91 and 0.92 firware
with any other is total dead

i can understand why???