Community brainpan - please discuss and debate desirable features for a miner

[sidehack]

So, folks who know me on here know I have an interest in miner design. I have my ideas on how to do things and what is "good" and "not good", but plenty of other people also have their own ideas.

So I would like, if possible, to use this thread to facilitate civilised debate over possible features for a consumer-grade miner. Let's assume the machine sits in the spectrum of Avalon6 and S7 for general size and power consumption. Those attributes are fixed.

I'd like to see what the community consensus is about such items as integrated controllers (like Bitmain) versus external chainable controllers (like Avalon uses), or using purpose-designed cabling and protocols (lke Bitmain) versus a more generic bus (like ASICMiner's UART or Rockminer's USB) to connect. What do we want to see for power interfacing, or voltage control? Should hashboards have sub-controllers or be dumb and driven directly by the central controller? Stuff like that.

Partly I'm interested to see where my own ideas line up with the community at large, and partly I want to draw from the collective (and collectively overwhelming) variety of expertise present here, the end result of which should assist in designing an actual miner with the hopes that it's "the best". That part of the goal should be no surprise to anyone.

So, let's start today's discussion and start picking things apart.


I like the single-fan tube concept of the Avalon6, but would like to see heatsinks on both sides of the board. This isn't always possible, and with a string-topology miner can become dangerous. However, in designs like the A1 Dragon and AntMiner S3, having chip-side and PCB-side heatsinks allowed for efficient heat transfer without a lot of fan noise. Does the decreased Tca outweigh the risk of failure due to electrical short circuits through the PCB-side heatsink, and the extra milling requirements of at least one of the heatsinks to avoid contact with other components?

I like the daisy-chaining concept that Avalon used in the -4 and -6 machines. I'm not overly fond of the required USB dongle signal converter, and would prefer to keep operating requirements a bit simpler. Jstefanop mentioned some weeks ago an idea to make small (~20W) miners with USB connectivity, and each daisy-chainable. That would require a 2-output hub chip in each miner, which is definitely fun but I'm not sure if that's better than just using a hub. I think star topology afforded by a hub would be better (certainly more fault-tolerant) than a daisychain of miners. Does the availability and affordability of USB hubs and cabling, and the maintainability and fault-tolerance of a tree layout versus chaining, outweigh the potential software and hardware overhead (and physical connection reliability concerns) of using USB versus a more primitive protocol for miner interconnection?

Any chaining like this will only matter if the miner uses an external controller. This reduces overhead for a fleet of miners, and makes administration easier (with a single point of access). However, the controller becomes a single point of failure for what could be a fairly large operation, and distributed control software leveraging cgminer API functions already exists. Does the ease of administration, ease of replacement, and general reduction in equipment overhead for a single central controller outweigh the cost of single-point failure? Is it better to have a completely self-contained controller (like seen on Antminers, requiring only a network connection) in every miner unit?

If using an external controller, higher-level protocol or not, it makes sense to have an intermediary microcontroller on the hashboard (or, in the case of Avalon6, on a separate board that talks to the hashboards directly) which handles all upstream communication, and multiplexes chip-bound data, fan control and sensor reading. Would it make sense to have this integrated at the board level even if the miner has a self-contained controller? This increases board-level hardware complexity, but can also add features like semi-autonomous fan control in emergency situations when the controller software is exhibiting erratic behavior (for example, S5 overheats). It could also be responsible for implementing changes at the board's voltage regulators, in the case that adjustable core voltage is desired; you cannot convince me adjustable core voltage is not a mandatory feature, so something will need to do it.

So, lets get started.

[1714954582]

1714954582

[1714954582]

1714954582

[1714954582]

1714954582

[1714954582]

1714954582

[1714954582]

1714954582

[1714954582]

1714954582

[Unacceptable]

Just keep it as simple & cheap & as easy to use as possible 

[jojo69]

actually delivered on time and on spec

[sidehack]

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

[jojo69]

lol, sorry

though that IS really the ONLY thing that matters

FWIW what I want is a 4u unit in the 1200-1500W range, as far as internal topology I could seriously not give a fuck, though I imagine that 3X2 120mm fan tunnels would be the most likely solution

[sidehack]

Let's assume the machine sits in the spectrum of Avalon6 and S7 for general size and power consumption. Those attributes are fixed.

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.

[dogie]

Wasn't there a similarly named thread with pages of answers you could draw from?

[philipma1957]

okay  lets go for practical or what a home miner wants.



