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

[Quantus]

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

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

[sidehack]

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

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

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

[Mr. Kashif]

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

[chiguireitor]

Nice thread

Some of my suggestions:

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

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

[sidehack]

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

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

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

[cryptotore]

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

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

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

/Sorry for my broken english..

[sidehack]

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

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

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

[NotFuzzyWarm]

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

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

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

[ZedZedNova]

• 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

[ZedZedNova]

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

[sidehack]

would making the six pins for an AVR/ICSP programmer connection accessible

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

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.

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

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

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

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

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.

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

[ZedZedNova]

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

[sidehack]

Nope, that's entirely a coincidence.

[kano]

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

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

[chiguireitor]

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.

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

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.

Hmmm, somehow I don't think this is what you mean by lego miner:

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

[sidehack]

(Bitmain has never used SPI)

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

[ZedZedNova]

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

[sidehack]

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

[chiguireitor]

(Bitmain has never used SPI)

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

[ZedZedNova]

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