Yes Kano, Icarus does suck and I'd never use it for anything more than a single-chip stick miner. It worked for the BM1384 Compac that most everything was already in there, but any new Compacs and of course any full-scale miners will have proper drivers and control. I don't really understand most of the next thing you said but that's a "yet" - I don't understand it yet but know that I'll be spending a lot of time on that suggestion post and making sure the software people do too.

Phil - what's been requested is a 10TH miner, so if the assumption is current-gen chips in the 0.1J/GH neighborhood, then the assumption is 1KW at stock settings. Yes that's twice what I'd like, but yes it will be adjustable for undervolting/underclocking and yes the boards will be independent.

NotFuzzy - I get now what you were saying about control over TCP/IP. However, if all the miners are on a private network and your controller acts as a bridge, you'd need a controller with dual NICs. That rules out a lot of devboard computers like the Pi, and even most desktops that don't have a second NIC installed by the owner. If you wanted a single control machine to be able to handle n independent trees of miners, you'd have to build a computer with at least n+1 NICs. Am I understanding that right?

620mV@575 burns an extra 24 watts for an effective 41GH increase for a margin of 0.59J/GH by those numbers, because you lose so much hashrate to errors and instability. Better off staying at 550MHz. My criteria for maximum stable hashrate (which I used to generate the graph) was less than or equal to 0.01% HW errors, because I noticed past that threshold the hashrate would suffer noticeably - averaging 98% or less of expected versus 100% +/- 1%. Now maybe your miner will handle it, worth testing, but from what I've seen so far I don't expect it to work that well.

So maybe set up a core-charge/refund kind of thing? Interesting. That only really matters for the next generation, but it's interesting.

Right, but what's the cause? I'm really looking forward to getting back to rational stability instead of sitting around waiting to get hosed by speculators. Stability is good for a currency if it wants to actually be used as a currency instead of another random nonexistent traded asset for investors to jerk each other off with.

The post with the massive data table has been updated with even more data. It's okay, because right at the top I put a graph summarizing it all.

Holy balls, you're right. Coin's down like $80 (a solid 12%) from looking at it last night. What's up?

Anodize would be a good way to help prevent shorts that get around solder mask.

I think, given the zero-power-required-from-bus and pretty low throughputs required, stock-standard USB1.1 would be overkill. Something like USB-C is incredibly unnecessary for this application.

So... let me figure out that last paragraph. You want each board to have its own ethernet connection, all hub'd to a central controller running a single instance of cgminer/BFG to link to them all via network? I don't understand how that's in any way better (other than ground loops of course). Seems like getting the same thing as using USB or some multiplexed primitive, except now the software guys have to overlay everything on TCP/IP. The cgminer driver would have to ping-detect all the miners on the network (which could cause conflicts), or the miner would have to be pre-configured to find the host (which requires extra setup steps). It's interesting, but I'm not sold yet. Could be I don't fully understand.

Also consider that every "miner" will have probably two or three hashboards in it. Would each "miner" need 3 ethernet cables? Or are we talking hashboards to an internal control board with a single Ethernet? Because then the only difference between that and Antminers is cgminer would be centralized on a separate machine instead of internal to each miner.

Actually, I'll probably be applying ideas from this to my own "sidehack-alone" miner but the overarching project specific to this thread is more I am helping some people than some people are helping me - at least that's how it's supposed to be. Since it'll be me doing a job for someone else, I want that job done as best as possible, which includes questioning my own definition of "best" because there will always be cases I didn't think of where something I think is great might fail. I'm not in charge of finances at all, just design, and I want to make sure the design is up to the community's standards since y'all will hopefully be the customers.

This will not be a GekkoScience product, but regardless it needs to be solid and reliable.

Yeah, a wide range of operating points is a must.

I think in the two-sizes and 1/2 jacks part you missed the part where it'd be a single ~1KW miner. Within the context of this discussion there is no small miner and there is no miner that 2 jacks wouldn't immediately burst into flames on - unless you mean per board with a multi-board miner, but even then 3 jacks would be better for ~500W.

Quiet is relative, and also dependent heavily on the power consumption of the user setpoint as allowed in your second point.

If we're going USB, is it better to have an "internal daughter board" per machine that controls all internal hashboards, or relegate all board-level control to a microcontroller on the board and all boards connect to USB directly (either with an exposed port per board, or to an internal hub with single outgoing port)? I like the idea of direct USB connection to board-level control with no daughter board since, as you say, it removes one part from the list of minor things that can fail and take out the whole machine. One thing about direct control to boards is fan control - with multiple boards in a miner, which one drives the fan? What happens to the other boards if the fan-driving hashboard kicks out? It would be easy to have a jumper or DIP switch per board to designate as the "master", or just have each one attempt to kick on a fan and watch for tach response. It could also be possible to put a small controller on whatever internal hub is present, that controls fans for the whole machine, but at that point you're only one step away from the Avalon6 daughter board anyway. Maybe it's best to have a microcontroller on the board handling most things (convolving sensor readings, handling ASIC IO, setting voltage and measuring power use), but talking to a basic daughter board that multiplexes comms to all boards and also is a master control for the fan. This board needs to be simple and resilient, and ideally not requiring an FPGA to do its job.

And yes I understand a miner should be delivered on time and on target and be affordable. That applies to literally every manufactured good. What I'm asking about are evaluating pros and cons of specific design elements, like the ones laid out quite extensively right up there in the first post. And I only stopped there so there'd still be stuff to discuss next week. I don't mean to sound mean, but if you can't productively add to that discussion please don't post.

Just throwing this out there, but that's pretty freakin' not helpful at all obvious and simplistic surface-level suggestions.

Right, the picture I posted of the rear 3 pages back had the fan removed and was more showing the boards than the miner.

Everything on that cable is 3.3V or less. Nothing should be pulling enough current to do that kind of damage. I would guess either the hashboard backed power up that cable, or a switching regulator on your control board shot craps, the end result being a lot of probably 12V (or thereabouts) going through it. I'd be very surprised if the control board was functional or even repairable.

If you want to work it out with Phil, I'll just ship another unit to Phil at regular price (420/430) and you two can iron out the details however you want.

I'll post package dimensions here in a bit, once I start repacking the ones going out today.

Probably cheaper at that point to just track down a PIC programmer and learn how to do it yourself.

That's kinda how I see it. A blockchain as a means of reliably transferring and storing data in general isn't a bad idea. I just have never liked the idea of using one that already exists specifically set up to transfer currency data for other things.

Cycling the same rhetoric with the same jargon (left undefined or mostly unexplained) doesn't really do much good to convince me otherwise, and improper sentence structures difficult to parse accurately make it even worse. I hope he comes back with a well-thought-out, well-reasoned and informative response.

A shipping label can be created online and emailed to me.

Current cost is $420 BTC or $430 PayPal (to account for some of the fees they like to add). So if you're sending a label, $400/410

Well that works. 12 hours from now I'll be asleep and you can talk as much as you want.

If you want to cover postage from me to you, knock $20 off the GB price and send me a shipping label. I just didn't want to have to mess with bidding international transport and customs paperwork and using whoever's favorite carrier this week.