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

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

[in2tactics]

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.

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.

[2112]

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.

[sidehack]

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.

[toptek]

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.

[sidehack]

No USB dongles. No external boards for fan control.

[toptek]

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 .

[sidehack]

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.

[toptek]

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


  

[sidehack]

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.

[sidehack]

Hopefully fourth time's the charm...

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

I think ... you missed the part where it'd be a single ~1KW miner

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.

An internal Ethernet-connected controller using off-the-shelf hardware like a Pi makes sense.

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.

[NotFuzzyWarm]

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.

[ZedZedNova]

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.

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.

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.

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

[NotFuzzyWarm]

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

[sidehack]

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.

[irritant]

raspberry model 3 has wifi built in

[sidehack]

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.

[ZedZedNova]

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.

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.

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.

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

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.

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?

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.

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.

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.

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.

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.

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

[ZedZedNova]

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

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

[QuintLeo]

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.

 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.