refund processing
Sweet! Better for me!
Topic: Swedish ASIC miner company kncminer.com - page 1826. (Read 3050071 times)
refund processing
how about all you nervous nelly's buy 15 different PSU's now and then return the ones that you don't need later?
In fact forget the miners.. get a refund and buy out ALLLLL the PSUs on the planet and gouge the miners?? =profit
In fact forget the miners.. get a refund and buy out ALLLLL the PSUs on the planet and gouge the miners?? =profit
£120 (Good quality PSU for example Corsair HX850)
That won't be enough. For Jupiter you would need to have at least HX1050 PSU (or better) to be on the safe side. ($240, £155)
Also, you forgot import taxes.
At least for Norway, that's 25% of the unit cost. Don't know about Sweden->UKEveryone please ignore this post. If you were to buy a HX1050 for a 1000W Jupiter, you would essentially be running at near 95% load.
That's why I said "at least" on the off-chance that Jupiter would draw around 800W instead of the pessimistic estimate of 1000W. Cyper's 850W was way off.
Agree with Bitcoinorama that we should wait for the final specs.
HX850 I linked has a headroom of more than 1000W. It is one of the best PSU on the market.
I used one for 4 months with a GPU miner consisting of 4x 5870 overclocked at 960Mhz Core.
Obviously I'm not recommending it for a 1000W miner, but if it's less I will consider it
£120 (Good quality PSU for example Corsair HX850)
That won't be enough. For Jupiter you would need to have at least HX1050 PSU (or better) to be on the safe side. ($240, £155)
Also, you forgot import taxes.
At least for Norway, that's 25% of the unit cost. Don't know about Sweden->UKEveryone please ignore this post. If you were to buy a HX1050 for a 1000W Jupiter, you would essentially be running at near 95% load.
That's why I said "at least" on the off-chance that Jupiter would draw around 800W instead of the pessimistic estimate of 1000W. Cyper's 850W was way off.
Agree with Bitcoinorama that we should wait for the final specs.
No challenge for me, just fun.
I did not claim that there is any stuck-at fault which will not be found by cgminer. This is of course the final end-to-end test. But that alone does not help you for compensating dead hashing cores by adjusting the chip frequency. This feature must be implemented in the miner firmware to guarantee 100 GH/s per chip. I also don’t doubt that KnC can handle this. The question is only how long it takes.
The Bitfury ASIC is a full-custom digital design, maybe they did things as mentioned by you.
The KnC ASIC is a standard semi-custom digital design, which means automatic RTL synthesis and place&route of the standard cells, done hopefully by an experienced design enablement partner of the foundry (not ORSoC) . So it is almost sure, that the supporting logic is implemented with the same 28nm standard cell lib as the hash cores. This is no problem, because the standard cell libs are most likely already silicon proven and showed good yield. But 100% yield are just impossible.
I’m not sure, if you are the right person to discuss any 28nm yield issues. How many 28nm ASICs did you characterize for yield over temperature and voltage in lab so far?
I did not claim that there is any stuck-at fault which will not be found by cgminer. This is of course the final end-to-end test. But that alone does not help you for compensating dead hashing cores by adjusting the chip frequency. This feature must be implemented in the miner firmware to guarantee 100 GH/s per chip. I also don’t doubt that KnC can handle this. The question is only how long it takes.
The Bitfury ASIC is a full-custom digital design, maybe they did things as mentioned by you.
The KnC ASIC is a standard semi-custom digital design, which means automatic RTL synthesis and place&route of the standard cells, done hopefully by an experienced design enablement partner of the foundry (not ORSoC) . So it is almost sure, that the supporting logic is implemented with the same 28nm standard cell lib as the hash cores. This is no problem, because the standard cell libs are most likely already silicon proven and showed good yield. But 100% yield are just impossible.
I’m not sure, if you are the right person to discuss any 28nm yield issues. How many 28nm ASICs did you characterize for yield over temperature and voltage in lab so far?
1) Fun is fine.
2) They have a whole "Embedded Linux SO-DIMM module" to handle initialization and self-test. Why waste even a single gate and single trace on dedicated test logic? Hopefully they included some sort of "clock disable" register to avoid wasting dynamic power on the engines that keep delivering erroneous nonces. This is such a trivial design that any undergrad could do that. I'm willing to give KnC the benefit of the doubt.
3) All standard-cell libraries that I've seen have some "high fanout", "high load", "low-skew clock" cells that are drawn much wider than the nominal feature size of the process. What are you trying to imply?
4) He, he. My 28nm e-peen has measure-zero. How many circuits have you implemented/characterized that had no JTAG chain (for a valid reason, not due to a fault) and were completely multi-way redundand, including power?
5) Extra-credit question for people who aren't engineers but have experience mining: how many mining devices/rigs you had that booted and started mining correctly, but kept failing after several hours or only in specific circumstances? Were you willing to consider them completely faulty and throw them away or were you willing to delve in and debug the problem? How many hours of "testing" was your cutoff time before you decided to throw that device away?
6) Extra-extra-credit question for engineers: What do you think about other engineers that have an obsesive-compulsive disorder about some testing methodology but have no practical experience running an actual bitmine?
Its called basic math. Have you ever brought a PSU? Read the manual, there are some charts and figures explaining load limits, noise and operating efficiency. Even running a platinum PSU at around 95% - 100% produces about 3% variance.
I would suggest you wait for official and final information on the Jupiter consumptions and then you can make such statements
So far we know it will consume less than 1000W
OK, maybe you should apply that to your original HX1050 post. And also:
The final specifications for this device are being ironed out now but we can confirm the following.
400GH/s per device.
28nm Standard ASIC
Maximum 1000w
Shipment begins in September
Yeah, good choice: HX1050 on a unit with a maximum 1000w.
Allow me to bring a piece of information that you have apparently missed
6/26/2013 1:44:00 PM
Quote
Power usage details
We have previously specified the power consumption of the Jupiter device at a 1000 watts. We have now received indication from our chip manufacturer that this may be lower.
This is where we need to refer you to our statement of under promise and over deliver.
So until you hear from us again on this, we would like to reaffirm that Jupiter will be less than 1000 watts and Saturn less than 500 watts.
We have previously specified the power consumption of the Jupiter device at a 1000 watts. We have now received indication from our chip manufacturer that this may be lower.
This is where we need to refer you to our statement of under promise and over deliver.
So until you hear from us again on this, we would like to reaffirm that Jupiter will be less than 1000 watts and Saturn less than 500 watts.
The top part of the figure has some control logic connecting the FPGA to the hashing cores to exchange data/midstace/nonce or whatever. Without access to the netlist it's not possible to analyze the probability of a single point of failure. I've seen cases of redundant logic which turned out to share some gates. Test tools can analyse your netlist and detect such potential failures. There are four different clock domains so there might be some synchronization logic in there, unless there are four separate channels with separate clock outputs, or an embedded clock. Again without access to the design one can only speculate. I can't see why KnC chose to skip this common design practice, even though a hasher itself is similar in nature to many BIST implementations even tough the signature checker will be on the device itself so I can be checked on the tester. It would have been better to do the testing on the chip tester and not struggle to figure out if the cause of the reduced hashing capacity is due to the ASIC chip itself or some other part of the miner. And you don't need to kill all four regions to reduce the capacity of the miner. If the yield is low it will be hard to prove to the vendor that this is due to the ASIC's and not something else.
Look, what you do here is called "concern trolling".You wrote: "Without access to the netlist it's not possible to analyze the probability of a single point of failure." No need to access anybody's netlist. Just access the critical thinking facilities. Everything is at least 4-way redundand: cores, I/O, clock and even voltage regulators. The only thing shared is ground.
You wrote "I can't see why KnC chose to skip this common design practice", while many other members of this forum, including bitfury, already wrote at length why the Bitcoin hasher is self-testing and why any advanced fault analysis is a waste of resources when 1% error rate on the output nonces is perfectly acceptable.
I'm not psychic so I can't see what possible dependencies are inside the top FPGA control interface. If the only thing in common is ground the yield analysis is like four independent chips. The main problem is that they don't do chip level testing. They don't utilize the "free BIST" and supplement it with coverage for the other part. When they see failure and lower hashing performance they will not know if it's due to chip fabrication problems or not.
Its called basic math. Have you ever brought a PSU? Read the manual, there are some charts and figures explaining load limits, noise and operating efficiency. Even running a platinum PSU at around 95% - 100% produces about 3% variance.
I would suggest you wait for official and final information on the Jupiter consumptions and then you can make such statements
So far we know it will consume less than 1000W
OK, maybe you should apply that to your original HX1050 post. And also:
The final specifications for this device are being ironed out now but we can confirm the following.
400GH/s per device.
28nm Standard ASIC
Maximum 1000w
Shipment begins in September
Yeah, good choice: HX1050 on a unit with a maximum 1000w.
The top part of the figure has some control logic connecting the FPGA to the hashing cores to exchange data/midstace/nonce or whatever. Without access to the netlist it's not possible to analyze the probability of a single point of failure. I've seen cases of redundant logic which turned out to share some gates. Test tools can analyse your netlist and detect such potential failures. There are four different clock domains so there might be some synchronization logic in there, unless there are four separate channels with separate clock outputs, or an embedded clock. Again without access to the design one can only speculate. I can't see why KnC chose to skip this common design practice, even though a hasher itself is similar in nature to many BIST implementations even tough the signature checker will be on the device itself so I can be checked on the tester. It would have been better to do the testing on the chip tester and not struggle to figure out if the cause of the reduced hashing capacity is due to the ASIC chip itself or some other part of the miner. And you don't need to kill all four regions to reduce the capacity of the miner. If the yield is low it will be hard to prove to the vendor that this is due to the ASIC's and not something else.
Look, what you do here is called "concern trolling".You wrote: "Without access to the netlist it's not possible to analyze the probability of a single point of failure." No need to access anybody's netlist. Just access the critical thinking facilities. Everything is at least 4-way redundand: cores, I/O, clock and even voltage regulators. The only thing shared is ground.
You wrote "I can't see why KnC chose to skip this common design practice", while many other members of this forum, including bitfury, already wrote at length why the Bitcoin hasher is self-testing and why any advanced fault analysis is a waste of resources when 1% error rate on the output nonces is perfectly acceptable.
What are those mysterious dark shadows inside the case on the right?...
Is that possibly a pcb I see hiding in there?
Just to "Stirr the Pot" a bit...
lol, get your eyes checked old man! hahahaha
I just realized the front of the KNC box looks kind of like a goofy robot face - fans as eyes and the power/io slot as a mouth.
Nice, they had this in 1600x900 at least for a background as well.
+1 for the futurama reference.
Its called basic math. Have you ever brought a PSU? Read the manual, there are some charts and figures explaining load limits, noise and operating efficiency. Even running a platinum PSU at around 95% - 100% produces about 3% variance.
I would suggest you wait for official and final information on the Jupiter consumptions and then you can make such statements
So far we know it will consume less than 1000W
Most likely this will be stuck-at faults in some of the hash cores (which could be easily detected by a BIST or ATPG tests).
Go ahead, make my day. Take the challenge. Run your ATPG toolset and come up with a "stuck-at" fault vector that will not be detected by the HW-error code in the cgminer. What are you trying to show?The "yield issue" for "a large 28nm" chip is a bullshit concern from people who don't understand that one can't take data from chips implementing single, hyper-complex circuit like CPU or GPU and apply it to a repetitive chip that doesn't even have a JTAG chain. I discussed it already a couple of days ago.
Edit: It was in this very thread: https://bitcointalksearch.org/topic/m.2723643 . End of edit.
Rest your post about what is the real available "margin upon margins" is definitely a valid concern, but it is too early to really quantify that. Bitfury disclosed how he had dealt with it: hashing cores are 55nm but the unique control logic is drawn much wider (150nm?), all using the same 65nm nominal process. I'm going to give KnC designers benefit of the doubt and assume that they were skilled enough to use similar design methodology in their 28nm-nominal design.
No challenge for me, just fun.
I did not claim that there is any stuck-at fault which will not be found by cgminer. This is of course the final end-to-end test. But that alone does not help you for compensating dead hashing cores by adjusting the chip frequency. This feature must be implemented in the miner firmware to guarantee 100 GH/s per chip. I also don’t doubt that KnC can handle this. The question is only how long it takes.
The Bitfury ASIC is a full-custom digital design, maybe they did things as mentioned by you.
The KnC ASIC is a standard semi-custom digital design, which means automatic RTL synthesis and place&route of the standard cells, done hopefully by an experienced design enablement partner of the foundry (not ORSoC) . So it is almost sure, that the supporting logic is implemented with the same 28nm standard cell lib as the hash cores. This is no problem, because the standard cell libs are most likely already silicon proven and showed good yield. But 100% yield are just impossible.
I’m not sure, if you are the right person to discuss any 28nm yield issues. How many 28nm ASICs did you characterize for yield over temperature and voltage in lab so far?
£120 (Good quality PSU for example Corsair HX850)
That won't be enough. For Jupiter you would need to have at least HX1050 PSU (or better) to be on the safe side. ($240, £155)
Also, you forgot import taxes.
At least for Norway, that's 25% of the unit cost. Don't know about Sweden->UKEveryone please ignore this post. If you were to buy a HX1050 for a 1000W Jupiter, you would essentially be running at near 95% load.
How did you come to this conclusion?
Its called basic math. Have you ever brought a PSU? Read the manual, there are some charts and figures explaining load limits, noise and operating efficiency. Even running a platinum PSU at around 95% - 100% produces about 3% variance.
£120 (Good quality PSU for example Corsair HX850)
That won't be enough. For Jupiter you would need to have at least HX1050 PSU (or better) to be on the safe side. ($240, £155)
Also, you forgot import taxes.
At least for Norway, that's 25% of the unit cost. Don't know about Sweden->UKEveryone please ignore this post. If you were to buy a HX1050 for a 1000W Jupiter, you would essentially be running at near 95% load.
How did you come to this conclusion?
£120 (Good quality PSU for example Corsair HX850)
That won't be enough. For Jupiter you would need to have at least HX1050 PSU (or better) to be on the safe side. ($240, £155)
Also, you forgot import taxes.
At least for Norway, that's 25% of the unit cost. Don't know about Sweden->UKEveryone please ignore this post. If you were to buy a HX1050 for a 1000W Jupiter, you would essentially be running at near 95% load.
What are those mysterious dark shadows inside the case on the right?...
Is that possibly a pcb I see hiding in there?
Just to "Stirr the Pot" a bit...
lol, get your eyes checked old man! hahahaha
I just realized the front of the KNC box looks kind of like a goofy robot face - fans as eyes and the power/io slot as a mouth.
I'm totally calling my new miner bender
What would be a minimum required size of a "single defect" that would kill all 4 regions?
The top part of the figure has some control logic connecting the FPGA to the hashing cores to exchange data/midstace/nonce or whatever. Without access to the netlist it's not possible to analyze the probability of a single point of failure. I've seen cases of redundant logic which turned out to share some gates. Test tools can analyse your netlist and detect such potential failures. There are four different clock domains so there might be some synchronization logic in there, unless there are four separate channels with separate clock outputs, or an embedded clock. Again without access to the design one can only speculate. I can't see why KnC chose to skip this common design practice, even though a hasher itself is similar in nature to many BIST implementations even tough the signature checker will be on the device itself so I can be checked on the tester. It would have been better to do the testing on the chip tester and not struggle to figure out if the cause of the reduced hashing capacity is due to the ASIC chip itself or some other part of the miner. And you don't need to kill all four regions to reduce the capacity of the miner. If the yield is low it will be hard to prove to the vendor that this is due to the ASIC's and not something else.
What are those mysterious dark shadows inside the case on the right?...
Is that possibly a pcb I see hiding in there?
Just to "Stirr the Pot" a bit...
lol, get your eyes checked old man! hahahaha
I just realized the front of the KNC box looks kind of like a goofy robot face - fans as eyes and the power/io slot as a mouth.
Most likely this will be stuck-at faults in some of the hash cores (which could be easily detected by a BIST or ATPG tests).
Go ahead, make my day. Take the challenge. Run your ATPG toolset and come up with a "stuck-at" fault vector that will not be detected by the HW-error code in the cgminer. What are you trying to show?The "yield issue" for "a large 28nm" chip is a bullshit concern from people who don't understand that one can't take data from chips implementing single, hyper-complex circuit like CPU or GPU and apply it to a repetitive chip that doesn't even have a JTAG chain. I discussed it already a couple of days ago.
Edit: It was in this very thread: https://bitcointalksearch.org/topic/m.2723643 . End of edit.
Rest your post about what is the real available "margin upon margins" is definitely a valid concern, but it is too early to really quantify that. Bitfury disclosed how he had dealt with it: hashing cores are 55nm but the unique control logic is drawn much wider (150nm?), all using the same 65nm nominal process. I'm going to give KnC designers benefit of the doubt and assume that they were skilled enough to use similar design methodology in their 28nm-nominal design.
Jump to: