Here is the results running Jupiter model with 8 VRMs on firmware v0.9.5 for 12 Hours in an ambient room temp environment of 17°C with case cover off and house fan on top of unit.

Update on firmware 0.9.5

Results after 8 hours.

Ambient room temp below 17 degrees celsius. Power draw at wall 580 watts. Case cover off and house fan in place.

Looking good

you can avoid that if you use the P within cgminer.

Thats what I did and never had the issue.

did you make any changes to the cgminer.conf file?

Perhaps the api allow w:0/0 line?

or Perhaps the api port default 4028?

3 hour 11 min update.

I notice that the hw % is down to under 5% however I also notice that the WU/m is down from what I had from v 0.9.4

Firmware 0.9.4 averaged at just under WU8300 and HW% was at 6.5%
Firmware 0.9.5 averaged at 7800 and HW% is just under 5%

Here are the results Jupiter on firmware v0.9.5 power 580 watt @ 120v

Here is the results after at least 10 minutes.

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.

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.


source

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

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.

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:~#

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.

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

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

Unfortunately for this experiment I am using windows 7 pro.

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

KnCMiner stats after 1 hour.


I forgot to include pool results

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

KnCMiner stats after 45 minutes.

Thats not 100% true. The reason is that it did enable the cores if you look back.

However for some reason the system never pulled more watts as would normally be expected with cores being turned on. Perhaps those core's are not getting the adequate power needed to work?

I will do a full system power down and after 1 min power it back on. Note (Avalon's also need this as they do not turn off completely until about 30 seconds after powering down.)

Yes you are correct. However even with the firmware enabling the shut off core's the performance did not go up and the power draw on the wall was still below the 580 watts.

Also it seems the software reset did make the system pull the proper watts at the wall as it presently is at 577 watts.

However the performance started at 500 gh/s and is slowly increasing up. It presently is at 518 GH/s however I installed that custom script and it seems to not be loading the status tab with the details.

IF I remained at the status tab I noticed that the GH/s did drop down to 514 GH/s. It could have been a coincidence. However just to be sure I decided to see what load that scrypt put on the system.



Nice the load increase once I was at the status tab and it drop once i moved to the update tab?

Just wanted to share this observation.

If you have been following my posts. You would see that I raised the temperature in the room from sub 17 degrees Celsius (°C) to 25 degrees Celsius (°C)to test if the system would continue to operate at the optimal speed at those temps even with increased air flow using the house fan. The system started averaging around 500GH/s and the power draw at the wall was 530 watts.

After 3 hours pass at 25 degrees Celsius (°C) I then lower the room ambient temp to under 17 degrees Celsius (°C)

The core processors did become active and the VRM's did start to pull more power. However the firmware never recovered the loss performance nor did it go back to 580 watts at the wall. It just peaked at 540 watts.

The answer was that the firmware adjusted by lowering the performance to a target that would have been 500 GH/s if left alone.

However I have since issued a software restart and will see if that would be adequate to get it running optimal at the low ambient room temperature.

Software restart command sent from web interface.

Putty gave me loss connection message and this is what came up on cgminer.



At least that work was submitted.