Swedish ASIC miner company kncminer.com

[isimme]

https://www.kncminer.com/categories/miners

Neptune Second Batch
41
Neptune is our first 20nm product and will be shipping in Q2 of 2014. This order is for the second batch which will leave about one month after the first batch
The stats and performance that we can release today are
Minimum 3000GH/s of hashing speed that 3TH Over 5 times the speed of our first Jupiter release
   (we reserve the right to increase this as we get closer to shipment)
A 30% reduction in watts per GH
Based on the existing Jupiter design (See photo, however this may change as development progresses)
Shipment begins in Q2 of 2014
Bitcoins first ever 20nm miner brought to you form the company who shipped the first 28nm bitcoin miner
Limited batch of 1200 units,
Payment for this product is bitcoins and bank transfer only.
$ 9,995.00

[1713499110]

1713499110

[flexgroo]

I am putting my order in now, just got the email from KNC telling me about the second batch, they say it should be delivered about 1 month after the first batch...

anyone have any idea on the diff by then? im guessing Apr maybe May... or should i just spend the 10k on btc, lol

[de_ixie]

I am confused - should be named 3rd batch - not second 

[jelin1984]

Any news about knc new firmware??

[helmax]

wht sells again?

like i say knc is kidding with us and our money

where network protection

where is 3000$ more other batch now is 10000

3600 machines

maybe are right calculation by other member we only get 7 bitcoins

mining is out control

[CYPER]

Thanks.
How many of these should I see in the list?

  323 root      2148 S    udhcpc -b -x hostname Jupiter-1 eth0
14003 root      2152 S    grep dhcp
29312 root      2148 S    udhcpc -b -x hostname Jupiter-1 eth0

I think that one is enough. you should kill the one with the lower pid. But i'd prefer if you check it with someone else that is using the dhcp network settings.

usually there's only one dhclient for each network interface. If I were you I would simply reboot the miner and check how many udhcpc will be running.

but i'd dare to say that you could do this the next time a network glitch appear, this way you could use the downtime to test this solution without wasting mining time.

Thank you. I posted my problem at my ISP forum and someone suggested a possible solution where Static IP addresses would not get changed by the router - I should set Static IP addresses that are not in the DHCP pool - anything below .64:

[r1senfa17h]

I've put up a new binary for knc devices based on the new cgminer 3.9.0 that has some fixes for the high hw error on rEligius problem people are having. Note it's not comprehensively better, and to make it work even better, it is much more reliable if you start cgminer with the extra options -q -T (quiet and text only).

http://ck.kolivas.org/apps/cgminer/kncminer/cgminer

I've noticed higher hashrates overall with this binary, along with substantially lower hardware error rates especially across block changes on any pool.

Thanks ckolivas! I've been running this for about 30 minutes on Eligius and it appears to have taken the HW error rate on my 6-module October Jupiter from 2.2% to 1.8%. I also like that the reported GH/s seems to line up much better with the WU, which means I should see the same hashrate at the pool as reported by cgminer .

[bobsag3]

Out of 6 nov jupiters, I now have 3 dead moduals, and a completely dead Jupiter. RMA is pretty fast... but Ill be down almost $1k in shipping by the time this is done. Seriously thinking about just chaging back the dead one... Not worth it after 2 weeks dead then another 3 weeks in RMA.

[CYPER]

Out of 6 nov jupiters, I now have 3 dead moduals, and a completely dead Jupiter. RMA is pretty fast... but Ill be down almost $1k in shipping by the time this is done. Seriously thinking about just chaging back the dead one... Not worth it after 2 weeks dead then another 3 weeks in RMA.

They make you pay for shipping?

[bobsag3]

Out of 6 nov jupiters, I now have 3 dead moduals, and a completely dead Jupiter. RMA is pretty fast... but Ill be down almost $1k in shipping by the time this is done. Seriously thinking about just chaging back the dead one... Not worth it after 2 weeks dead then another 3 weeks in RMA.

They make you pay for shipping?

