Topic: KnCMiner Jupiter Miner First Impressions - page 12. (Read 65993 times)
They've been just jammed... I just started them by pushing finger and working fine now.
Hi guys, I just got my first Jupiter up and running. Before I turned it on, of course I had to open the case, fix the fans (they been flying everywhere in the case). Now I am happily mining at ~522 GH/s. Firmware was already updated to 0.95.
But what is my concern is that 2 14mm Arctic fans are not working. They should be working all time? Or they temperature controlled? What should I do about it?
But what is my concern is that 2 14mm Arctic fans are not working. They should be working all time? Or they temperature controlled? What should I do about it?
4 or 8 VRM? Power consumtpion?
thanks
Hi guys, I just got my first Jupiter up and running. Before I turned it on, of course I had to open the case, fix the fans (they been flying everywhere in the case). Now I am happily mining at ~522 GH/s. Firmware was already updated to 0.95.
But what is my concern is that 2 14mm Arctic fans are not working. They should be working all time? Or they temperature controlled? What should I do about it?
But what is my concern is that 2 14mm Arctic fans are not working. They should be working all time? Or they temperature controlled? What should I do about it?
Firstly I'm not a native english speaker then I've had a few difficulties to parse your post, so I just want to say sorry in advance 
This makes sense and fit with the results of further research I've made.
Sorry but as I already said lack of knowledge and rusty english just don't let me grasp the meaning of your statement fully. Anyway I'm more than glad to read good "review" of KnC work.
still can't parse
did you already solve this problem or do you still need help?
BitBuster said that doing an hard reset could be beneficial for miners running 0.95
I've dig a little and I found that on BB there seems to be a process that will take care of resetting to factory default, namely:
it seems that every time we perform the magic sequence (press five - wait five - press five) monitor-pwbtn will excute factory_config_reset.sh.
The script simply restore a few configuration files (pwd,webserver,etc) nothing fancy, if you're interested in more detail look at /etc/init.d/kncminer_setup.sh.
My question is: do you think that other than doing aforementioned tasks it will do something else at FPGA/PCB?
I've extracted strings from /usr/bin/monitor-pwbtn and the only interesting thing I saw are:
There is a clearup of the database of the disabled cores. But... the disabled cores are disabled ON CHIP, not in the linux. I've dig a little and I found that on BB there seems to be a process that will take care of resetting to factory default, namely:
Code:
1710 root 1496 S /usr/bin/monitor-pwbtn /usr/bin/factory_config_reset.sh
it seems that every time we perform the magic sequence (press five - wait five - press five) monitor-pwbtn will excute factory_config_reset.sh.
The script simply restore a few configuration files (pwd,webserver,etc) nothing fancy, if you're interested in more detail look at /etc/init.d/kncminer_setup.sh.
My question is: do you think that other than doing aforementioned tasks it will do something else at FPGA/PCB?
I've extracted strings from /usr/bin/monitor-pwbtn and the only interesting thing I saw are:
Code:
echo low >/sys/class/gpio/gpio71/direction
echo high >/sys/class/gpio/gpio71/direction
This makes sense and fit with the results of further research I've made.
That is, their clock is disconnected by a command and maybe also power supply, but I believe only the latter as some chips took 15A while being disabled. KnC demonstrated the best clock distribution network I have seen in a long time, IMHO.
Sorry but as I already said lack of knowledge and rusty english just don't let me grasp the meaning of your statement fully. Anyway I'm more than glad to read good "review" of KnC work.
So, it seems the dual cores don't have an "enable" option? maybe it is easier to re-set all the clock gates at once.
still can't parse
an you direct me how to unpack or mount the u-boot rootfs.cpio file? I believe I have found a method, but I'm out during the day so I ask if you have a quick solution to that. Then I will enable to explain A LOT! (Can't wait to get inside, knock! knock!)
did you already solve this problem or do you still need help?
Any recommendations for a wireless ethernet bridge?
I would avoid using a wireless connection altogether, unreliable and prone to interference from your neighbor, microwaves, etc. I have been using the following Powerline adapter kits (only $100) for the past week without any issue. I get actual throughput of more than 10MBps (=80Mbps) with low 2-3ms ping latency, much better than any wireless routers/bridge combo I have tried (Cisco, Netgear, D-Link, Ubiquiti, Ruckus).
NETGEAR Powerline 500 Mbps 4-port Network Adapter Kit (XAVB5004)
im having a bit of trouble, if anyone could help me out.
cgminer just hangs when i try to connect back to eligius.
any help would be appreciated.
Is eligius the pool in which BFL Josh has fingers in? If so, it would explain the strange behaviour. ...sorry for highjacking this thread. cgminer just hangs when i try to connect back to eligius.
any help would be appreciated.
You are probably thinking of the Eclipse pool which was started by BFL Josh. Eligius is ran by Luke-Jr.
https://bitcointalksearch.org/topic/old-eligius-asic-no-registration-no-fee-cppsrb-btc-105-pps-nmc-877-23768
im having a bit of trouble, if anyone could help me out.
cgminer just hangs when i try to connect back to eligius.
any help would be appreciated.
Is eligius the pool in which BFL Josh has fingers in? If so, it would explain the strange behaviour. ...sorry for highjacking this thread. cgminer just hangs when i try to connect back to eligius.
any help would be appreciated.
Code:
echo low >/sys/class/gpio/gpio71/direction
echo high >/sys/class/gpio/gpio71/direction
im having a bit of trouble, if anyone could help me out.
cgminer doesnt seem to want to start when i try to connect to my eligius account. but starts up fine with other pools.
it has worked fine for a week now, but all of a sudden after i tried slushs pool for an hour, cgminer just hangs when i try to connect back to eligius. tried 50btc and thats working too. back at slush again for now.
any ideas, could it be some pool config file that got messed up somehow?
ive tried hard reset, and reinstalling firmware. nothing helps.
im not experienced with linux, but know enough to ssh in with putty and execute screen -r.
all i get when trying to connect to eligius is the cgminer startup screen with " starting cgminer 3.4.0"
and then nothing.
any help would be appreciated.
cgminer doesnt seem to want to start when i try to connect to my eligius account. but starts up fine with other pools.
it has worked fine for a week now, but all of a sudden after i tried slushs pool for an hour, cgminer just hangs when i try to connect back to eligius. tried 50btc and thats working too. back at slush again for now.
any ideas, could it be some pool config file that got messed up somehow?
ive tried hard reset, and reinstalling firmware. nothing helps.
im not experienced with linux, but know enough to ssh in with putty and execute screen -r.
all i get when trying to connect to eligius is the cgminer startup screen with " starting cgminer 3.4.0"
and then nothing.
any help would be appreciated.
BitBuster said that doing an hard reset could be beneficial for miners running 0.95
I've dig a little and I found that on BB there seems to be a process that will take care of resetting to factory default, namely:
it seems that every time we perform the magic sequence (press five - wait five - press five) monitor-pwbtn will excute factory_config_reset.sh.
The script simply restore a few configuration files (pwd,webserver,etc) nothing fancy, if you're interested in more detail look at /etc/init.d/kncminer_setup.sh.
My question is: do you think that other than doing aforementioned tasks it will do something else at FPGA/PCB?
I've extracted strings from /usr/bin/monitor-pwbtn and the only interesting thing I saw are:
There is a clearup of the database of the disabled cores. But... the disabled cores are disabled ON CHIP, not in the linux. That is, their clock is disconnected by a command and maybe also power supply, but I believe only the latter as some chips took 15A while being disabled. KnC demonstrated the best clock distribution network I have seen in a long time, IMHO.I've dig a little and I found that on BB there seems to be a process that will take care of resetting to factory default, namely:
Code:
1710 root 1496 S /usr/bin/monitor-pwbtn /usr/bin/factory_config_reset.sh
it seems that every time we perform the magic sequence (press five - wait five - press five) monitor-pwbtn will excute factory_config_reset.sh.
The script simply restore a few configuration files (pwd,webserver,etc) nothing fancy, if you're interested in more detail look at /etc/init.d/kncminer_setup.sh.
My question is: do you think that other than doing aforementioned tasks it will do something else at FPGA/PCB?
I've extracted strings from /usr/bin/monitor-pwbtn and the only interesting thing I saw are:
Code:
echo low >/sys/class/gpio/gpio71/direction
echo high >/sys/class/gpio/gpio71/direction
So, it seems the dual cores don't have an "enable" option? maybe it is easier to re-set all the clock gates at once.
an you direct me how to unpack or mount the u-boot rootfs.cpio file? I believe I have found a method, but I'm out during the day so I ask if you have a quick solution to that. Then I will enable to explain A LOT! (Can't wait to get inside, knock! knock!)
Once again, the chips were never tested or put into different batches. That was to save us week(s) of production time, not to mention costs and development costs of the testing scripts.
Are you an official spokesman for KNC?
Then you may have missed it, the whole strategy and plan, procedure was explained in there, their English was sometimes far less than optimal, but it went OK.
The fastest design-to market is achieved only when you have redundancy and skip the costly steps. So that's why they did 48-dual core chips, 4 chips per one MCM processor, and that's 4 processors per one large miner. The promised hashrate was given by the expected yield and continuously increased as the verification and production yield of the design allowed.
Planar epitaxy is a wonderful science, you should play with it for a while, amazing things to learn.
P.S. if you hear anyone talk about an "emitter follower", here is a hint; it's not a cult member.
Any recommendations for a wireless ethernet bridge?
I was skimming through knc forum and I found this:
http://forum.kncminer.com/forum/main-category/hardware/7111-core-x-was-disabled-due-to-10-hw-errors?p=7121#post7121
BitBuster said that doing an hard reset could be beneficial for miners running 0.95
I've dig a little and I found that on BB there seems to be a process that will take care of resetting to factory default, namely:
it seems that every time we perform the magic sequence (press five - wait five - press five) monitor-pwbtn will excute factory_config_reset.sh.
The script simply restore a few configuration files (pwd,webserver,etc) nothing fancy, if you're interested in more detail look at /etc/init.d/kncminer_setup.sh.
My question is: do you think that other than doing aforementioned tasks it will do something else at FPGA/PCB?
I've extracted strings from /usr/bin/monitor-pwbtn and the only interesting thing I saw are:
opinions?
http://forum.kncminer.com/forum/main-category/hardware/7111-core-x-was-disabled-due-to-10-hw-errors?p=7121#post7121
BitBuster said that doing an hard reset could be beneficial for miners running 0.95
I've dig a little and I found that on BB there seems to be a process that will take care of resetting to factory default, namely:
Code:
1710 root 1496 S /usr/bin/monitor-pwbtn /usr/bin/factory_config_reset.sh
it seems that every time we perform the magic sequence (press five - wait five - press five) monitor-pwbtn will excute factory_config_reset.sh.
The script simply restore a few configuration files (pwd,webserver,etc) nothing fancy, if you're interested in more detail look at /etc/init.d/kncminer_setup.sh.
My question is: do you think that other than doing aforementioned tasks it will do something else at FPGA/PCB?
I've extracted strings from /usr/bin/monitor-pwbtn and the only interesting thing I saw are:
Code:
echo low >/sys/class/gpio/gpio71/direction
echo high >/sys/class/gpio/gpio71/direction
opinions?
Sitarow I just want to thank you for thorough tests. Really appreciated.
Your welcome.
Sitarow I just want to thank you for thorough tests. Really appreciated.
With 8 VRMs you get that choice between .93/.94 & .95 without the 300 watt difference and crazy heat
With 4 VRMs, the best they could do going forward is somehow make less and less HW errors and cores turning off since they won't let it run hot anymore with newer firmware. (the datacenter would explode)
With 4 VRMs, the best they could do going forward is somehow make less and less HW errors and cores turning off since they won't let it run hot anymore with newer firmware. (the datacenter would explode)
Jupiter 24 hour update.
Been running jupiter with firmware v0.9.5 with case cover on and front two intake fans swapped with two 175 cfm fans.
I kept the ambient room temp 19°C for the duration of this test.
Results
Results Firmware v0.9.5 over 24 hours with case on and new intake fans 175 cfm - ambient temperature 19°C.
The power consumption for firmware v0.9.5 with the case cover on and the added cooling from replacing the intake fans with higher cfm ones is 574 watts.
Results Firmware v0.9.5 over 24 hours with case cover off and added house fan for cooling - ambient temperature 17°C.
Results for Firmware v0.9.4 over 24 hours with case cover off and added house fan for cooling - ambient temperature 17°C
You can tell that over the course of the 24 hours firmware 0.9.5 gave more stable speeds and less hardware error %.
However firmware v0.9.4 gave more submitted shares and a WU rate of over 8200 steady.
Both firmware power usage fluctuated between 578 and 580 watts.
The power consumption for firmware v0.9.5 with the case cover on and the added cooling from replacing the intake fans with higher cfm ones is 574 watts.
As far as the case cover on with the new fans. My guess is that it is the best one can expect, unless firmware v0.9.6 will make the performance increase.
Been running jupiter with firmware v0.9.5 with case cover on and front two intake fans swapped with two 175 cfm fans.
I kept the ambient room temp 19°C for the duration of this test.
Results
Results Firmware v0.9.5 over 24 hours with case on and new intake fans 175 cfm - ambient temperature 19°C.
The power consumption for firmware v0.9.5 with the case cover on and the added cooling from replacing the intake fans with higher cfm ones is 574 watts.
Results Firmware v0.9.5 over 24 hours with case cover off and added house fan for cooling - ambient temperature 17°C.
Results for Firmware v0.9.4 over 24 hours with case cover off and added house fan for cooling - ambient temperature 17°C
You can tell that over the course of the 24 hours firmware 0.9.5 gave more stable speeds and less hardware error %.
However firmware v0.9.4 gave more submitted shares and a WU rate of over 8200 steady.
Both firmware power usage fluctuated between 578 and 580 watts.
The power consumption for firmware v0.9.5 with the case cover on and the added cooling from replacing the intake fans with higher cfm ones is 574 watts.
As far as the case cover on with the new fans. My guess is that it is the best one can expect, unless firmware v0.9.6 will make the performance increase.
Once again, the chips were never tested or put into different batches. That was to save us week(s) of production time, not to mention costs and development costs of the testing scripts.
Are you an official spokesman for KNC?
Those regulators are speced for a max current of 40A each....
Has anyone pointed out that's a good suspect for the VRMs and caps failing?
The capacitor were failing because the hashicg processors are loded in pulses with interruptios, as teh work is momentarily interrupted, the ATX PUS (Corsair) in question causes a spike in the supply voltage, which is short, but deadly. A combination of mechanical load, load current and tenmperature causes ultimately electrical breakdown of the input MLC capacitor.Has anyone pointed out that's a good suspect for the VRMs and caps failing?
Please not that only one specific PSU was doing this. The named ATX PSU was able to blow up a board that was completely OK with the coolermaster PSU.
Punin working with the BITFURY ASIC chip and C-SCAPE hardware design was also reporting that those caps were getting considerably hotter then they should on their 2nd batch modules.
Quote
Hardware:
We have encountered overheating issues with the capacitors placed in 4 groups of 8 between the chips on H-cards. This shouldn't affect any orders shipped in august. We have not had any serious issues apart that the caps run extremely hot (up to 250°C). This is clearly a malfunction and we're not sure what is causing this. There shouldn't be a risk of fire as these are ceramic capacitors, but we decided to try removing them. (They boards seem to actually work better without these caps Smiley
sourceWe have encountered overheating issues with the capacitors placed in 4 groups of 8 between the chips on H-cards. This shouldn't affect any orders shipped in august. We have not had any serious issues apart that the caps run extremely hot (up to 250°C). This is clearly a malfunction and we're not sure what is causing this. There shouldn't be a risk of fire as these are ceramic capacitors, but we decided to try removing them. (They boards seem to actually work better without these caps Smiley
https://bitcointalk.org/index.php?topic=250249.msg3247580;topicseen#msg3247580
explain this big guy
here is the one overclocked (I don't care how you define it, it is baking, running hot, or whatever, it is PRODUCING better)
and you can see it has one board with 8 VRMs and running cooler with .93 while the other 4 VRM boards are running hotter
so leave this thread ok?
/quote]
This is interesting, I see the 4-VRM module running cooler than the 8 VRM module why is that?
Coincidentally, are some of the boards in fromt while some are in the back, sucking the warm air from the boards that are in the front?
You are very good at trolling, sir!
here is the one overclocked (I don't care how you define it, it is baking, running hot, or whatever, it is PRODUCING better)
and you can see it has one board with 8 VRMs and running cooler with .93 while the other 4 VRM boards are running hotter
so leave this thread ok?
/quote]
This is interesting, I see the 4-VRM module running cooler than the 8 VRM module why is that?
Coincidentally, are some of the boards in fromt while some are in the back, sucking the warm air from the boards that are in the front?
You are very good at trolling, sir!
Jump to: