Bitcoin Forum
June 25, 2018, 08:31:49 PM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 »
  Print  
Author Topic: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support  (Read 80633 times)
silver71
Member
**
Offline Offline

Activity: 101
Merit: 10

no avatar for now


View Profile WWW
February 20, 2014, 11:10:08 AM
 #401


That looks to work very well. Unfortunately my hashing test is hitting some errors at anything much over 800Mhz.

I don't see chips dropping out or bad results being produced, just that nonces are missed. My code checks for all six nonces in sequence for each job issued (all four chips are run simultaneously and the job queue is kept as full as possible).

I don't think the nonce queue is overflowing as I'm issuing the read result command very frequently (and then checking chip status for finished jobs). I will get a bunch of no results and then a chip reports a nonce that has skipped a previous result.

I haven't looked at power at the board level at all yet - hopefully that's the issue. I think this board is running a little low on the voltage front so hopefully I can clean things up with that.

The good news is that I did get it to run at up to 1.25Ghz (40GH/s). About two-thirds of the nonces were dropped but it successfully ran the test (101 jobs) to completion.

My SPI frequency is a little low (think it's around 250Khz) but I wouldn't expect that to cause issues unless it were so low that the nonce queues couldn't be serviced frequently enough?

For 1.25GHz to work stable, you will need extreme cooling. Once the initial stress is over, I plan to develop a stackable 16-chip board for a submerged setup. A 10 PCB stack will fit into one liter - 160 chips ran at 40GHps, or 6.4TH in-a-box. But for heatsink cooling 1.25GHz is definitively a challenge.

As for the work / result pipelining: luckily, with input and output queues the job feeding and collecting of results is de-coupled, leaving you the freedom to find a good trade-off between their priorities. We dimensioned the output queue based on statistics collected from mining sessions which resulted in 99.9% of all jobs have 4 or less results.

If you run the A1 at nominal speed (800MHz), it will crunch the nonce range in ~160ms. That is, if every 160ms you collect the results and feed new jobs, you should get 99.9% of all potential results. To catch all results of a job with more than 4 winning nonces, you need to poll for results in-between, i.e. check every 80ms and you reduce loosing the 5th result significantly. Obviously, you can't cover all potential use cases and prevent loosing results: assume you have a job with 5 winning nonces that happen to be very close to each other - the chip will spit them out before you have time to collect. But the chances for that are negligible.

Bottom line: if you feed the chip at least every nonce period (e.g. 160ms at 800MHz) and check for jobs every half nonce period, you should be on the safe side.

As for SPI clock, I made some theoretical considerations here: https://bitcointalk.org/index.php?topic=294235.msg4554508#msg4554508



Why 16, when you already have ref.design for 8, and 8 is easier to cool...

Even when you think about immersion cooling, if enything goes wrong, your whole chain (16) goes offline...

Wouldn't it then be smarter to stick with 8 ?

smart solutions from Tesla's home country...
1529958709
Hero Member
*
Offline Offline

Posts: 1529958709

View Profile Personal Message (Offline)

Ignore
1529958709
Reply with quote  #2

1529958709
Report to moderator
1529958709
Hero Member
*
Offline Offline

Posts: 1529958709

View Profile Personal Message (Offline)

Ignore
1529958709
Reply with quote  #2

1529958709
Report to moderator
1529958709
Hero Member
*
Offline Offline

Posts: 1529958709

View Profile Personal Message (Offline)

Ignore
1529958709
Reply with quote  #2

1529958709
Report to moderator
The World's Betting Exchange

Bet with play money. Win real Bitcoin. 5BTC Prize Fund for World Cup 2018.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1529958709
Hero Member
*
Offline Offline

Posts: 1529958709

View Profile Personal Message (Offline)

Ignore
1529958709
Reply with quote  #2

1529958709
Report to moderator
1529958709
Hero Member
*
Offline Offline

Posts: 1529958709

View Profile Personal Message (Offline)

Ignore
1529958709
Reply with quote  #2

1529958709
Report to moderator
zefir
Donator
Hero Member
*
Offline Offline

Activity: 919
Merit: 1000



View Profile
February 20, 2014, 11:52:22 AM
 #402

Why 16, when you already have ref.design for 8, and 8 is easier to cool...

Even when you think about immersion cooling, if enything goes wrong, your whole chain (16) goes offline...

Wouldn't it then be smarter to stick with 8 ?

16 was just a number I pulled from thin air Smiley

As for the technical challenge: with the experience collected so far, I'd say once you have an 8-chip chain working, it is not a huge step to move to 16 chips. At least from the A1 side, I don't understand the DCDC part of it to state it would be easy.

The immersion cooling idea follows DaT's approach here, where due to the high costs of the fluid it is essential to stuff as much hashing power into as little volume as possible. I think one could get a 4x4 A1 matrix onto a 10x10cm^2 PCB and stack them with 1cm distance. Resulting in a 6kW burner in a 1 liter cube.

That would be more of a fun than a serious project and I proposed this to be added as a challenge for Bitmine's planned design contest - which for obvious reasons was put at the back of the priority queue and might never leave the announcement phase Sad


Takers? I'd supply the chips and the fluid.

silver71
Member
**
Offline Offline

Activity: 101
Merit: 10

no avatar for now


View Profile WWW
February 20, 2014, 12:05:11 PM
 #403

Why 16, when you already have ref.design for 8, and 8 is easier to cool...

Even when you think about immersion cooling, if enything goes wrong, your whole chain (16) goes offline...

Wouldn't it then be smarter to stick with 8 ?

16 was just a number I pulled from thin air Smiley

As for the technical challenge: with the experience collected so far, I'd say once you have an 8-chip chain working, it is not a huge step to move to 16 chips. At least from the A1 side, I don't understand the DCDC part of it to state it would be easy.

The immersion cooling idea follows DaT's approach here, where due to the high costs of the fluid it is essential to stuff as much hashing power into as little volume as possible. I think one could get a 4x4 A1 matrix onto a 10x10cm^2 PCB and stack them with 1cm distance. Resulting in a 6kW burner in a 1 liter cube.

That would be more of a fun than a serious project and I proposed this to be added as a challenge for Bitmine's planned design contest - which for obvious reasons was put at the back of the priority queue and might never leave the announcement phase Sad


Takers? I'd supply the chips and the fluid.

Let's first solve present rig delay (non-delivery), and go further with improved cooling ...

About the fluid...you meant oil or 3M-like liquid ?

It would be less expensive to just hook the rig to central heating (as a source), and use household radiators as coolers Smiley

smart solutions from Tesla's home country...
Cheshyr
Full Member
***
Offline Offline

Activity: 168
Merit: 100


View Profile
February 20, 2014, 05:12:36 PM
 #404

Why 16, when you already have ref.design for 8, and 8 is easier to cool...

Even when you think about immersion cooling, if enything goes wrong, your whole chain (16) goes offline...

Wouldn't it then be smarter to stick with 8 ?

16 was just a number I pulled from thin air Smiley

As for the technical challenge: with the experience collected so far, I'd say once you have an 8-chip chain working, it is not a huge step to move to 16 chips. At least from the A1 side, I don't understand the DCDC part of it to state it would be easy.

The immersion cooling idea follows DaT's approach here, where due to the high costs of the fluid it is essential to stuff as much hashing power into as little volume as possible. I think one could get a 4x4 A1 matrix onto a 10x10cm^2 PCB and stack them with 1cm distance. Resulting in a 6kW burner in a 1 liter cube.

That would be more of a fun than a serious project and I proposed this to be added as a challenge for Bitmine's planned design contest - which for obvious reasons was put at the back of the priority queue and might never leave the announcement phase Sad


Takers? I'd supply the chips and the fluid.
I'd be glad to poke at that after we finish these first two A1 designs.  I've got a gallon of Novec 7000 in the corner, and was planning on playing with it using A1s anyway.

DCDC will be the real problem, and it really depends how fast you plan to clock the chips. 
goodney
Member
**
Offline Offline

Activity: 102
Merit: 10


View Profile
February 20, 2014, 09:18:02 PM
 #405

I haven't looked at power at the board level at all yet - hopefully that's the issue. I think this board is running a little low on the voltage front so hopefully I can clean things up with that.

totalslacker:

Have you been able to measure the current or power consumed by one chip at 800Mhz?

Thanks!

-a[g
zefir
Donator
Hero Member
*
Offline Offline

Activity: 919
Merit: 1000



View Profile
February 20, 2014, 09:37:14 PM
 #406

Notification: A1 CoinCraft Desk cgminer driver now upstreamed

Since some of you asked for it: as of today, Con pulled the current A1 driver (as variant for CoinCraft Desk) into cgminer. I will follow soon with the variant for the Rig, and after we get the products into delivery state, I'll also work on a bfgminer integration.

totalslacker
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
February 21, 2014, 12:11:27 AM
 #407


Have you been able to measure the current or power consumed by one chip at 800Mhz?


Not a super accurate measurement, but it looks to be about 20A. This is when the chip is around 40C as it gets hotter the current goes up (I was seeing around 22-24A at 60C). I do have the board instrumented so that I should be able to get more accurate results, I just haven't written code to look at that yet Smiley

Oh, this was with a core voltage of 0.84V. So looks to be pretty spot-on at 0.67W/GH at 25GH/s (assuming you have decent cooling).
drinkmorecoffee
Jr. Member
*
Offline Offline

Activity: 58
Merit: 0



View Profile WWW
February 21, 2014, 06:22:22 PM
 #408

Code merged into master cgminer, thanks.

zefir previously mentioned that cgminer has support for MCP2210-based boards (with USB comms to a PC rather than a RasPi).  Does this merge now mean that a current-version build of cgminer will run the A1 chips direct from a PC, if the MCP2210 is included?

That would be sweet...
zefir
Donator
Hero Member
*
Offline Offline

Activity: 919
Merit: 1000



View Profile
February 21, 2014, 07:19:00 PM
 #409

Code merged into master cgminer, thanks.

zefir previously mentioned that cgminer has support for MCP2210-based boards (with USB comms to a PC rather than a RasPi).  Does this merge now mean that a current-version build of cgminer will run the A1 chips direct from a PC, if the MCP2210 is included?

That would be sweet...

No, the current version runs exactly the CoinCraft Desk which is driven by a RasPi over its SPI interface. To make it working over MCP2210, one would need to wrap the SPI interface (which is abstracted over spi-context.c already) over MCP2210. Should be easy to implement, alas I currently am too busy so look at.

drinkmorecoffee
Jr. Member
*
Offline Offline

Activity: 58
Merit: 0



View Profile WWW
February 21, 2014, 08:00:39 PM
 #410

Code merged into master cgminer, thanks.

zefir previously mentioned that cgminer has support for MCP2210-based boards (with USB comms to a PC rather than a RasPi).  Does this merge now mean that a current-version build of cgminer will run the A1 chips direct from a PC, if the MCP2210 is included?

That would be sweet...

No, the current version runs exactly the CoinCraft Desk which is driven by a RasPi over its SPI interface. To make it working over MCP2210, one would need to wrap the SPI interface (which is abstracted over spi-context.c already) over MCP2210. Should be easy to implement, alas I currently am too busy so look at.

Very good, thanks for the quick reply.  I've heard a couple comments that the RasPi is not suitable for this sort of thing, but hearing that it's used in the Desk product (a professional, commercial product) is reassuring.

Back to work!

Thanks again!
zefir
Donator
Hero Member
*
Offline Offline

Activity: 919
Merit: 1000



View Profile
February 21, 2014, 08:10:54 PM
 #411

Very good, thanks for the quick reply.  I've heard a couple comments that the RasPi is not suitable for this sort of thing, but hearing that it's used in the Desk product (a professional, commercial product) is reassuring.

I guess what you refer to is the known problem of the RasPi wearing out the SD-card if you run it over standard Linux system over long time - which I personally did not notice working ~3 months mostly compiling with continuous write access to the card.

To be on the safe side, the FW provided with the Desk is mostly read-only, i.e. it writes to the SD-card only on re-configuration, while everything else goes into memory mapped filesystems.

jbcheng
Jr. Member
*
Offline Offline

Activity: 42
Merit: 0


View Profile
February 21, 2014, 08:26:27 PM
 #412

Code merged into master cgminer, thanks.

zefir previously mentioned that cgminer has support for MCP2210-based boards (with USB comms to a PC rather than a RasPi).  Does this merge now mean that a current-version build of cgminer will run the A1 chips direct from a PC, if the MCP2210 is included?

That would be sweet...

No, the current version runs exactly the CoinCraft Desk which is driven by a RasPi over its SPI interface. To make it working over MCP2210, one would need to wrap the SPI interface (which is abstracted over spi-context.c already) over MCP2210. Should be easy to implement, alas I currently am too busy so look at.

hi Zefir
Our team also stuck on this part at the moment, Known you are quite busy, while would you please take some time and help to develop a version over a PIC? as this is a important step for multi modules integration. Thanks

Jbcheng
zefir
Donator
Hero Member
*
Offline Offline

Activity: 919
Merit: 1000



View Profile
February 21, 2014, 08:40:29 PM
 #413

hi Zefir
Our team also stuck on this part at the moment, Known you are quite busy, while would you please take some time and help to develop a version over a PIC? as this is a important step for multi modules integration. Thanks

Jbcheng

Hi,

'quite busy' is quite some understatement - I am out of this world for at least the next 4 weeks to finalize the SW for the CoinCraft products and clean up the mess I will have been left behind me until then.

I'd support the community as best as I can (like I have been doing so far), but working on another driver / FW now is completely out of reach for me.

But this is exactly the idea behind the open source DIY approach: stick together and share your potential. There are at least 20 projects working on something, and while at some point we all are competitors, we at the same time profit from cooperation. I know marto74 did his firmware for a PIC, as well as the WASP team is working on some framework for mining endpoints. There are also at least 2 teams working on a USB->SPI bridge approach. I'm pretty sure that if one party starts to publish their work on FW as open source, everybody else will join to be the second. It only takes one team to step up...


Cheers,
zefir

silver71
Member
**
Offline Offline

Activity: 101
Merit: 10

no avatar for now


View Profile WWW
February 21, 2014, 08:46:22 PM
 #414

Very good, thanks for the quick reply.  I've heard a couple comments that the RasPi is not suitable for this sort of thing, but hearing that it's used in the Desk product (a professional, commercial product) is reassuring.

I guess what you refer to is the known problem of the RasPi wearing out the SD-card if you run it over standard Linux system over long time - which I personally did not notice working ~3 months mostly compiling with continuous write access to the card.

To be on the safe side, the FW provided with the Desk is mostly read-only, i.e. it writes to the SD-card only on re-configuration, while everything else goes into memory mapped filesystems.

With current SD-card prices this would not be an issue, if reasonable user, clones SD-cards prior of using them, and swaps them if they fail...on the other hand I would rather choose Arduino over Pi, but...that's me...now it's all - whatever works first...

...and when talking about sharing mutual knowledge and learning from it...

maybe something usefull comes from Scrypt-ASIC teams...and their open-source PCB's :
https://github.com/losh11/aura-asic

smart solutions from Tesla's home country...
drinkmorecoffee
Jr. Member
*
Offline Offline

Activity: 58
Merit: 0



View Profile WWW
February 21, 2014, 09:35:35 PM
 #415

Why is Bitmine no longer allowing payment in BTC?  I was just about to order a couple samples and the BTC payment option is just... gone.  Is this a temporary thing, or what? 

I wrote their support people but haven't heard back.  Anyone know anything?
jbcheng
Jr. Member
*
Offline Offline

Activity: 42
Merit: 0


View Profile
February 22, 2014, 01:29:31 AM
 #416

That's really bad news for Bitmine do not accept BTC payment. We can use the realtime exchange rate and this shall not be too complicated?
Bicknellski
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000



View Profile
February 26, 2014, 07:53:13 AM
 #417

Why 16, when you already have ref.design for 8, and 8 is easier to cool...

Even when you think about immersion cooling, if enything goes wrong, your whole chain (16) goes offline...

Wouldn't it then be smarter to stick with 8 ?

16 was just a number I pulled from thin air Smiley

As for the technical challenge: with the experience collected so far, I'd say once you have an 8-chip chain working, it is not a huge step to move to 16 chips. At least from the A1 side, I don't understand the DCDC part of it to state it would be easy.

The immersion cooling idea follows DaT's approach here, where due to the high costs of the fluid it is essential to stuff as much hashing power into as little volume as possible. I think one could get a 4x4 A1 matrix onto a 10x10cm^2 PCB and stack them with 1cm distance. Resulting in a 6kW burner in a 1 liter cube.

That would be more of a fun than a serious project and I proposed this to be added as a challenge for Bitmine's planned design contest - which for obvious reasons was put at the back of the priority queue and might never leave the announcement phase Sad


Takers? I'd supply the chips and the fluid.

Ice Wasp is something we are keen on doing... just need to get our Wasps finished first.

Dogie trust abuse, spam, bullying, conspiracy posts & insults to forum members. Ask the mods or admins to move Dogie's spam or off topic stalking posts to the link above.
zefir
Donator
Hero Member
*
Offline Offline

Activity: 919
Merit: 1000



View Profile
February 27, 2014, 09:05:28 AM
 #418

Update: Chip Distribution closed

That's it, I assigned all remaining chips for assembly and with that this DIY chip distribution is closed.

Chips will remain available through Bitmine's web-shop, even in sample quantities.


Thank you all for your trust and support. Good luck with your projects, especially since times became more stormy in bitcoin land recently.

marto74
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile WWW
February 27, 2014, 09:13:46 AM
 #419

Thank you for the opportunity to start our design.
As usual it was pleasure doing business with you.
Looking forward for future projects.
We wish you and the Bitmine team all the best.

http://technobit.eu
tips : 12DNdacCtUZ99qcP74FwchaCPzeDL9Voff
vs3
Hero Member
*****
Offline Offline

Activity: 622
Merit: 500


View Profile WWW
February 27, 2014, 09:22:46 AM
 #420

Zefir - thanks again for all of your work and helping the community with this project!

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!