Bitcoin Forum

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.

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

actually delivered on time and on spec

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

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

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.

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

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

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.

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

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

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.

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.

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.

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.

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.

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.  

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

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

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.

https://bitcointalk.org/index.php?topic=294499.0

An icarus design hardware is crap - don't do it again.

Edit: oh, also if you process two nonce ranges at the same time, so do e.g. an ntime role of '1' - and handle ntime properly in the driver like -ck and I have done in many drivers, but with a double roll - you can get something like a 20% reduction on the power requirements of the 2nd nonce range ... ... ...

I read size and power as per gh/ watt   don't ask me why.

 so if it is to be 16 by 9 by 9 and pull 1 kwatt dc as max.

2 boards  with 3 pcie jacks each is a must. 

I would like what ever connects the 2 boards to the controller be replaceable with ease
I would like  a rasp pi or pc option.

When I ran 120 usb sticks to 1 pc I got it to be stable.

The good thing was every part in that  was easy to replace.

Your setup needs every part to be easy to replace. via amazon newegg

  The most expensive part would be the board   and basically it the only part that would be yours and yours alone.



Just like the usb sticks  I only need to replace a usb stick  which is your exclusive part.

So the key is to make the board a black box  concept which the miner mails to you and you send a replacement.

and the board are independent   so if a board dies it is one board. or ½ the hash

quiet is still key even if it must be down clocked.

at 500 watts it is more efficient and quiet.
at 1000 watts it is louder and less efficient.

to be frank   I do think  that a 400 watt to 800 watt is better then 500 to 1000

as so many good  850 to 1000 watt psus are around


https://www.amazon.com/EVGA-SuperNOVA-PLATINUM-Crossfire-220-PS-1000-V1/dp/B00SOXNK52/ref=sr_1_9?

https://www.amazon.com/EVGA-SuperNOVA-TITANIUM-Warranty-220-T2-1000-X1/dp/B018JYHGQE/ref=sr_1_11_m?


this would be really good if you had a 400 to 800 watt miner  just clock the miner to 700 watts


https://www.amazon.com/SilverStone-Technology-Strider-Titanium-PS-ST80F-TI/dp/B01CE7NV84/ref=sr_1_1?


and if the miner was on quiet mod   at 400 watts in an office  even this psu works


https://www.amazon.com/SilverStone-Technology-Strider-Titanium-PS-ST80F-TI/dp/B01CE7NV84/ref=sr_1_1?

1- quiet
2- I want to be able to use my EVGA 1300 watts PSU.

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?

I personally don't mind  the 1KW area.  What I want is the best bang for my buck, and if you are able to get it cheaper by having more chips/power on each miner I would rather have that then  a quiet low power unit that is more expensive on hash.

This is the opinion of someone with a mining area where sound/electricity is not an issue.    So really 1KW area does not bother me, my two main wants are power efficient and low price.

From a not super technical standpoint, the question of how to control the miners is really a question of how long it takes to get going. Once you have everything set up, they mostly just go.

I've got a few "dumb" miners that I control with a pi running minera, a few others that are run by a pi running Zeus's own ARM mining image. I like both of those because other than applying the image to the pi, once it's on and plugged into the network you can run everything from their web portals. It takes the imaging of the pi and initial settings for the pool but all in all not that daunting. That being said, it may be a bit too much for your average home miner.

The Advantage of having the controller already on the miner is ease of initial setup. When an S7 arrives at my home, I plug it into power and network and check DHCP lease on the router, go to the new IP and put in my pool settings, the thing is hashing away in 5 min, out of the box. That's huge.

If you choose to put the controller on the miner, please include DHCP lease renewal on the network interface! Setting up used S1s and S3s that have default IPs is annoying, you have to set up small private networks just to get them to be on the right subnet to speak to your regular network, if they would just get their IPs from the DHCP server it would make setup time much quicker.

Ease of setup is essential, but I also want to look at overall cost, reliability and fault tolerance. A controller per miner ensures no one box can affect the operation of another, but also has the highest cost.  A single controller for a fleet of miners is the cheapest and easiest to configure, but also provides a nice single point of failure. A single controller with chained boxes means if you pull any one cable, every miner downstream is also disconnected. Using a single controller with a tree structure of connected boxes reduces (but does not remove) this problem, and still leaves you with the controller as a single point of control but also failure.

I like the idea of the single controller being something generic and replaceable like the Pi. If your Avalon6 controller craps out, you don't have to email warranty claims and wait a week for them to deny your claim. Just go to any of a thousand online vendors and pick up a new one for like $20 - or if you're that worried about it, already have one standing by just in case. Avalon sending a Pi with the SD card already imaged is really nice.

The easiest busses for consumers to work with, as far as setting up a tree of connections using readily available hardware is concerned, would be Ethernet and USB. I'm in favor of USB from the standpoint of ease of interface (you can get $2 microcontrollers with full USB capability) and availability of software to build upon, but Ethernet does make distribution easier what with better cabling and generally more reliable hardware. The problem with ethernet comes from controlling it - either the miners have to be on a private network and a dual-NIC controller is present, or the miners exist on the same network which adds work to detection and preventing control overlaps.

Oh yeah, I was ecstatic when the S5s started showing up with DHCP enabled by default. Very glad to see that change. My entire hosting is run off static leases on the DHCP server, makes everything super easy.

Whatever happened to the board to replace the S1-S5?

chips chips chips.  it has always been the issue  chips .

 best we did was get some to make the compac sticks

Like I've mentioned a couple times in the last few days (I think it's been suggested here, and explicitly stated in the Community Miner thread), I have been asked to help with a miner development project and one of the side benefits is being able to piggyback their resources for my own project. So that's what's happened to the project to replace boards on the S1.

Back to the CC ideas being thrashed out and such:

1st - the 1kw power fits perfectly with me. For one, it is a perfectly reasonable load for any ONE household 110v 15A circuit. Also fits well with those who have several 1500VA/1300w dual-conversion 120v UPS's hanging around ;) and ta' boot is a perfect match for the uber-available HP 1200w server supplies when fed >200vac

On coms, still like the private/public networking. Ja that means 2x NIC's but - if pressed to use RasPi's and such I do believe they have USB-LAN adapters for them so there ya go. But...

