|
FUKT
|
 |
August 16, 2013, 10:00:21 PM |
|
£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->UK Everyone 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. |
|
|
|
|
|
|
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
HyperMega
|
|
August 16, 2013, 10:02:31 PM |
|
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://bitcointalk.org/index.php?topic=170332.msg2723643#msg2723643 . 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? |
|
|
|
|
|
CYPER
|
|
August 16, 2013, 10:10:37 PM |
|
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 |
|
|
|
|
|
greenbtc
|
|
August 16, 2013, 10:21:46 PM |
|
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. Well spotted. Bender is a bitcoin miner! VVVVVVVVVVVVV  Nice, they had this in 1600x900 at least for a background as well. +1 for the futurama reference. |
|
|
|
|
2112
Legendary
 Offline
Activity: 2128
Merit: 1065
|
|
August 16, 2013, 10:23:00 PM |
|
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. |
|
|
|
|
FUKT
|
|
August 16, 2013, 10:24:06 PM |
|
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 1000wShipment begins in September Yeah, good choice: HX1050 on a unit with a maximum 1000w. |
|
|
|
|
|
kingcoin
|
|
August 16, 2013, 10:44:55 PM |
|
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. |
|
|
|
|
|
CYPER
|
|
August 16, 2013, 10:53:04 PM |
|
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 1000wShipment 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 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.
|
|
|
|
|
2112
Legendary
Offline
Activity: 2128
Merit: 1065
|
|
August 16, 2013, 10:53:31 PM |
|
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? 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? |
|
|
|
Nemo1024
Legendary
Offline
Activity: 1680
Merit: 1014
|
|
August 16, 2013, 11:05:59 PM |
|
£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->UK Everyone 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. |
“Dark times lie ahead of us and there will be a time when we must choose between what is easy and what is right.”
“We are only as strong as we are united, as weak as we are divided.”
“It is important to fight and fight again, and keep fighting, for only then can evil be kept at bay, though never quite eradicated.”
|
|
|
|
CYPER
|
|
August 16, 2013, 11:12:18 PM |
|
£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->UK Everyone 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 |
|
|
|
|
|
DPoS
|
|
August 17, 2013, 01:14:01 AM |
|
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
|
|
|
|
|
JohnyBigs
|
|
August 17, 2013, 04:35:37 AM |
|
refund processing
|
|
|
|
|
ASIC-K
Sr. Member
Offline
Activity: 280
Merit: 250
Hell?
|
|
August 17, 2013, 04:38:34 AM |
|
refund processing
Sweet! Better for me!  |
|
|
|
|
ur0pl
Newbie
Offline
Activity: 56
Merit: 0
|
|
August 17, 2013, 04:42:04 AM |
|
If you get a refund, then where are you going to put all your money? It gotta be somewhere
Please message me if you are looking for a refund, I would be willing to buy your order position from you.
|
|
|
|
|
|
jmevz
|
|
August 17, 2013, 04:45:28 AM |
|
I want my machine already  Wonder why the larger units are shipping before the smaller? I could do some research I guess... |
|
|
|
Phoenix1969
Legendary
Offline
Activity: 938
Merit: 1000
LIR DEV
|
|
August 17, 2013, 04:48:08 AM |
|
Because they are shipped by order payment date, and Mercury wasn't offered till later
|
|
|
|
|
joae1975
|
|
August 17, 2013, 04:50:00 AM |
|
refund processing
Cool! Difficulty will be one unit less. thanks! |
1PewuG8KZJUPK3CtvAkAs1Uw42rQgUv5Jk
|
|
|
ur0pl
Newbie
Offline
Activity: 56
Merit: 0
|
|
August 17, 2013, 05:09:16 AM |
|
Do you guys think it is sound that kncminer should offer a option to buy miners for November delivery, at a discount. For them to offer that now instead of when October is sold out. I would like to buy a miner, but I dont want it to be so close to November that I was a few days off from a cheaper price. I rather have a firm delivery date, like early November, than Late October with a higher price.
|
|
|
|
|
|
DPoS
|
|
August 17, 2013, 05:50:31 AM |
|
Do you guys think it is sound that kncminer should offer a option to buy miners for November delivery, at a discount. For them to offer that now instead of when October is sold out. I would like to buy a miner, but I dont want it to be so close to November that I was a few days off from a cheaper price. I rather have a firm delivery date, like early November, than Late October with a higher price.
so you rather them not tell anyone and pull a fast one come nov? they really cant win so they are trying to bring the win/win as close as someone can try to make it.. |
|
|
|
|