$100 per module back to sweden for each, then they want me to ship the entire Jupiter back that wont work. I don't even have RMA numbers for the last module yet.

[CYPER]

Out of 6 nov jupiters, I now have 3 dead moduals, and a completely dead Jupiter. RMA is pretty fast... but Ill be down almost $1k in shipping by the time this is done. Seriously thinking about just chaging back the dead one... Not worth it after 2 weeks dead then another 3 weeks in RMA.

They make you pay for shipping?

$100 per module back to sweden for each, then they want me to ship the entire Jupiter back that wont work. I don't even have RMA numbers for the last module yet.

Hm, I never knew they segregate customers like that. All I know is that us people in Europe don't pay for return shipping.
Have you asked them about this?

[bobsag3]

Out of 6 nov jupiters, I now have 3 dead moduals, and a completely dead Jupiter. RMA is pretty fast... but Ill be down almost $1k in shipping by the time this is done. Seriously thinking about just chaging back the dead one... Not worth it after 2 weeks dead then another 3 weeks in RMA.

They make you pay for shipping?

$100 per module back to sweden for each, then they want me to ship the entire Jupiter back that wont work. I don't even have RMA numbers for the last module yet.

Hm, I never knew they segregate customers like that. All I know is that us people in Europe don't pay for return shipping.
Have you asked them about this?

from them:

"We can see that there is an issue with your whole miner.

Please write in large writing on the box RMA 131223-08 and send the entire miner back to the following address:

KnCMiner
Birger Jarlsgatan 33
11145 Stockholm
Sweden

The shipping cost to us will need to be paid by customer and we will pay for the shipping cost back. Please declare value as 1000 US dollar."

And In the past I asked- never answered. Not only do they want me to pay return shipping, but also to undermark the customs. Pretty sure its illegal to do that... not happy with a establish company asking me to do that.

[ASIC-K]

Out of 6 nov jupiters, I now have 3 dead moduals, and a completely dead Jupiter. RMA is pretty fast... but Ill be down almost $1k in shipping by the time this is done. Seriously thinking about just chaging back the dead one... Not worth it after 2 weeks dead then another 3 weeks in RMA.

They make you pay for shipping?

$100 per module back to sweden for each, then they want me to ship the entire Jupiter back that wont work. I don't even have RMA numbers for the last module yet.

Hm, I never knew they segregate customers like that. All I know is that us people in Europe don't pay for return shipping.
Have you asked them about this?

from them:

"We can see that there is an issue with your whole miner.

Please write in large writing on the box RMA 131223-08 and send the entire miner back to the following address:

KnCMiner
Birger Jarlsgatan 33
11145 Stockholm
Sweden

The shipping cost to us will need to be paid by customer and we will pay for the shipping cost back. Please declare value as 1000 US dollar."

And In the past I asked- never answered. Not only do they want me to pay return shipping, but also to undermark the customs. Pretty sure its illegal to do that... not happy with a establish company asking me to do that.

wow, that is very unprofessional.... surprise surprise

[Bitcoinorama]

There will be a tuning suite for Nov, but not this side of Jan, as everything there is winding down. There's just some ongoing Neptune work. There will also be the means to vary SPI clock frequency. I saw it in the original tuning suite as a feature, but that hadn't been developed into the recent release. It was purely part of a template I saw.

Can you please elaborate on what that option does as I believe many of us are just changing values without knowing what they actually do  
The voltage settings are clear, but the SPI voltage and frequency not so much. I know they are related to the communication between each board and the controller board, so do they increase the signal to noise ratio or am I talking rubbish  