As has been brought up, even the newest RasPi's are easy to max out with too many connections (miners) under its control. So: Use a cheap fanless mini-PC. I got a fairly cheap one in 2014 to control my first 2 miners -- two lil' BFL 10GHs cubes. The PC is about the size of a phone book and has a 2. something GHz dual-core Atom CPU, 64gb ssd. Takes 20w to run and cost around $200. Ja only has 1 LAN port but again, get a USB-LAN adapter fer it and done.

Since throughput vs CPU power is not my bailiwick I can't say for sure but I'd think that even that would be quite an improvement over a hobbyist/dev board like a RasPi, BB, Audrino, etc.

A thought on the HP CS psu's:
What form-factor is in mind? Stand-alone blocks ala' Bitmains extruded cases? (which I do love, 'specially how they can lock together. Nice touch there.)  Perfect for folks to use any standard >1200w PSU. Only problem with Bitmains cube is that the shape and size is the root cause of their noise. Why their cases are not even just 2" longer to get the fans away from the heatsink fins is beyond me.

EDIT: Removed commercial/industrial  and rack mounting from the discussion.

I for 1 would not like to drop 10THS or more from PSU failure. If the miner is self contained w/interal PSU, considering the HP's bare-bones go for around $40 on up is cheap protection toallow for2x  pre-wired PSU sockets for folks with >200vac available. Better yet, if room allows ya could optionally add more hash boards in (but lose 1+n redundancy unless there are 3x PSU slots).

As a side note: I would kill for someone to make a little case for the HP's with 4 or more slide in bays using pre-wired for load-share sockets tied to a set a of copper bus bars.. I still have around 6 of the HPs still in OEM anti-static bags I'd love to put to use in multi-kw power brick...

I think a lot of how "powerful" a Pi is with regard to controlling multiple miners is dependent on how work is distributed. I don't know the numbers for Avalon6 but one Pi could handle something like 50 of the Avalon4 units.
Considering NICs, that's actually one of the main limitations of the Pi is the ethernet is slow since, if I'm remembering right, it shares a bus with USB. Adding USB NICs might not be a great idea.

Also requesting your buyer to buy a $200 PC to control a miner is not a path I'd like to go down.

I think, all said, if I were putting Ethernet on the miner I'd just as soon put a full controller in it like on an Antminer.

There's no question that ethernet connections are going to be a lot more resilient and reliable for a large deployment of machines. I think with good control software leveraging the cgminer API, configuring multiple miners on independent network connections is not going to be much more difficult than configuring multiple miners on a common controller. This also removes the common controller as a single point of failure.

I like the idea of using something off-the-shelf like a standard Pi, that the user can buy replacements for all over. I'd prefer to not have that plug into a proprietary IO board for simplicity's sake, but without knowing more about the GPIO header on the Pi it may be necessary. If the boards used USB they could plug directly into USB on the Pi, and then anyone enterprising could hook the boards up to anything he wanted. I'll do some more learning about the Pi's GPIO and see what busses are available, because connection-wise it'll probably be more reliable to use a pinned header than a USB jack.

Also, for the third time,

Which means, for the purpose of this discussion, any consideration for industrial farms and especially rack-mounters goes right out the window. Don't care at all, it's a whole different discussion. I've got a thread from sometime last year, similar type of discussion, about attributes for an open-source rackmount design indended for internal or semi-internal server PSUs and internal blades in the S1 formfactor, if you want to look that up. The conversation fell by the wayside when any optimism I had for being able to make those boards last year evaporated.

Just had an issue with my lil' s7b6 that brought this idea back in me mind...
Since we are talking about using the MC on the hashboards to do more than pass along info to the ASIC's and now letting it do real monitoring/control functions, how about an intelligent power glitch or internet loss recovery/restart process?

Looks like a worst-case example of what can happen is https://bitcointalk.org/index.php?topic=1524802.msg15339312#msg15339312

My s7b6 is in the garage and power by one of my fav UPS's feeding 2x HP supplies fed off its (perfect) 120vac so that end is covered. However, since I use an over the power-line network bridge between house and garage it has to be on a 'bare' unprotected socket. Power must have glitched because lost connection to the b6, it went into full fan safe mode. Noticed it was offline, had to unplug the OPL bridge and plug back in to restore internet connection. Connection restored, miner still needed 2x soft reboots to recover.

As long as the RPI and CG/BFGminer stay alive do they have links to respond to intelligent or semi hashboards going into safe mode and then recovering on their own? Or say a watchdog prog monitoring hashboard health stats to trig the necessary responses?

Oh, along the lines of the burnt data cable thread... data isolators so power finding its way into data cables poses no threat. Multi-channel bi-directional ones are pretty cheap. Also perhaps could be a novel way to handle the ASIC data line voltages as it varies going up the string perhaps as well?

You could do that with a controller that allowed sub-interfaces/virtual interfaces to be configured on a single ethernet port, and a switch that could handle standard VLANs and VLAN trunking. One VLAN with the miners, one VLAN with the controller and the connection to the internet. You would want the miners to use DHCP, and then configure the controller to act as a DHCP server on the miner VLAN.

I like the idea of using USB to connect the miner to the controller. It keeps things relatively straightforward for the end-user and the components are easily sourced from pretty much anywhere.

The choices for controllers is the more interesting one, or you could make it even easier by letting people use what ever they want for a controller as long as it can connect to the internet, has USB and can run cgminer.

Cheers,

- zed

Perish the thought!

VLANs aren't a consumer-level concept. I would argue that they even aren't business-level concept unless the business has several hundred employees or at least one CCIE (or equivalent) network administrators.

They are also emerging as a new way of hiding malware botnets, several better network security devices (both high-end and low-end) are flagging VLAN-tagged traffic as intrusions.

Also, VLAN-tagged frames have unfortunate property of causing crashes or malfunctions in otherwise quite reliably working network hardware. This includes Intel which was co-architecting the current VLAN standards! Some people more paranoid than myself even have an opinion that the malfunctions/crashes/malware flagging is the tactic to increase sales by "planned obsolescence". From my recent memory the business class Samsung printer/copiers/scanners have particularly nasty bugs cased by the presence of VLAN-tagged frames.

My one-employee business runs VLANs, but that's only because of the hosting subnet. A miner requring the customer to use VLANs very much violates the "simple" requirement.

I now have a standard answer to those "one-man company" arguments. It is a old poem by some Russian poet:

Quote A lonely sail is flashing white Amidst the blue mist of the sea!... What does it seek in foreign lands? What did it leave behind at home?.. Waves heave, wind whistles, The mast, it bends and creaks... Alas, it seeks not happiness Nor happiness does it escape! Below, a current azure bright, Above, a golden ray of sun... Rebellious, it seeks out a storm As if in storms it could find peace!

Quote Бeлeeт пapyc oдинoкий B тyмaнe мopя гoлyбoм!.. Чтo ищeт oн в cтpaнe дaлeкoй? Чтo кинyл oн в кpaю poднoм?..   Игpaют вoлны - вeтep cвищeт, И мaчтa гнeтcя и cкpыпит... Увы, - oн cчacтия нe ищeт И нe oт cчacтия бeжит! Пoд ним cтpyя cвeтлeй лaзypи, Haд ним лyч coлнцa зoлoтoй... A oн, мятeжный, пpocит бypи, Кaк бyдтo в бypяx ecть пoкoй!

I just have gotten used to not having a stupid boss I have to blame things on, and who can tell me to violate my principles for a paycheck. Freedom is worth the effort.

Agreed, I was just answering the question posed. I understand VLANs and such, but that's because I've been doing that stuff for a relatively long time, and without a CCIE even.  ;)

In the OP:

Having the miners be chainable using USB would be interesting. It allows for the possibility of having one miner with a built-in controller (that has ethernet and USB) that is able to communicate with other "dumb" (no built-in controller) miners, and also possibly using cgminer (or equivalent) running on an external computer to control the miners. Using the built-in controller managing a chain of miners model might provide more fine-grained control of the individual miners through an API or web interface than the external computer running cgminer.


Here ya go:

http://www.raspberrypi-spy.co.uk/2012/06/simple-guide-to-the-rpi-gpio-header-and-pins/

That has all the models listed, except the Pi Zero, but the Pi Zero has the same GPIO pinout as the Model A+/B+/2B boards.

Cheers,

- zed

Understood, VLANs aren't really rocket science. But they are also nowadays a history. With the exception of the USA true IPv4 globally-routable addresses are in acute shortage. Modern ISPs rarely provide "the Internet" with plain IPv4 technologies. Nowadays it is a mixture of PPPoE (8-byte tags instead of 4-byte tags in VLAN), MPLS (variable tag sizes) or by tunneling IPv4 in IPv6. So adding 4-byte VLAN tags to the "Internet" side is really pointless. It is much better to understand what is the "native" transport layer on the "Internet" side and configure everything else accordingly.

The reality of 2016 is that VLANs are now mostly botnet-hiding trick. Most of the past users of VLANs moved on to the more general and flexible SDNs (Software-Defined Networks).

I think that these days advising someone to learn configuring VLANs is like advising necromancy.

SDN technology is still in its infancy. In fact, Brocade has the capability built into their switches via VXLAN and OpenFlow and sells a few controller options, but actual enterprise solutions are few and far in-between. Their demonstrations are all based on Mininet in a virtual environment. HP, well, their switches might have OpenFlow capability, but the functionality is a joke. Cisco claims they are working on an SDN solution, but where is the firmware for their switches? SDN is not even designed as a replacement technology for VLANs. Anyway, VLANs have their place in major enterprise network where they are frequently used in conjunction with VRFs and MPLS to extend the enterprise over multiple campus networks.

All of that to say, I agree with you. VLANs would only serve to add complexity that is unnecessary.

It is good to have somebody knowledgeable post here about SDN. My comment to the above is that SDN is to the large extent a fancy packaging of the old-style GRE tunnels (Generic Routing Encapsulation), so the devices not explicitly supporting SDN can still be made to interoperate with them, because GRE was rolled out in late 1990-ies.

But I posted here to somehow constructively close this derail. The original problem was to have disjoint IPv4 subnets on a single LAN segment. If this LAN segment is under single administrative control it is best to support that using IPv4 aliasing. Windows fully supports it since NT4. Unix-like system supported IP aliasing even earlier, review the "man ifconfig". Depending on your actual configuration you may need to review and hand modify your routing table ("route" and "netstat -r"). Also be aware of possible ICMP redirect packets that could install temporary routes. With some careful configuration done you can even have more than one DHCP server running on the same LAN segment. Various DHCP exclusions/special identifiers will need to be set up to make that work correctly. Again, read the docs.

In the SOHO (Small Office Home Office) market segments using VLANs is really risky. The problems are:

0) previously mentioned botnet-hiding tricks in malware and various workarounds for those attacks in networking equipment/software sold in the SOHO segment.

1) lack of full hardware support for VLAN-tagged packets in many cheap network switches/routers. They tend to support VLANs through software exceptions that make them work much slower. The cheapest devices tend to have firmware/hardware cheats that not even fully work but pretend just enough to pass the "Compatible with Windows" tests administered by Microsoft.

2) color printers/copiers/scanners on the segment with VLAN tags are your worst enemy. Those devices always have secret police firmware to prevent printing/copying banknotes, not even the printer manufacturer has the source code and they cannot fix all the bugs.

In my experience helping various part-time small-network administrators IPv4 aliasing is a safer choice than VLAN tagging. If you insist on using VLANs then buy some old Cisco IOS router/switch just for the purpose of using it in debugging and troubleshooting, not in a normal production/operation. Cisco IOS is extremely complex but also there's lot of information for it available for free on the Internet. It is also extremely well debugged and has extremely good debugging/logging tools available.

My hosting VLANs are all handled in an old 24-port Cisco multiplexing off a pfSense router with VPN. Works pretty well. Also, I had a cousin missed a family reunion about ten years back because he got arrested for counterfeiting - probably with something lame like a photocopier or, at best, inkjet printer and scanner. Noodlehead.

Also. I think we're in agreement that requiring, or even requesting, VLANs for a consumer environment is probably a bad idea.

An internal Ethernet-connected controller using off-the-shelf hardware like a Pi makes sense. Is USB good enough for bussing the boards to the controller internally? That would certainly make troubleshooting easier for end users, and allow a lot of flexibility in custom deployments - as well as ease of connecting multiple units in the event of a controller failure. Heck, with a bit of playing you could probably even mount a bunch of boards in a rack case if you wanted to, which would be good for that guy from earlier.

One concern, already mentioned but worth rolling over again, with using a base controller and having all functions handled at board level is fans. If it's a one-fan unit like the Avalon6, one board would have to be designated as the fan driver. This is simple enough to do if, upon startup, the boards check for a fan installed (easy enough with a tach line) and report to the controller who owns it. This gets a bit tricky if multiple boxes end up tied to a single controller, since the controller won't know which two boards are on the same fan. Some way of assigning pairs, perhaps with serial numbers in a config file, would have to be conjured up that needs to be straightforward. It'd be nice if that function was implemented in a webconfig also, because not everyone knows what "SSH" means or how to use it. An easy means to ID boards without jacking with wiring, like flashing an LED, would be necessary. Of course the controller should automatically handle this if only two boards are connected, and the only manual intervention needed would be when multiple boards/boxes are tied together.

You can use any PI type if the software is written right i do it now with my Alchemist which comes with it own controller that is junk i use  rasp pi cubie boards orange pi etc or have tried them all they all  work with USB dongles the drivers are suppose to only work on  RPI but i knew different in most cases if it works on one it works on all of them if it's in USB dongle form these https://www.amazon.com/gp/product/B009T2ZR6W/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1

 i know that's script it's just a example any miner can do it . just adding that thought . and 500 watts to 1300 for a btc miner sounds good.

for fan control http://www.ebay.com/itm/DC-12V-PWM-PC-CPU-Fan-Temperature-Control-Speed-Controller-CPU-High-Temp-Alarm-/181694032917?hash=item2a4dceec15:g:ffIAAOSwqu9VCZMW

i sent two to phillp to try he said in a round about way they work. how well no idea   just a idea to build from.

No USB dongles. No external boards for fan control.

not asking to unmind you . whats wrong with  USB dongles if you using a hub , won't you need some kind usb plug on the end is my whole point. i use a hub with wires running to the hub from the miner is my point why i said any pi . so i hope it not just limited to one controller pi type then it's kind like bit main any way whatever comes I'll  adjust just adding feedback idc either way as long it does what it  suppose with less power and more hash and user friendly for every one and not hard to replace parts .

Well, we've already noted that it's annoying to find replacements for the USB converter Avalon uses, and made specific mention of how easy it is to find microcontrollers with USB capability built in. So, if going USB why require an annoying converter when you can just integrate it onto the board?

USB has also been raised specifically because it doesn't limit you to one controller type. It's easier for everyone if the thing comes with a controller already, but with open software and USB connection you could replace that controller with almost anything you wanted. "Not hard to replace parts" is definitely a key desirable feature.

cool like i said whatever work :) , I'm not being rude by saying whatever works i don't mean it like some might take it .:) .


and the Avalon 4/4.1/6 is made for the Avalon your are right about that what i link is not and sold any place. so excuse me was offering feedback just being cool or trying if it's works yea :).


cya


  

It's easier to keep track of if there are fewer add-on parts strung along in the middle, especially since it won't cost any extra or be any extra work to build it into the board. That adapter you linked is the same hardware as on USB Block Erupters, AntMiner U1/2/3, my Compacs, New R-Box and a bunch of other stuff. It is easier to find for an end user, but (as Novak and the AM Tube found out) people sometimes still have problems with incredibly simple things. Idiotproofing is your friend - well, assuming "you" will be doing any kind of customer support. Most customers, at least the ones who ask questions, are idiots.

Hopefully fourth time's the charm...





If you're looking for something in any way akin to the U3, you're in the wrong thread.
That said, thanks for the support. Hopefully whatever ends up getting built is worth buying.

Query: How is the miner connected to the home network?
Hardwire only using jacks and cat5 cables?

Any chance for a WiFi option as well as the hardware (for setup) connection?

Hmm, might also be a good chance to reuse the WiFi boards and hardware from s1's... I ask because it seems the OPL LAN bridge between house and garage is acting up again -- it runs warm to start and doesn't seem to like a hot garage :( So, need to setup a WiFi link from my home router to there... Side note to this is that my s7b6 normally draws 1090w as reported by the UPS feeding it, when in loss of internet 'safe' mode power drops to 390w. So far fans always stay running at my set 85% but if they ever stop....

For the new miner - how about the MC having a safe mode to have the V regulators feeding the ASICS to shut down when the network connection is dropped and the ASIC's are just twiddling their thumbs?
 
Along those lines, Why did Bitmain change drop using OpenWRT? I loved the data traffic graphing it offered.

I think it is, and I am basing that on the fact that my Compac has been hashing away for a couple of months now and it seems pretty happy. I've probably only had to unplug/plug it a dozen or so times.

Where USB gets wobbly is when you keep plugging/unplugging cables. The connectors loosen up, the connections become less "solid" and that's when things get flaky.


What if the miner used a two controller configuration in a master/slave setup? The slave would be the focal point for all onboard items like the hashing boards, power control, fan control, and information gatherer.

There could be a 3-port USB hub within the miner with one of the ports wired to the slave controller, and two externally accessible ports to connect to other miners and the external master controller.

The master controller is where cgminer runs. You could put together a package of software that runs on a RasPi 3 so that you have USB connectivity to/from the miners, ethernet or wifi connectivity to/from the 'net, and the spare horsepower to run a web server to proved a nice GUI interface and REST API. You could also plug in a keyboard and mouse on the USB bus, and plug in a monitor on the HDMI to use like a regular computer.

The slave controller inside the miner has several management tasks:

• Fans
• Power
• Hashing boards
• Information gathering

Fan ownership would be a non-issue as the slave controller handles it. Fan control could use a PWM pin on the slave controller with the fan(s) always spinning at some arbitrary low speed when power is applied but the miner is not hashing. This minimum speed would be enough to keep things cool at idle.

The hashing boards could connect to the slave controller using I2C with the I2C IDs set by a simple switch on the hashing board if the boards are identical, or with a hardwired I2C ID if the boards are different based on which side (left/right) of the case they are on.

Power to the hashing boards could be controlled/managed by the slave controller. I'm thinking about two levels of control here. The first level is on/off which is dependent on a properly operating fan and active communication with the master controller. This could be managed using GPIO to activate/deactivate relays that feed power to the hashing boards. The second level of power management is controlling the voltage on the hashing boards to manage the power usage for custom tuning (over-/under-volting) and optimizing.

Information gathering could be achieved through use of the other GPIO pins to sensors for things inside the case, and any hashing board sensor data coming in through the I2C data stream. This information would be fed back to the external controller via USB.

The miners would be modular as the external controller could talk to them via USB, up to some arbitrary limit. Each miner would have a unique ID as USB devices on the bus. The internal slave controller could be a custom design, or could be an off the shelf devboard. The use of the external controller allows folks to use their existing computer as long as it can run the cgminer software. For an added charge they can buy the GekkoScience external controller that provides additional bells and whistles.

Cheers,

- zed

Well put. The only flaw I see is:
    "This could be managed using GPIO to activate/deactivate relays that feed power to the hashing boards."

Relays that can handle the currents involved are not cheap. However, use the same idea but talk to the MC to trip the voltage regulators run/stop pin just like a PC's PWR_OK line from ATX and other psu's so the Vcore regulator(s) simple shut down until all is well again..

A slave board is possible, but if there's a way to do without it I'd prefer that. I think the fewer proprietary and also essential parts there are, the better. Dealing with warranty stuff sucks from both ends, especially if there's no workaround to get your miner at least back to limping while waiting for replacements.

Are there any decent wifi modules that work with the Pi via USB? I'm assuming so, that seems like a very simple and common problem but I don't really use wifi so I've never had to look it up. What I'm thinking currently is have a Pi as an internal controller, and expose ethernet, at least one USB and probably some status LEDs on the front panel. Hashboards would connect directly to the Pi by USB. Worst case your Pi craps out and you're waiting on a replacement, you should still be able to tie the boards to an adjacent miner or other computer via hub. With a setup like that, the hashboards become the only proprietary (and therefore difficult to source) electronics, and they would be easy to run off a variety of nonproprietary controllers, which minimizes a lot of the issues people have with, say, Antminer BeagleBoners and IO boards shooting craps and losing a month of hashtime and money out of pocket waiting for very specific replacement parts existing in limited quantities (if at all) from exactly one source in the world.

I generally don't like unnecessary complexity because it tends to add failure points. Yes I know using USB for interconnectivity is adding a layer of complexity to a problem which could be solved in a simpler way, but it does so in a way that reduces the overall cost of failure. A layer of complexity which adds a layer of redundancy or reliability is okay - like RAID5. It's not perfect, but the benefits merit the extra effort.

Enabling power to the hashboards does not need to be accomplished using external switches in any way, provided the hashboards have an onboard regulator (which they will if I have any say in the matter). One only needs control of the buck controller's ENABLE pin (which NotFuzzy stated while I was typing this up). No power will get to the hashing chips if the buck is shut down, so the board-level microcontroller should be able to control this in addition to determining operating voltages. I like the idea of making a software power-cycle of individual hashboards possible, and an advanced driver could be implemented that watches for a hung board then forces a hardware/software restart. That would be really handy for automatic tuning especially at the bottom-end voltage range where node-level voltage imbalances have the most effect on overall stability. Being able to force a total power-down of all ASICs would also be good for mitigating damage from an overheat condition resulting from fan failure.

raspberry model 3 has wifi built in

That is handy, depending on how easy it is to interface to. But do we really need a quad-core? (hint - the answer is "no").

What specific model of what devboard computer gets picked is important to the overall discussion, but I wouldn't mind deferring it for a bit. If enough people want wifi, that certainly adds weight to one supporting it natively.

I'm not a fan of proprietary designs when there are off the shelf components available. That's why I was thinking about using something like:

https://www.adafruit.com/products/2885

or similar as the slave controller. It is powerful enough to do everything to manage the miner, and is sourceable from a lot of places. Using a slave controller also makes some of the management tasks easier.


Yes, as @irritant mentioned, the RasPi 3 has it built-in.


How would fan management work in the failed/external controller scenario? I like the idea of each hashboard having it's own connection to the controller, but as you mentioned earlier, how to associate fans to hashboards/miners becomes a challenge. How much non-hashing functionality do you want to put on the hashboards? Is there benefit/value in keeping the hashboards "simple" and having some auxiliary board handle some of the other tasks?


Agreed. If "fixing" the miner is as simple as removing the failed controller, pulling the microSD card, inserting it into the new controller, and plugging it back it in, then that's good. That the failed controller is available off the shelf from a number of places around the world, then it's even better. That's why I keep coming back to the RasPi variants. The Arduino and it's variants are about the only other ones I know that have such broad availability. There are probably others, but those are the two that come to mind.


Done! That is exactly what I was thinking. I'm just not as familiar with the low level power stuff as you are. What you and @NotFuzzyWarm are suggesting is a far better solution than my proposal.


Yes, this is what I was thinking, too, but you stated it better than I did. The nice thing is that if automatic control is implemented, you could have each hashboard under-volt and under-clock when temperatures reach a certain threshold. This enables miner self optimization to run at peak levels in hotter locations with less human intervention.

Cheers,

- zed

Retail the Pi 3 is ~$40. You'd likely spend more on a non-wifi devboard, and then have to come up with a wifi solution, which is typically a dongle. As you have stated several times, dongles are not desirable.

That the Pi 3 is a quad-core board is just an added bonus.

- zed

 Size, sure - but power consumption on BOTH of those units was quite high for a "home" miner.
 I'd aim for under 1KW and preferably WELL under for a "consumer" miner - 500-700 watt range is a lot more manageable for non-BIG FARM miners, IE the S5 and SP20.

 WiFi - definitely should be OPTIONAL.
 A lot of us don't have any use for it nor any interest in paying for it.
 Available AS AN OPTION, sure - some folks DO want it.

A miner for those who only have wifi would be nice. A lot of people like myself can't connect any other way.
I personally have been stealing internet access for over 10 years.
So miners that connect to a PC via USB or a expansion card slot are nice.

The wifi transmitter that comes with the raspberry pi is just to weak, I have to use a Alfa card with a large parabolic dish to connect. So everything has to run threw my computer.

A USB dongle for wifi support is acceptable, since it's optional and would just plug into the controller's external USB jack. A USB dongle being required for base functionality of the machine, that's when dongles are unacceptable.

I would prefer a miner in the 400-500W topend size, but it's not up to me. Like I said, those attributes are fixed.

I have no interest in enabling thievery, so telling me what will make it easier for you activates my contrary nature and makes me want to oppose your suggestions.

Those are really good points you guys have been pointing out. I hope this is a success. And how about using C.H.I.P as the controller it's just $9 with wifi, 4gb storage, 1Ghz processor, 512mb RAM, Bluetooth, eth. I guess a 512Mb RAM can easily handle tasks.

Nice thread :D

Some of my suggestions:

• If possible, one-side only monoblock heatsink. It makes it super easy to maintain and super easy to upgrade. The S5 heatsink was great to work with, especially the extruded ones that had straight fins.
• USB communication with a jumper or dip switch to override it and use direct UART. What if the darned USB circuit fails? it would be nice to jack it up to a raspi UART and be back on business.
• A good spec: it would be nice to have a spec so anyone wanting to roll their own solution can push work to the device easily.
• If chained comms can be avoided, better. Too many times i have had one antminer board fail on me because one chip malfunctions. That, for me, is designed obsolesence.
• Replaceable power module. Your regulator circuits rock sidehack, you know i admire them. How cool would be to just throw a faulty regulator circuit and replace it with a new one?
• Also, replaceable comms. I know i'm suggesting a lego miner, but heck i have seen too many dead boards because of anything but the board really failing.

I know some of my suggestions are a little pie in the sky, but we're talking about an ideal miner, right? RIGHT?

Well, ideal and practical. I'm opting for a bucked string since it's by far the most efficient and least parts cost that still allows adjustable core voltage. The obvious problem with that is if one chip fails the board fails, chained comms or not.
If you look at the node-level support hardware on a Prisma versus S5, to implement parallel comms requires a lot of extra stuff.
A "lego miner" is probably not feasible, as half the cost of the thing will be in sockets. I'm not attempting to define an open standard, just some guy wants to build a miner.
If the darned USB circuit fails - I'm assuming we're using a USB-enabled microcontroller, so if the USB circuit fails that probably means all board-level control is gone. No chip comms, no temp sensors, no voltage regulation, no fan speed. But I bet you could swap on another $3 microcontroller, flash the firmware and get back up. It might be worth having a separate UART port; the only problems would be adding to the cgminer driver and micro firmware to support that transport alongside USB.

I am definitely in favor of monolithic heatsinks, but I also suggest that double-siding should get better heat transfer to air which should result in quieter fans. However, I'm not a mechanical engineer or heat transfer guy so I don't have the numbers to back that up, it's just an intuition.

As far as the spec goes, the cgminer source code will be public (as are the license terms, after all) if I have to steal and host it myself. I don't know about micro firmware source code, that'll probably remain proprietary, but I'll see about making a compiled hex available for folks in need of repair. Surely there'll be some documentation on the command structure for talking to that micro as well.

Not really helpful, but:
I'd love to have a miner that would make it easy for someone to create a watercooling heatsink/block for it.
I have a wet dream of owning a house with a quiet, waterborne?, central heating system, powered by ASIC's! ^^

Also, would it be possible to make a 1000W miner "silent" by using a bigger enclosure? Instead of 2-3 boards packed in an S7 formfactor, that requires fans with high RPM and a high static pressure, could you spread it in a bigger formfactor so that you don't need high RPM fans? An enclosure like this would obv. be optional.
Would this work for an S7?

Can't wait to see the results from this project!  :)

/Sorry for my broken english..

You could probably take apart an S7 and strap lower-volume (in both nose and CFM) fans directly to the heatsinks and quiet it down. Part of the noise problem there is power density of the boards, and part is the overall heat density (and high pressure required by the solidity of the heap of heatsinks) of the miner. One of those problems is solvable by spreading it all out.

For this project, what you're suggesting will likely not be implemented. Mechanical design and manufacturing for a secondary optional everything-except-the-hashboards seems a bit of a stretch to ask for. My goal is to make the thing as quiet as possible within the given constraints.

Anything with a monolithic heatsink should be able to mount up to a waterblock. One of my goals (separate from the project discussed in this thread) is and has been for a while to build new boards in the S1 formfactor, and those should mount up nicely to C1 waterblocks.

The single problem with mono heatsinks as usually done (on the back of a board) is one of thermal transfer. If a chips is dissipating more than 10-15w then great care has to be taken regarding thermal vias and contact bumps on the board/heat sink interface to make sure enough heat can flow from the chip through the board/vias to the sinks. Even if done properly a naked chip is still going to run a fair bit hotter than one with a topside heat sink which in turn will directly set what the maximum speed/Vcore can be.

Now maybe if the chips can be mounted on one side of the board and all other components in the other to allow a single large heatsink contacting the tops of the chips-- that could work as it takes the boards thermal resistance right out of the picture.

I get the ease of maintenance with a single block that has straight fins, but is it really that easy to upgrade/remove? I would think that there is a lot of stickiness from the baked on thermal paste.


This could be possible depending on where the USB circuit it located, and what path the controller decision has taken. As @sidehack has mentioned earlier in this thread he is inclined to connect the hashboards via USB to the controller much like he did with the Compac miners he built. If the USB circuit breaks, then the hashboard would need repair.

From the request it's as if you may be thinking that there is a PIC (or equivalent) micro-controller on the hashboard. That sounds like it may be more complicated.

Earlier in this thread I had suggested using I2C to communicate to the hashboards, but I also suggested using a replaceable slave controller inside the miner that communicated to the "mother" controller via USB. More complex, yes, but easily fixable with off the shelf components.


If one were to use an off the shelf passive USB hub would that solve the problem? If the hub fails, you buy a new one from the local electronics place, or off the web.


Oh, man, I see this one snowballing. Next thing it'll be n+1 redundant power supplies, backplanes/midplanes with redundant paths, redundant fans with sufficient capacity that if one or more fails its not a problem, and of course everything is hot swappable, right?  ;)

Man, when I think UART it goes back a lot of years, but would making the six pins for an AVR/ICSP programmer connection accessible (don't need to have headers installed) be the equivalent? If that is the case you could make a hex file available separately, and folks that were interested/capable could flash their new micro-controller.

Cheers,

- zed

edited to add ICSP...

ISP header is pretty much exactly what I was thinking of doing.


This is also pretty much exactly what I was thinking of doing. How else are we going to read temp sensors, adjust core voltages, and change fan speeds? Something needs to be present at the board level to implement all that, which I'm pretty sure has been specified since the very first post and reiterated about half a dozen times since.

If we wanted the option for UART as well as USB, probably the easiest solution would be to use a CP2102 (or equivalent) on the hashboard and break out the serial lines to header holes. That separates the board-level microcontroller from USB, which would probably make code simpler and add about a dollar to the cost of boards. If the onboard USB shot craps, someone could wire up toptek's USB adapter in a pinch and get it back to running. I don't know if that's a better idea overall than just using a USB-enable micro and that's the only means of interfacing. If USB is externalized, it means sourcing two chips instead of one but that also helps standardize drivers and device detection and removes USB stack code from the microcontroller.


Nope, nope, nope. When considering adding complexity to cover for potential failure events, you should consider the cost of the addition versus the likelihood of failure. If a $100 miner is 1% likely to fail in a certain way, it makes sense to add $1 of addition to remove that failure. If a $1000 miner is 0.01% likely to fail in a certain way and removing that potential for failure costs more than a dime, you're probably wasting the effort. My design motto is "Simple, durable, reliable" but there are practical limits to how durable a thing should be made, especially at the cost of simplicity.


This has been the case, and it was also the entire point of the thread - I wanted my ideas to change because there are a lot of people here a lot smarter than me (and certainly more experienced engineers) and it'd be foolish to assume I know what's best from the get-go and ignore input.

Would that be the device that influenced the GekkoScience name? I looked up the device (https://www.silabs.com/products/mcu/Pages/default.aspx), and noticed the image that they used and the name of one of their dev kits.

Cheers,

- zed

Nope, that's entirely a coincidence.

Just a little bit of info regarding that, if the driver is written well and the chip design is optimal :)
I wrote the driver in the (defunct) Blackarrow Prosperos (as you can see if you look at the minion driver source in cgminer)
I managed to get a standard RPi to process approx 3.5TH/s of 1 diff shares during development.
No new miner would be sending back 1diff shares to the driver, so even at 64diff you're looking at a >200THs limit.
(The Prospero chip allowed setting nonce ranges and I set it to a tiny fraction of a nonce range and kept sending it the same work item that had the same nonce value in that range, so yeah it was full 1diff checking how fast I could get it to go. I got it to about 3.5THs)
The Blackarrow chip was indeed well designed, they just failed dismally at making high power SPI controller boards :P
However, that was SPI, not USB.

Yes, monoblocks are the best. The stickiness is solved with periodical thermal repastings. It is easir to maintain 1 big block than 163 little sinks ;)


The problem with I2C is it limits any bus to 255 devices. SPI is better suited for the density miners have. Also, much better solution is to have a MCU local to each board and make THAT controller the slave, not each individual hash chip. Then, the upstream controller just sends a nonce range and it divides work between hash chips. This could hide an I2C comms behind, SPI or a roll your own like the daisy chained SPI from Bitmain.



Hehe.... that's modularity at its best, too bad they are just toys :(

(Bitmain has never used SPI)

I don't know enough about the chips we'd be using to know if you can set a returned diff threshold, but I hope it's there. Last I checked, Bitmain chips returned all shares (might have changed with BM1385/7?); I know the BE200 had a minimum diff and I believe Avalon put that in as well. Hopefully that's the case - like you said, kano, optimal chip design.

Thanks for the architecture info. I read a bit about the SPI protocol and what they call mSPI (mini-SPI) seems interesting, and with the free-form of the SPI protocol, could have the potential for many more addressable devices in a chain.

How is communication usually handled when each hashboard has multiple chips and work has to be farmed out? Is that also SPI?

Cheers,

- zed

Most things use chained comms - the controller talks to the first chip, which relays work to the second, which relays work to the third. Sometimes the work packet will have a bunch of nonce ranges attached; each chip will take one and pass the rest on.
ASICMiner used SPI for board-level chip comms. Each chip had a select line and the MOSI, MISO and CLK lines were shared. There'd be some binary decoding where a five- or six-bit address would flag a single chip and everyone else would ignore the data passed in. In the case of AM Tube and Prisma, all the boards were on a shared UART line where work passed into the board-level microcontroller was addressed, which is why each board was given a unique address using the DIP switches. I imagine that's similar to the shared bus Avalon units are on, except addressing is automatic - either hard-coded into each box's internal controller board or there's a detection and assignation protocol, I haven't looked into it far enough to know for sure.
It looks like Bitfury uses unique comms to each chip using a single multiplexer chip, at least in current generations. I believe the old 55nm chips were chained/relayed comms.
Avalon's A3222 and A3218 chips use SPI between them; before that I believe was UART. I haven't looked at the current BM1387 (S9) but BM1380 through 1385 used UART and I don't expect that changed. Bitfury 55nm were SPI. I'm not sure about BW chips or the A1.

True thing, brainfart on my part. They just use some form of chained comms.

Thanks for the info. Definitely interesting.


That's the part of mSPI that was interesting. All the devices shared the same four lines, the SS line would change state indicating the there was new traffic on it's way, the master would put the traffic on the wire, and the devices would pick it up. According to the wikipedia article, the first byte was essentially an address of the desired device. With the free-form of SPI, there would be nothing preventing you from using more than one byte as addressing, except top speed.


The DIP switches kinda reminds me of the old SCSI device addressing. You had to pay attention to the address of each device, so there were no duplicates, and it couldn't be the same as the controller. I seem to recall that later versions of the SCSI protocol introduced chipsets/firmware that could negotiate their buss ID.


Definitely interesting how each of the engineering design teams tackled essentially the same problem.

Thanks for the education @sidehack.

Cheers,

- zed

 Trying to heatsink a chip THROUGH the board is just a nightmare of inefficiency. VERY VERY bad idea.

 On the other hand, trying to get multichips to make good contact with a single HS on top of them isn't fun either - but it's a TON more efficient when you can get it to work.

That's another reason why I like the idea of heatsinks on both sides. As long as all the chips start out coplanar, the one heatsink will keep them pressed flat and tight to the other. I know some people complained about S5 because the boards could warp due to screw placement and some chips wouldn't make good contact. That's a lot less of a problem with a good sandwich.

Yeah, both side nice SOLID heatsinks would tend to help with making good reliable thermal contact long-term.

 Might be a little more expensive, but heatsinks don't cost all THAT much.



 That reminds me - why do you keep specifying you are locked into the "1 kilowatt power consumption" ballpark on the design?

Based on the below quote from the OP


I would say that 1KW is the target because the design is for a consumer-grade miner and 1KW is a sweet spot for those folks operating on 110V PSUs. I could be wrong though and I am sure sidehack will correct me if am. :P

It's been mentioned a couple times, but this is not my project. Basically, I have been asked to oversee design and when I say "those attributes are fixed" what I mean is "those attributes are fixed by the person footing the bill". Y'all know I'd rather see something sub-500W, and my own projects will be.

Well, I stand corrected. I need to pay more attention to which thread I am posting in because you have a lot of miner related threads. :)

