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.
Topic: Community brainpan - please discuss and debate desirable features for a miner - page 4. (Read 5838 times)
June 24, 2016, 12:43:04 PM
June 24, 2016, 12:41:39 PM
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.
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.
June 24, 2016, 11:41:32 AM
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.All of that to say, I agree with you. VLANs would only serve to add complexity that is unnecessary.
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.
June 24, 2016, 06:00:35 AM
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.
All of that to say, I agree with you. VLANs would only serve to add complexity that is unnecessary.
June 24, 2016, 12:53:27 AM
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.
June 23, 2016, 11:52:32 PM
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
June 23, 2016, 11:13:34 PM
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.
June 23, 2016, 10:35:58 PM
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! June 23, 2016, 10:17:30 PM
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.
June 23, 2016, 10:09:29 PM
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. June 23, 2016, 09:44:03 PM
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 June 23, 2016, 09:03:22 PM
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://bitcointalksearch.org/topic/m.15339312 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? June 23, 2016, 06:15:00 PM
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. June 23, 2016, 06:07:37 PM
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... June 23, 2016, 05:27:52 PM
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 >200vacOn 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. June 23, 2016, 04:18:22 PM
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.
June 23, 2016, 01:07:53 PM
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 June 23, 2016, 12:46:21 PM
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? June 23, 2016, 09:40:26 AM
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. June 23, 2016, 09:13:18 AM
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. Jump to:
|
