Topic: KNC ASIC Users Thread & FAQ (Read 8761 times)
thanks i post there.
do use multiple knc minor with same pool ?
should use different pool ?
any tip ?
Thank you =)
This is an older thread, see https://bitcointalksearch.org/topic/guide-dogies-comprehensive-kncminer-saturnjupiter-setup-456033 should use different pool ?
any tip ?
Thank you =)
do use multiple knc minor with same pool ?
should use different pool ?
any tip ?
Thank you =)
should use different pool ?
any tip ?
Thank you =)
Code:
Filesystem Size Used Available Use% Mounted on
devtmpfs 245.1M 0 245.1M 0% /dev
/dev/mmcblk0p3 511.7M 88.0K 511.6M 0% /config
rootfs on / type rootfs (rw,relatime)
proc on /proc type proc (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=251008k,nr_inodes=62752,mode=755)
sysfs on /sys type sysfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
/dev/mmcblk0p3 on /config type vfat (rw,sync,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
devtmpfs 245.1M 0 245.1M 0% /dev
/dev/mmcblk0p3 511.7M 88.0K 511.6M 0% /config
rootfs on / type rootfs (rw,relatime)
proc on /proc type proc (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=251008k,nr_inodes=62752,mode=755)
sysfs on /sys type sysfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
/dev/mmcblk0p3 on /config type vfat (rw,sync,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
As it seems the only persistent storage is device /dev/mmcblk0p3 mounted on /config.
Therefore cgminer.conf and passwords remain on the system during upgrades&reboots.
One would have to modify the firmware file.
I see, thanks for letting me know
If somehow you could set that TZ variable during boot that may be a good solution but I know nothing about linux so no idea how.
I see, thanks for letting me know
if you want to change the timezone only, you can set your env var 'TZ=GMT' (or whatever you prefer)
https://bitcointalksearch.org/topic/m.3337684
However it will not sync your time with ntp servers as the approach above from Tigggger
https://bitcointalksearch.org/topic/m.3337684
However it will not sync your time with ntp servers as the approach above from Tigggger
Tried that method as well, but although #date gave the correct response it didn't update the already running cgminer for me which was the thing that was annoying.
Be nice to have a permanent method, ideally an option in the GUI to select timezone.
if you want to change the timezone only, you can set your env var 'TZ=GMT' (or whatever you prefer)
https://bitcointalksearch.org/topic/m.3337684
However it will not sync your time with ntp servers as the approach above from Tiggger
https://bitcointalksearch.org/topic/m.3337684
However it will not sync your time with ntp servers as the approach above from Tiggger
Added details of how to show the correct times into the first post
Modifications
Fixing the time.
Machines appear to ship with the time set to UTC, although it's not important it did annoy me not having the correct time, these instructions came from Nanners on the IRC channel and worked for me, replace 'tigggger' with whatever you want.
Modifications
Fixing the time.
Machines appear to ship with the time set to UTC, although it's not important it did annoy me not having the correct time, these instructions came from Nanners on the IRC channel and worked for me, replace 'tigggger' with whatever you want.
Quote
1. cd /config
2. mkdir tigggger
3. cd /config/tigggger
4. wget http://www.angstrom-distribution.org/feeds/v2012.12/ipk/eglibc/all/tzdata_2012d-r3.0_all.ipk
5. opkg install /config/tigggger/tzdata_2012d-r3.0_all.ipk
6. rm /etc/localtime (NOTE this gave an error for me as the directory wasn't there, but not important just carry on)
7. ln -s /usr/share/zoneinfo/YOURTIMEZONE /etc/localtime (In my case it was /usr/share/zoneinfo/Europe/Belfast)
8. cd /
9. /etc/init.d/ntpd reload
10. ntpdate -b -u pool.ntp.org
Now if you look at cgminer the time should be correct.
2. mkdir tigggger
3. cd /config/tigggger
4. wget http://www.angstrom-distribution.org/feeds/v2012.12/ipk/eglibc/all/tzdata_2012d-r3.0_all.ipk
5. opkg install /config/tigggger/tzdata_2012d-r3.0_all.ipk
6. rm /etc/localtime (NOTE this gave an error for me as the directory wasn't there, but not important just carry on)
7. ln -s /usr/share/zoneinfo/YOURTIMEZONE /etc/localtime (In my case it was /usr/share/zoneinfo/Europe/Belfast)
8. cd /
9. /etc/init.d/ntpd reload
10. ntpdate -b -u pool.ntp.org
Now if you look at cgminer the time should be correct.
never seen before. how many cores are enabled for that die/asic?
Now upgraded from 0.90 to 0.95 and the errors went off, but the cores disabled on that core were 48 in total, that's the reason because that core ran much cooler than the others. Dropped to 430w.
Which is stable and which is unstable ??with 0.95
The 4 or 8 version?
The 4 or 8 version?
.95 firmware for me is a little slower but more stable... Really torn here between loading .91 back and keeping .95?
Don't know how KNC is going to fix my issue if they are shipping 4vrm per module now and I have 8. It's like I have a different product.
Not always best to be first!
Don't know how KNC is going to fix my issue if they are shipping 4vrm per module now and I have 8. It's like I have a different product.
Not always best to be first!
also very interested in the 8 vs 4 VRM boards....
seems to be the difference between a stable 550 and an unstable 400+
.95 nets me around 275/257 GH/sec for a Saturn on cgminer
the crazy thing is the onboard temps don't read above 48C, and i'm not seeing ANYTHING - VRM modules, caps, etc above 55C at the most.
Makes me think they're not thermally limited for clock rate. Maybe the buck converters can't push enough current to clock higher or there's not sufficient decoupling capacitance/other voltage issues?
Or do these have untapped potential? I am ignorant to how these devices are clocked, if cgminer / etc software can adjust the clock frequencies or if it's a hard-soldered oscillator / clock divider or what.
301 watts at the PSU line in
this is also with the cover off, but no external fans
the crazy thing is the onboard temps don't read above 48C, and i'm not seeing ANYTHING - VRM modules, caps, etc above 55C at the most.
Makes me think they're not thermally limited for clock rate. Maybe the buck converters can't push enough current to clock higher or there's not sufficient decoupling capacitance/other voltage issues?
Or do these have untapped potential? I am ignorant to how these devices are clocked, if cgminer / etc software can adjust the clock frequencies or if it's a hard-soldered oscillator / clock divider or what.
301 watts at the PSU line in
this is also with the cover off, but no external fans
.95 firmware for me is a little slower but more stable... Really torn here between loading .91 back and keeping .95?
Don't know how KNC is going to fix my issue if they are shipping 4vrm per module now and I have 8. It's like I have a different product.
Not always best to be first!
Don't know how KNC is going to fix my issue if they are shipping 4vrm per module now and I have 8. It's like I have a different product.
Not always best to be first!
Upgraded from .91 to .95
Erratic first hour, it would go up to 550ghs then crash to 300 something and back. It looks to be settling now at about 450ghs. Will update
Erratic first hour, it would go up to 550ghs then crash to 300 something and back. It looks to be settling now at about 450ghs. Will update
Just got my jupiter and installed 0.95. After 30 minutes or so of running and slowly creeping to 420GH or so, cgminer restarted and the unit now is averaging 475GH or so, with spikes above 500 being rather common. Lots of the cores are going off and on due to hardware errors over and over again. Overall, I'm pretty happy, but I wish it was over 500GH consistently. It's pulling 2A @ 220V from my PDU, so I'm assuming it's rounding down and it's just above 500W.
Just updated to 0.95; seems to have fixed my problems. Went from 440GH/s, 16% errors, 900W to 530GH/s, 5% errors, 620W. Much better!
As I suspected, this update dropped my voltages from 0.92V to ~0.73V, thus the drop in power usage. Obviously they must have also fixed something else that corrected whatever hashrate issues units like mine were having.
As I suspected, this update dropped my voltages from 0.92V to ~0.73V, thus the drop in power usage. Obviously they must have also fixed something else that corrected whatever hashrate issues units like mine were having.
Someone knows what does it mean "FAULT 17" on status of VRM's?
never seen before. how many cores are enabled for that die/asic?
fw 0.95 was just released. give it a try.
Someone knows what does it mean "FAULT 17" on status of VRM's?
never seen before. how many cores are enabled for that die/asic?
Jump to: