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

[philipma1957]

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 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?

[dunand]

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

[sidehack]

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?

[notlist3d]

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.

[Entropize]

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.

[sidehack]

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.

[bronxnua]

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?

[philipma1957]

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

[sidehack]

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.

[NotFuzzyWarm]

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.

[NotFuzzyWarm]

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...

[sidehack]

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,

...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.

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.

[NotFuzzyWarm]

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?

[ZedZedNova]

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?

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

[2112]

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.

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.

[sidehack]

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.

[2112]

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:

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!

Б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й!

[sidehack]

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.

[ZedZedNova]

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.

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.

... A miner requring the customer to use VLANs very much violates the "simple" requirement.

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:

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?

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.

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.

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

[2112]

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. 

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.