1) quiet first
2) wide  efficiency ranges as in watts per gh    the sp20  had a big range  .48 watts for low clock say 950gh   and .70 watts for high clock say 1400gh
3) the dongle on the avalon is a pita for 1 reason not easy to get it if it dies.  same for the internal daughter board.
4) so flexable hub  ie any powered hub usb2 or usb3
5) simple easy bullet proof miner usb part.  Ie  you don't replace it. like the s-7 the av6
6) rasp pi to hub to multiple miners
7)  two types of miners

  say 3 chip 6 chip or 6 chip 12 chip or 12 chip 24 chip

make the small miner use 1 six pin pcie wire
make the big miner use 2 six pin pcie wire.

bolded this  as it works well with your server psu's

I like the idea of  being able to do  two sizes  a lot  one using 1 six pin pcie jacks the other using 2 pcie jacks.
I like real efficiency flexibility.


I like the idea of toss out the rasp pi if it dies fast replacement
I like the idea of everything can be replaced

other then a plug in miner   and if you have 2 small and 2 big  only 1 miner dies.

  say the 75 watt one does 300gh the 150 watt one does 600gh since we are talking s-7 or avalon6

or make the two 600gh at 150 watt  and 1200gh at 300 watt

Make 10 or 20 connections the max

[sidehack]

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.

[jojo69]

I DO like the idea of wide efficiency ranges with clocks/voltages!

I have my rack built into my furnace cold air return, being able to downclock/volt in the summer and go insane in the winter would be a huge plus

[sidehack]

...you cannot convince me adjustable core voltage is not a mandatory feature...

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

[2112]

I'm reading this post as implicitly stating that you are going to have some people helping you with procurement, manufacture and distribution. So it won't be "sidehack"-alone project, but some other folks will be working closely with you.

In that case get one of those people interested in verifying how to apply regular bank financing in your project. The regular way for small businesses to manufacture made-to-order stuff is via https://en.wikipedia.org/wiki/Letter_of_credit . The buyers will not be able to gratuitously back out of orders and you will be able to order parts and components on the regular commercial net terms instead of prepaying for them.

The Wikipedia article I linked is not a good description of the concept. It is best to find somebody who isn't afraid to step into the branch and directly talk to somebody in merchant services. I presume that "GekkoScience" is an actual proper registered business entity and not just and expense code on sidehack's personal bank account. Also, the letters of credit require funding, which would fall onto hand of the group buy organizers, but it is much easier to set up than receiving and holding letters of credit.

[sidehack]

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.

[NotFuzzyWarm]

Ok...

1) Does the decreased Tca outweigh the risk of failure due to electrical short circuits through the PCB-side heatsink, and the extra milling requirements of at least one of the heatsinks to avoid contact with other components?

To me the increased cooling is DEFINITELY worth it. CNC milling keeps addition costs low - and will probably be used anyway for drilling/tapping bolt holes so should be minor concern as long as the CNC has tool changers. Plus - if the heatsinks are seen -- anodize them -- most colors of the rainbow are available plus it forms very durable insulator.

2) Does the availability and affordability of USB hubs and cabling, and the maintainability and fault-tolerance of a tree layout versus chaining, outweigh the potential software and hardware overhead (and physical connection reliability concerns) of using USB versus a more primitive protocol for miner interconnection?

Given the plethora of crappy USB hubs and cables out there -- hell no! But - if USB is in the mix and say a time frame of around Fall or later - look into USB-C. Good for 10's of watts, no upside-down to cabling, astonishing speed, etc.

Jumping right to:

3) If using an external controller, higher-level protocol or not, it makes sense to have an intermediary microcontroller on the hashboard (or, in the case of Avalon6, on a separate board that talks to the hashboards directly) which handles all upstream communication, and multiplexes chip-bound data, fan control and sensor reading. Would it make sense to have this integrated at the board level even if the miner has a self-contained controller? This increases board-level hardware complexity, but can also add features like semi-autonomous fan control in emergency situations when the controller software is exhibiting erratic behavior (for example, S5 overheats). It could also be responsible for implementing changes at the board's voltage regulators, in the case that adjustable core voltage is desired; you cannot convince me adjustable core voltage is not a mandatory feature, so something will need to do it.

To me, given the near dirt-cheap cost of using a real cpu chip per-board that talks to a controller PC (running say BFGminer perhaps?) which handles all pool assignments and miner setups/reporting makes the most sense. AFAIK there are several companies offering complete SOC's using name-brand cores.

How the boards are linked, I'd prefer straight Ethernet using DCHP to start with with the network name pre-programmed as say the board sn. Single chip interfaces running T10/100 are available from many mfgrs along with their IP stack just for this type of thing so should be piece of cake. No ground loop issues, reliable and inexpensive network switches abound.

No matter what, the idea of a separate control PC between the miners and the outside world has too many plus's to be ignored. Central setup of the hash boards, single-point monitoring of network traffic, can be a RasPi or one of Intels NUC's, etc.

