Community Miner Design Discussion

[cavaliersrus]

what about the ability to run them with a nic on each miner

or run 1 nic to a switch then the others would connect via usb to miner 1 and make a usb hub style where they could daisy chain down the line with less clutter of going mass into a switch with alot of cat 5 cables ? just a idea i had kinda like the old firewire days where you could keep chaining devices down the line till u needed another hub to boost the power

I would like to see the actual error statistics from those daisy-chained Firewires. I saw some stats from high-end MacIntoshes driving stacks of 5-6 external disks each through Firewire 400. This wasn't anything good and they did run in very clean offices not garages, like the mining farms.

i never ran them but i know my school used to and they hardly ever failed... i bet theres some info online about them though

[1715008851]

1715008851

[2112]

i never ran them but i know my school used to and they hardly ever failed... i bet theres some info online about them though

I'm actually familiar with the broad error statistics for i.LInk & Firewire 400 and I call bullshit on "hardly ever failed". More likely "hardly ever used, so nobody noticed the failures or was scared to report the failures to the teachers". Coin mining is supposed to work 24*7.

[sidehack]

Also as mentioned about an hour previous, that'd require building a hub chip onto each board - as well as a second jack. Same number of cables required, and also more complexity and cost. I'm not going to spec that into the "standard" also because it doesn't make sense for all use cases. Course someone else building his own boards around the framework can do whatever the heck he wants for daisychain.

[tvasbn]

Guys I'm super excited about this personally and want to help as much as I can!

I'll discuss internally if and how BitFury could contribute to this project. Our reference design PCB for 16nm is almost done and could be used as a starting point should BitFury's chip be selected.

Fantastic help will be providing gerber files of the boards . The low density air cooled ones will doo

Whit that and whit an 500K MOQ of chips, definitely some groups will put money together and make an PCB bord order. Sure must be some small PCB manufactures that take 100-200K orders.

A huge + will be for european costumers which in case of building the boards on a local manufacturer will avoid paing VAT.

[philipma1957]

what about the ability to run them with a nic on each miner

or run 1 nic to a switch then the others would connect via usb to miner 1 and make a usb hub style where they could daisy chain down the line with less clutter of going mass into a switch with alot of cat 5 cables ? just a idea i had kinda like the old firewire days where you could keep chaining devices down the line till u needed another hub to boost the power

I would like to see the actual error statistics from those daisy-chained Firewires. I saw some stats from high-end MacIntoshes driving stacks of 5-6 external disks each through Firewire 400. This wasn't anything good and they did run in very clean offices not garages, like the mining farms.

i had a lot of firewire 400 fire wire 800 they were a bit more reliable then usb2.  but the cables are costly.

usb2 I have run 121 usb2 sticks off 1 pc.  but truth be told it was a pita

but 40 usb sticks easy.

17 gridseed blades on 1 pc a pita but 12 blades on 1 pc was easy.

I have 4 or 5 pcs

 so putting 1  on the side to mine a dozen pcbs in the solar array should be a piece of cake

[alh]

While I liked the Firewire disk devices that I had, it's day is long since over. The USB universe has completely run roughshod over Firewire. Hubs, ports, cables are way more available and less costly for USB than Firewire.

It would be nuts to have your hashing hardware require a Firewire port for correct operation.

[2112]

i had a lot of firewire 400 fire wire 800 they were a bit more reliable then usb2.  but the cables are costly.

usb2 I have run 121 usb2 sticks off 1 pc.  but truth be told it was a pita

but 40 usb sticks easy.

17 gridseed blades on 1 pc a pita but 12 blades on 1 pc was easy.

I have 4 or 5 pcs

 so putting 1  on the side to mine a dozen pcbs in the solar array should be a piece of cake

I'll definitely agree to "bit more reliable". The most common standard USB Type-A is probably the worst and least reliable connector in the history of personal computing. A sneeze nearby can cause a disconnect. I haven't tried farting test, but I believe it would fail too. But it also the cheapest connector in the history of personal computing.

Mini-USB has orders of magnitude better reliability than standard-USB. Micro-USB is again orders of magnitude better than mini-USB.

But I guess that the part of mining hobby is glue-gunning the loose USB Type-A connections; swapping cables and hubs until "Eureka! it works!".

[2112]

While I liked the Firewire disk devices that I had, it's day is long since over. The USB universe has completely run roughshod over Firewire. Hubs, ports, cables are way more available and less costly for USB than Firewire.