This is the only miner design one I've started in a long time. I have sorta laid claim to the Community Miner Development thread, but it's technically kilo17's home turf.

This has been a good one though, for sure.

Why does this thread seem to be asleep? ???

Maybe everything's been said that needs to be?

most of it.

Cause we all got our chips & are already building our miners!!!  :P  :D

1.) An integrated controller will conserve space.
2.) A generic bus would be nice
3.) Hashboards having sub-controllers
4.) If there is a way to control clock speed so as to reduce the noise level; you'd sell out fast
5.) If there is a way to reduce heat output; you'd be in constant demand.

That's pretty much what I came to as well. Additionally, notes 4 and 5 (assuming "heat" is derived more from adjusting core voltage than clock) are mandatory requirements.

I don't know if this info is useful at all, but I found BM1387 chips listed at Bitmain.
They won't appear in your shopping cart though if you try to add them  ;D
https://www.bitmaintech.com/productDetail.htm?pid=00020160824025047591cu3134LW063E

11$ each

There is plenty of other items listed as well here https://www.bitmaintech.com/bitcoin.htm

From my personal opinion...the most important design specs for small scale mining devices are as follows:

1. quiet (large scale mines can easily use loud data center equipment)
2. portable (heavy devices that cost 200$ to ship lose value quickly)
3. chain-able using easily replaceable and common connectors (usb or cat5/6 like the silverfish)
4. cheap non miner components (i don't want to replace a 50$ proprietary part to use a 20$ miner)
5. easily controlled, either a built in controller or a raspi/pc controller option
6. WiFi option (either built in or optional on the controller)
7. stack-able (connect small modules together to make a bigger robot)
8. decently made (I don't want it falling apart before it gives me a chance to use it)
9. easily powered using an existing powering method (usb, 6pin pci, or 12v barrel plugs)
10. variable clock speed/voltage
11. future proof blade design/re-useable case (it would be nice to be able to upgrade the blade with more efficient chips in the future. This way you don't have to discard 20% of the cost of the miner after the end of life period.)
12. worked on by gekkoscience
13. other awesome un-contemplated features.

I quite agree that a miner should be quiet and portable, should not occupy too much space but most importantly is the price of a new miner... it is possible to make budget miners for those on a tight budget?

Hi all,

Call me crazy but I want a KNOB, is that too much to ask?
Control buck converter, core clock, and fan speeds on 6+ miners with a thermal override so as to avaoid hard shutdowns like the s7

Rackmountable, I want to start colocating these things so a clean rack apearance is a must (6U or W.E. works)

- string of miners off a PI would be a must
- wifi is cool
- 5 or 10 pcie sockets, 1200 watts maximum so we can use the little HP guys you sell, maybe 750 so that 2 could hook up to an ant miner psu.

My machines live in liscence grow ops in Detroit and The Bay

Detroit is 3 cents For primary hook ups and we have TONS of space
 
Trueco2oil.com that's me and we don't steal anything

3-cents eh? Hmm. I have 7 semi-retired s7's using Sidehack under-volt/clock mod that pull 930w each and I'm Detroit area. Care to host them? Calc says @ 3 cents they would be good for $1.65 per-day each after deduct for power cost. For that matter, if they can go to a good home...

Trueco2.com - Wonder if Chronic Releaf here carries you? Last few oils I got are from Illuminati Extracts (also CO2 process).

are these miners not being utilized?

Correct. They've been replaced with s9's and another should join them tomorrow if the latest s9 I ordered comes today. Still have 11 more of them (s7's) online. I've limited myself to ~22kw of free power at work so have been slowly replacing the s7's with 9's but am starting to get unsightly retired miner buildup...  Well, the miners aren't so much the problem, it's their damn burros... ;)

well if he doesn't host them, feel free to send one or a few my way

I live in Washington currently but actually used to vend Truelabs to the Ann Arbor area

same technique as true co2 in California

as far as hosting I'll be back in January or February and would love to get together

++++.  Really tho my miners get unplugged because they're loud if they could be spun down easily by worker types that would be cool

Getting OT here but, if you are running s7's do apply Sidehacks mod. Power drops from around 1.2kw each to between 930 to 980w, speeds around 3.7ish THs per miner. Some folks have gotten them down to ~800w but stability could be an issue there. In a warm area, fans can be throttled down a fair bit but still not exactly quiet. They certainly don't scream anymore though :) I've ran those settings most of summer with room ambient around 85-90F. Since plants don't like temps that high then putting miners somewhere in the area around them should work well.
Sample of mod'ed s7's in my farm
https://i.imgur.com/D49gxLil.png