[sidehack]

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.

[NotFuzzyWarm]

My aversion to USB comes from using them as COM ports under Winbloze for around 10 years... Until recently all the lasers we use in our systems communicate in-depth to a GUI or other software via RS232 which meant using (non-counterfeit) serial-USB converters. Great until a couple get unplugged. Mix them up on reconnecting and you get to find what new com ports are used and which device is on them... (now coms are done via EtherCAT with USB as a backup)

Now these guys http://www.newson.be/doc.php?id=CUA-XXX-XY2-24V have a pure TCP mode for (galvo) controllers. Just enough with basic Find Me/Report address/Reassign IP address and protocol functions to work on a private network. Out of the box they all default to a fixed 172.xxx.etc address but since under control of a dedicated program (for mining CG/BGFminer) the private network link is separate from the one to the Outside World and using a different LAN adapter anyway so what? Yes that dictates hubs and a separate cable to each board.

In that respect CG/BFGminer would act as a bridge between the 2 local (private) and WAN LAN adapters. Each hash board would be 'smart' only in the sense that it can setup a link to the mining control program, report who/what it is and capable of doing eg report local temps and or chip temps, V/F control as well as handle the housekeeping task assigned to it eg COLD/Hot V stepping, fan speed, etc.

Since in our laser systems we use 4 of those galvo controllers along with 4 network links to the (4x) lasers + a power strip and a PLC w/touchscreen, plus Keyence height sensors all on the machine network as well, well Find Me and Reassign addressing makes it all a piece of cake and utterly repeatable.

Now if USB can provide positive & repeatable device ID assignments for CG/BFGminer to use, then fine, but you still need one cable per hash board and hubs don'tcha?

Hmm, an out of the box -- go wireless and use BlueTooth or NFC inside of the miner with the HB's talking to a link relaying via <insert name here> wired link to the outside world? Again, scads of single chip solutions for that.

[fullzero]

USB 3.0 (all type c are 3.0) is known to cause interference problems, and in general is a pain in the ass; I wouldn't want it anywhere near a miner.

I'm guessing you never used an Asicminer blade NotFuzzyWarm.  They used the getwork protocol which due to the superiority of stratum ( thank you slush ) eventually required you to setup a stratum proxy in order to use them to mine at most pools.  A stratum proxy can be used with almost any miner or group of miners to create a single stratum connection to all your miners.  This doesn't need to be implemented with hardware, nor do I think it should be.  

At some point a bbb or rpi will bottleneck controlling multiple miners.  This is why there is no S7+, as the bbb couldn't properly support 9x S7 hashboards.

This is why I would choose an integrated controller for an ~1000 watt miner.

In general, I like the idea of reusable heatsinks.  However, after re-applying TIM to many boards (this is much more time consuming for a miner than a cpu) I am inclined to think that it is probably better for replacement boards to be shipped with heatsinks attached.  I also sold some boards without heatsinks on eBay and had a lot of buyers say the boards were inop after they somehow failed to properly apply TIM and attach the heatsink.  Boards are worth way more than the cost of shipping a heatsink, so IMO the heatsinks should be reusable but it is probably best to have the buyer send them in to be reused when seeking to buy upgraded boards rather than simply shipping the boards themselves.  

[sidehack]

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

[2112]

Now these guys http://www.newson.be/doc.php?id=CUA-XXX-XY2-24V have a pure TCPIP mode for (galvo) controllers.

I haven't looked into details, but this device doesn't look like it would be suitable for coin mining. In this application the key functionality is asynchronous notification from the device to the controller that the golden nonce has been found or that the nonce range search has ended. It is non-trivial to do it fast, reliably and correctly. I have no experience with this particular interface, but I've tested many, many similar ones over the years. Few of them meet the the 3 requirements stated earlier. Most of them are barely working as event inputs and require tight polling loops. They are typically designed for output or for bulk streaming input.

Interestingly the various "trigger" devices used in music production work very well, I guess the musicians are particularly sensitive to have the computer really work on a cue from a human, not vice-versa.

Interestingly, bitfury who is an excellent engineer, proposed earlier an IP-based mining protocol that was susceptible to exactly this failure mode. I'll add a link once I find it.

Edit: I've found it: https://bitcointalk.org/index.php?topic=84791.0

[NotFuzzyWarm]

Now these guys http://www.newson.be/doc.php?id=CUA-XXX-XY2-24V have a pure TCPIP mode for (galvo) controllers.

I haven't looked into details, but this device doesn't look like it would be suitable for coin mining. <snip>

Was only using that as an example of a simple and dedicated-purpose TCPIP  networked device typically used in concert with others of its kind.