It would be nuts to have your hashing hardware require a Firewire port for correct operation.

Agreed.

The same can be told about daisy-chaining, no matter what is the actual connector and protocol. Even on-the-PCB daisy-chaining is going to be depreciated. I believe sidehack & friend have chosen an MCU with enough SPI or UART ports to have point-to-point connection to each hashing chip.

[sidehack]

Funny, because I have exactly the opposite experience. I've never had USB-B problems, but mini are decent (though sometimes the connector comes off the board) and micro tend to disconnect, or more likely break, all over. I will never deliberately put a micro USB connector on something I want to work for very long. My first preference is USB-B, followed by mini.

[Witrebel]

Just throwing a dart at a the dart board here, but how much complexity would be added if there was on option for USB and I2C connectivity?  

Those folks not comfortable with lower level interfaces stick to the default USB setup.  

If you want to use it as an I2C slave, you set a board level slave address via the USB, and then you can string up however many boards you want, up to 256 or whatever the max is.  

I am not very familiar with writing drivers, but I would think the majority of the code body on both the boards MCU and the cgminer side wouldn't care if it was running on usb vs I2C, just a different physical layer, with maybe a slight difference in the addressing mechanisms?  

Just playing devils advocate here, as I completely agree that USB makes the most sense if you have to pick only one option.  Just curious if its possible to at least provision for the DIY guys to run it on I2C if they really wanted.

[sidehack]

Yeah that's great, since the micro has an I2C bus. Except it's already in use talking to sensors as specified in my post on the first page. So if you want to make sure to address around those sensors (which are going to be implementation-dependent of course) I guess it's possible. And then add that into the firmware. And then add it into the driver on whatever you're compiling cgminer on.

So, to be not sarcastic, yes it's possible. Also, I'm not gonna do it. Please read my post on the first page with a description of everything I am going to do. If you want to extend that further on your own you're welcome to it, but I'm not going to. One of the things mandated was no design-by-committee because exactly this kind of thing happens. Feature creep kills time-sensitive projects just as much as anything. So, no offense guys, but I'm probably going to ignore all suggestions for at least the next month or so since Novak and I already spent most of a year talking over and ironing things out to where they are now and I figure that's good enough.

[2112]

Funny, because I have exactly the opposite experience. I've never had USB-B problems, but mini are decent (though sometimes the connector comes off the board) and micro tend to disconnect, or more likely break, all over. I will never deliberately put a micro USB connector on something I want to work for very long. My first preference is USB-B, followed by mini.

I'm not really sure if your experience is indicative.

The broad industry reliability statistics are:

Standard Type-A < Standard Type-B < Mini-B < Micro-B

The Mini-A and Micro-A weren't deployed widely enough.
 

[NotFuzzyWarm]

what about the ability to run them with a nic on each miner

or run 1 nic to a switch then the others would connect via usb to miner 1 and make a usb hub style where they could daisy chain down the line with less clutter of going mass into a switch with alot of cat 5 cables ? just a idea i had kinda like the old firewire days where you could keep chaining devices down the line till u needed another hub to boost the power

I would like to see the actual error statistics from those daisy-chained Firewires. I saw some stats from high-end MacIntoshes driving stacks of 5-6 external disks each through Firewire 400. This wasn't anything good and they did run in very clean offices not garages, like the mining farms.

Here are Firewire stats from one of our systems that has been running 24x7 for the past 3 weeks. It has 14 axes of motion with the motor drives fed via Firewire in a daisy-chained star config. 1 main feed to 1st driver, branching out to 2 more drives, branching out to two more, etc.
https://imgur.com/kvWcSM1

Perfect with zero errors. Then again, they are fed by the motion systems RTOS which WIndoze rides on top of...

[bctmke]

Yeah that's great, since the micro has an I2C bus. Except it's already in use talking to sensors as specified in my post on the first page. So if you want to make sure to address around those sensors (which are going to be implementation-dependent of course) I guess it's possible. And then add that into the firmware. And then add it into the driver on whatever you're compiling cgminer on.

So, to be not sarcastic, yes it's possible. Also, I'm not gonna do it. Please read my post on the first page with a description of everything I am going to do. If you want to extend that further on your own you're welcome to it, but I'm not going to. One of the things mandated was no design-by-committee because exactly this kind of thing happens. Feature creep kills time-sensitive projects just as much as anything. So, no offense guys, but I'm probably going to ignore all suggestions for at least the next month or so since Novak and I already spent most of a year talking over and ironing things out to where they are now and I figure that's good enough.

