I would like to solo mine (not BTC) via network with Avalon 6. I have tried google for a few days and all I could come up was the IP address of the Avalon 6 and the possibility of using Multiminer. I can't get the Avalon to be detected by Multiminer after a many hours...
If anyone can point me to a way to solo mine using windows and Avalon 6 over LAN that would be awesome. I have had no issues with solo mining with CPU and GPU but ASIC is a different beast to me...
Thanks for your time!
Sure but you really want a rasp pi not windows. I solo mined PPC with the avalon 6 http://mining.securepayment.cc/pools/ppcoin/stats.php?address=PV68JwCpM5CGGf9rirFS7weYWXnMeiyCaC&submit=Lookup+StatsI hit a few blocks. Mind you this is not pure solo mining. The avalon 6 will only mine sha 256 so BTC and PPC will work FYI, securepayment.cc hasn't updated their PPC pool to the new fork so any hashing you do there is wasted hash. I was trying to hash there with my Compac stick miner. I'll dig up the thread with my question, and the answer I received. edit: found it - https://bitcointalk.org/index.php?topic=601925.msg15282523#msg15282523- zed |
|
|
|
http://www.nytimes.com/2016/07/03/business/dealbook/bitcoin-china.html?ref=business&_r=0Look at the pictures and notice the cleanroom conditions in the mining data center; check out the lovely cabling at the mains power distribution box. The wire routing is a thing of beauty.  The Bitcoin mining machines in his facilities use about 38 megawatts of electricity, he said, enough to power a small city. Might be tough to build a new power generation facility behind my house... - zed
|
|
|
|
I just wish the thoroughness didn't come at the cost of time that's already been lost due to customs and delivery hangups. Nothing says "expected delivery June 21st" like packages showing up on June 30th, after something like 3 emails and 5 phone calls to the carrier. No worries @sidehack those are things beyond your control. When things are under your control you are doing what you think needs to be done, and letting us know. That always wins in my book. Cheers, - zed |
|
|
|
|
Nice! I have space cleared and ready. Really looking forward to it.
|
|
|
|
... ASIC Fairy going to sprinkle her fairy dust on some corn flakes for you? And here I was thinking Luck Charms, you know, because they're magically delicious. Oh, and the give you a wicked sugar high. |
|
|
|
Super excited to order one! A bit of a noob question here: How well does this work with Raspberry Pi? Or would it just be easier/better to run on Windows or Linux? The Compac is pretty easy to get running on most platforms. There are a number of people on this thread that are running them on RasPi. I'm running mine on a Mac. Follow the instructions in the OP (and in other posts on the 1st or 2nd page of messages. Lots of good and helpful info. The one common thread for most folks is that they are using an external powered USB hub. That is critical because as you crank up the core voltage and clock speed these Compacs can draw quite a bit of current. If you search this thread (or maybe check the OP) you will see the various recommendations for which USB hub works with which platform. The caveat with the RasPi that I remember is that it prefers USB 2 versus USB 3. Cheers, - zed |
|
|
|
Thanks for the info. Definitely interesting. 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. 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. 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. 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. 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. Definitely interesting how each of the engineering design teams tackled essentially the same problem. Thanks for the education @sidehack. Cheers, - zed |
|
|
|
Yes I am really hoping that they adjust their prices after the halving. They haven't adjusted the prices for their older S7 and S7-LN in a while which really surprises me. As long as Bitmain sells every one of the miners they make they can charge as much as they want. Free market capitalism at it's best. Think about how fast each batch of the S9 miners has "sold out." Would you lower your prices if you were selling everything you made? Probably not, and you might even raise your prices to see how much more you could make. Oh, sure, some of the people buying the miners will complain about the price, but at the end of the day they still sent the BTC or used a credit card to buy them. If/when another company selling equivalently powerful miners arrives on the scene is likely when you will see prices moderate. Cheers, - zed |
|
|
|
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.
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. 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 |
|
|
|
Hi all, i live in usa and have electricity included in my rent. Id like to find the cheapest way to start mining but all i have is Windows computers and lapptops.
any help?
GekkoScience Compac miner. It's inexpensive, doesn't need a lot of power, and cgminer can run on a windows machine. If you want to overclock it you will need an external powered USB hub. Check out this thread for more info: https://bitcointalk.org/index.php?topic=1173963.0I have one of these overclocked to 325MHz and it generates ~17.9 GH/s reliably. It won't earn you but maybe 1,000-1,200 Satoshi (BTC0.00001000 - BTC0.00001200) per block, with 2-6 blocks per day depending on the luck of your pool. Mine is pointed at the kano.is pool. If you want to actually have a chance at earning something worthwhile, the Bitmain antminer S9 is the current state of the art, but it's not cheap, and you have to be fairly quick to order one when they make them available. If you are willing to go with an older generation chip from Bitmain, consider buying an antminer S7-LN, or a used antminer S7. There is also the option of trying to pick up a use Canaan Avalon6. Since you posted in the Bitcoin -> Mining -> Mining speculation forum, I won't suggest alt-coin mining rigs. There is a whole set of boards for that under the Alternate Cryptocurrencies section on this website. Cheers, - zed edited: corrected earnings based on my account at kano.is |
|
|
|
... probably the easiest solution would be to use a CP2102 Would that be the device that influenced the GekkoScience name? I looked up the device, and noticed the image that they used and the name of one of their dev kits. Cheers, - zed |
|
|
|
In America it's pretty much understood that committees never actually accomplish anything One of my teachers, probably in high school, defined a committee as a living organism with many stomachs and no brain. That definition and what it connotes stays with me. If I am asked to be part of a committee, it has got to be a small number of people, perhaps 3-5, who, as @sidehack said, have broad knowledge and the ability to get it done. There are two things I would add to that and they are an open mind and a willingness to learn new things. It's far easier to reach a consensus with a small group of people than a larger group. In the larger group you will likely find that there is a small group that does the work (has the knowledge and the willingness to express their opinion publicly), and who the other members follow. Your mileage may vary. I know that mine does. Cheers, - zed |
|
|
|
... the objective of this community miner is not to compete with industrial scale production, it is not to make a profit, it is not to change the face of Bitcoin or the direction it is going. I think this project is a simple plan to produce a miner that common people that love Bitcoin can purchase, mine with and enjoy.
It is also a place to listen to what the little guys want and to respond.
ding! ding! ding! We have a winner! @Kilo17 hit the mark. I'm interested and have been annoying @sidehack and the other contributors/readers on the other thread with my thoughts. I'm not into mining to corner the hashing market, I'm in it as a hobby. If the miner returns my investment, sweet! If it doesn't, that's OK, too. It's also really cool that I can help someone realize their goal of designing and producing a working miner. If they make some coin from my purchase, that's great. It also gives them the incentive to produce the next cool miner, or whatever. Cheers, - zed |
|
|
|
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. 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... |
|
|
|
- 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.
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. - 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.
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 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.
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. - 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?
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?  - 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.
Hmmm, somehow I don't think this is what you mean by lego miner:  I know some of my suggestions are a little pie in the sky, but we're talking about an ideal miner, right? RIGHT?
True, but it's pie-in-the ideas that make folks think about what it is they are doing, questioning their assumptions, and perhaps making changes. Going into this thread @sidehack had some thoughts and ideas of what he wanted to do, and I would imagine that his design has shifted somewhat, or perhaps evolved is a better word, from the discussion in this thread. Cheers, - zed |
|
|
|
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 |
|
|
|
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/2885or 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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
|
Show Posts