By changing the voltage you are altering the power consumption and the noise to signal ratio (communication error rate - although reported by CGMiner as hardware errors they are not actual hardware errors so don't worry)

The less voltage the higher noise to signal ratio, the higher the probability of hardware errors.

The greater the voltage the less noise to signal ratio, the smaller the probability of hardware errors.

The higher the frequency, again the higher noise to signal ratio, which is not what you want.

If the SPI frequency is too low then there is not enough bandwidth to collect all the good nonces found. So you want to find an equilibrium where by SPI frequency is high enough not to miss any of the nonces found, but low enough to retain a healthy noise to signal ratio and thus minimise hardware errors.

Also, my bad, the future firmware update is not about SPI frequency, it's about configuring the PLL settings, which is directly correlated with the hashing speed as you are directly altering the clock speed of the die.

The SPI is not the hashing speed, but the speed of the communication between the dies and the controller board.

Hope that clears things up bud, and Merry Christmas, or if you're not into all that happy holidays all the same.

[bobsag3]

Out of 6 nov jupiters, I now have 3 dead moduals, and a completely dead Jupiter. RMA is pretty fast... but Ill be down almost $1k in shipping by the time this is done. Seriously thinking about just chaging back the dead one... Not worth it after 2 weeks dead then another 3 weeks in RMA.

They make you pay for shipping?

$100 per module back to sweden for each, then they want me to ship the entire Jupiter back that wont work. I don't even have RMA numbers for the last module yet.

That's strange, they gave me a paid-for shipping label sent with the RMA number when I got mine. Let us know if they do the same when you get your RMA #.

I have the RMA numbers for 1 module, and the entire Jupiter. Neither was provided with a label, and both asked me to pay for it and mark the customs down.

[r1senfa17h]

Out of 6 nov jupiters, I now have 3 dead moduals, and a completely dead Jupiter. RMA is pretty fast... but Ill be down almost $1k in shipping by the time this is done. Seriously thinking about just chaging back the dead one... Not worth it after 2 weeks dead then another 3 weeks in RMA.

They make you pay for shipping?

$100 per module back to sweden for each, then they want me to ship the entire Jupiter back that wont work. I don't even have RMA numbers for the last module yet.

That's strange, they gave me a paid-for shipping label sent with the RMA number when I got mine. Let us know if they do the same when you get your RMA #.

I have the RMA numbers for 1 module, and the entire Jupiter. Neither was provided with a label, and both asked me to pay for it and mark the customs down.

You should definitely point this out to them before moving forward. I would expect nothing less than free-shipping while the product is still under warranty.

[sickpig]

Thanks.
How many of these should I see in the list?

  323 root      2148 S    udhcpc -b -x hostname Jupiter-1 eth0
14003 root      2152 S    grep dhcp
29312 root      2148 S    udhcpc -b -x hostname Jupiter-1 eth0

I think that one is enough. you should kill the one with the lower pid. But i'd prefer if you check it with someone else that is using the dhcp network settings.

usually there's only one dhclient for each network interface. If I were you I would simply reboot the miner and check how many udhcpc will be running.

but i'd dare to say that you could do this the next time a network glitch appear, this way you could use the downtime to test this solution without wasting mining time.

Thank you. I posted my problem at my ISP forum and someone suggested a possible solution where Static IP addresses would not get changed by the router - I should set Static IP addresses that are not in the DHCP pool - anything below .64:

https://i.imgur.com/3giMtIs.png

so you have set a static IP that belongs to your dhcp address pool, right?

the fact is that if you did not have any dhcp client hanging around there's no way that the BBB let the dhcp server change its own static ip address.

now that I've checked better /www/pages/cgi-bin/network.cgi  I've found that there's also an avhai deamon involved... 
 

[bobsag3]

Out of 6 nov jupiters, I now have 3 dead moduals, and a completely dead Jupiter. RMA is pretty fast... but Ill be down almost $1k in shipping by the time this is done. Seriously thinking about just chaging back the dead one... Not worth it after 2 weeks dead then another 3 weeks in RMA.

They make you pay for shipping?

$100 per module back to sweden for each, then they want me to ship the entire Jupiter back that wont work. I don't even have RMA numbers for the last module yet.

That's strange, they gave me a paid-for shipping label sent with the RMA number when I got mine. Let us know if they do the same when you get your RMA #.

I have the RMA numbers for 1 module, and the entire Jupiter. Neither was provided with a label, and both asked me to pay for it and mark the customs down.

You should definitely point this out to them before moving forward. I would expect nothing less than free-shipping while the product is still under warranty.

And as I stated before- I have asked and never be answered? Its a catch 22- either I pay to sent it back, or fight with them and lose hashing time.

[CYPER]

There will be a tuning suite for Nov, but not this side of Jan, as everything there is winding down. There's just some ongoing Neptune work. There will also be the means to vary SPI clock frequency. I saw it in the original tuning suite as a feature, but that hadn't been developed into the recent release. It was purely part of a template I saw.

Can you please elaborate on what that option does as I believe many of us are just changing values without knowing what they actually do  
The voltage settings are clear, but the SPI voltage and frequency not so much. I know they are related to the communication between each board and the controller board, so do they increase the signal to noise ratio or am I talking rubbish  

By changing the voltage you are altering the power consumption and the noise to signal ratio (communication error rate - although reported by CGMiner as hardware errors they are not actual hardware errors so don't worry)

The less voltage the higher noise to signal ratio, the higher the probability of hardware errors.

The greater the voltage the less noise to signal ratio, the smaller the probability of hardware errors.

The higher the frequency, again the higher noise to signal ratio, which is not what you want.

If the SPI frequency is too low then there is not enough bandwidth to collect all the good nonces found. So you want to find an equilibrium where by SPI frequency is high enough not to miss any of the nonces found, but low enough to retain a healthy noise to signal ratio and thus minimise hardware errors.

Also, my bad, the future firmware update is not about SPI frequency, it's about configuring the PLL settings, which is directly correlated with the hashing speed as you are directly altering the clock speed of the die.

The SPI is not the hashing speed, but the speed of the communication between the dies and the controller board.

Hope that clears things up bud, and Merry Christmas, or if you're not into all that happy holidays all the same.

Thanks for the info
I have one other concern in relation to changing certain hex values, that increase some other values, that lead to increased hashrate   which bothers me lately: according to one KNC engineer, which I met in person   anything above 50Amps per VRM is considered not safe for long term usage. Or 200Amps per board. He wasn't very clear about it. Yet the 0.99 Tune firmware has the option to increase the current per VRM up to 64Amps, which brings the question: if over 50Amps is considered not safe, why then we have 64Amps at our disposal?
What is considered safe? Judging by the latest firmware I would assume 64Amps to be safe or at least any logical, non-technical person would believe that as it is included in the Advanced tab options.

Happy holidays and don't drink too much   We need you back here in the new year  

[CYPER]

Thanks.
How many of these should I see in the list?

  323 root      2148 S    udhcpc -b -x hostname Jupiter-1 eth0
14003 root      2152 S    grep dhcp
29312 root      2148 S    udhcpc -b -x hostname Jupiter-1 eth0

I think that one is enough. you should kill the one with the lower pid. But i'd prefer if you check it with someone else that is using the dhcp network settings.

usually there's only one dhclient for each network interface. If I were you I would simply reboot the miner and check how many udhcpc will be running.

but i'd dare to say that you could do this the next time a network glitch appear, this way you could use the downtime to test this solution without wasting mining time.

Thank you. I posted my problem at my ISP forum and someone suggested a possible solution where Static IP addresses would not get changed by the router - I should set Static IP addresses that are not in the DHCP pool - anything below .64:

https://i.imgur.com/3giMtIs.png

so you have set a static IP that belongs to your dhcp address pool, right?

the fact is that if you did not have any dhcp client hanging around there's no way that the BBB let the dhcp server change its own static ip address.

now that I've checked better /www/pages/cgi-bin/network.cgi  I've found that there's also an avhai deamon involved... 
 

Yes, before when I tried using the Static way. But once in a while the IP address of a random Jupiter would change and so I decided to go the other route, which was manually editing the DHCP table via telnet - I just gave my miners Indefinite lease time on their IP addresses. Fast forward to 2 days ago, when all of them started to disappear from my network all of a sudden.
If it happens again I will just set them Static again, but outside the DHCP pool range.