Just for the sake of posting it here.

Here's what sidehack et al have laid out

https://bitcointalk.org/index.php?topic=1368507.msg13932487#msg13932487

[2112]

Yeah that's great, since the micro has an I2C bus. Except it's already in use talking to sensors as specified in my post on the first page. So if you want to make sure to address around those sensors (which are going to be implementation-dependent of course) I guess it's possible. And then add that into the firmware. And then add it into the driver on whatever you're compiling cgminer on.

So, to be not sarcastic, yes it's possible. Also, I'm not gonna do it. Please read my post on the first page with a description of everything I am going to do. If you want to extend that further on your own you're welcome to it, but I'm not going to. One of the things mandated was no design-by-committee because exactly this kind of thing happens. Feature creep kills time-sensitive projects just as much as anything. So, no offense guys, but I'm probably going to ignore all suggestions for at least the next month or so since Novak and I already spent most of a year talking over and ironing things out to where they are now and I figure that's good enough.

You won't be able to get I2C to work reliably from one PCB to another PCB. Technically its a complete loss.

SMBus is very similar to I2C and if used on expansion board it is routed through a separate pair of twisted wieres, e.g. Wake-on-LAN.

[2112]

Here are Firewire stats from one of our systems that has been running 24x7 for the past 3 weeks. It has 14 axes of motion with the motor drives fed via Firewire in a daisy-chained star config. 1 main feed to 1st driver, branching out to 2 more drives, branching out to two more, etc.
https://imgur.com/kvWcSM1

Perfect with zero errors. Then again, they are fed by the motion systems RTOS which WIndoze rides on top of...

"daisy-chained star config?" What is that? Iron butter? Daisy-chained and star(hub & spoke more generally) are polar opposites.

Not sure what you are trying to say here.

Also, what kind of Firewire connectors are you using?

[NotFuzzyWarm]

Funny, because I have exactly the opposite experience. I've never had USB-B problems, but mini are decent (though sometimes the connector comes off the board) and micro tend to disconnect, or more likely break, all over. I will never deliberately put a micro USB connector on something I want to work for very long. My first preference is USB-B, followed by mini.

I'm not really sure if your experience is indicative.

The broad industry reliability statistics are:

Standard Type-A < Standard Type-B < Mini-B < Micro-B

The Mini-A and Micro-A weren't deployed widely enough.

Also if it connector durability really becomes an issue one can always use industrial grade high-retention force USB sockets. Exceeding reliable but also cost around 5x what you can get normal USB sockets for...

[NotFuzzyWarm]

Here are Firewire stats from one of our systems that has been running 24x7 for the past 3 weeks. It has 14 axes of motion with the motor drives fed via Firewire in a daisy-chained star config. 1 main feed to 1st driver, branching out to 2 more drives, branching out to two more, etc.
https://imgur.com/kvWcSM1

Perfect with zero errors. Then again, they are fed by the motion systems RTOS which WIndoze rides on top of...

"daisy-chained star config?" What is that? Iron butter? Daisy-chained and star(hub & spoke more generally) are polar opposites.

Not sure what you are trying to say here.

1 Firewire cable from the PC feeds first drive, that drive and all other drives is also a repeater (hub) with extra 2 ports. Each port from that drive feeds 2 more drives which also have 2 extra ports, those feed 2x more drives, rinse and repeat. Think of a tree, first FW cable from the PC is the trunk which branches out at each drive and the branches have branches. Any other name for that branching config?

[sidehack]

I just want a connector I'm not going to break, which does not include micro or mini. I have to wedge my phone and lay a brick across the cable jack to get it to charge off its shoddy micro connector, which is typical of devices I've seen. I've remounted a lot of mini connectors on stuff because they ripped free of the boards (I'm looking at you, New R-Box) but rarely because the jack broke. And after a couple years of refurb I never saw a busted B jack.

[2112]

Also if it connector durability really becomes an issue one can always use industrial grade high-retention force USB sockets. Exceeding reliable but also cost around 5x what you can get normal USB sockets for...

Look, it is a desperation solution. I've even seen people routing USB signals through the Neutrik stage audio connectors. (http://www.neutrik.us/) But what's the point.

For industrial-scale mining the multipoint solution will be the best. I'm not a particular advocate of CAN over competitors, but cheap automotive-grade CAN will beat any USB both on price and reliability.