No, please don't do that. If you want me to continue contributing some feedback, please do not nail me down to official statements. Official statements are Giorgio's business and I am not going to interfere with that.

Regarding the Rig's performance, conduct from the numbers: a fully populated Rig has 96 chips, at nominal clocks they do generate 2.4THps. With the 25% overclockability used in the Desk, there is a reserve up to 3THps. With that and the experience we have so far, 3THps is expected to be within reach. But still: this is an expectation. Simulations indicate that you can get out that much heat out of the box, but giving a guarantee based on simulations is just not serious.

SW is ready, I have one Rig board in hand running stable for days. HW is also ready, but did not pass long term stability tests. EE folks are working to bypass observed issues.

As for the over-clocking / turbo-mode: guys, no need to speculate - as I wrote several times, trubo mode is doable on chip or board basis, but is controllable on a product basis only to the extent that is already supported by FW (25% overclocking). I could post here what is required to drive a single board to 40-50% higher hashrates, but trying that would void your warranty. Seriously, it is not worth it.

The host SPI clock must be lower than the intra chip SPI clock, which is derived from the system_clock and a default divider of 64. For the nominal clock of 800MHz the intra chip clock results to 12.5MHz. With that, 8MHz host SPI clock is safe for system clocks above 550MHz and should be reduced otherwise.

What updates are you looking for?

The parameters are well explained: the boards use a ref-clock of 16MHz, you can enter arbitrary values for system clock (which is the A1 clock). The three clock rates used (600, 800, 1000) are those we performed long-term tests in the lab. At 1000 MHz and an ambient of 25°C, the 1.5kW PSU is at its edge - it will shut down if you go far beyond that value. Even if it does not, there is a sweet spot for the clock rate depending on various factors (environment, chips, PSU, etc.) which needs to be found out individually and is useless to go beyond. Your best take is to start at nominal (800MHz) and do long-term measurements with continuously increasing clock by 50MHz.

At some point you will notice that increasing clock will slightly improve your cgminer hashrate, but not that at the pool. This means that the increased processing rate is eaten up by HW errors. Since ambient temperature is a major factor for this sweet spot, it can not be pre-configured. It is also difficult to automate, due to the large number of depending parameters. If someone is eager to work on auto-tuning, I can provide information on how to access the sensor data.

Generally about over-clocking, do your math before you try to squeeze the last MHz out of the box: at nominal (800 MHz) a fully populated Desk gives 1THps for a total of ~960W at wall. At 1000MHz you get around 1.2THps for 1.5kW - you buy 20% more hashrate for 55% more power (and heat). With even higher clocks this non-linear relation gets worse - up to the point where power cost eat up potential gains.

a) what is the advantage of having a secondary SD card slot over flashing the new FW image to your miner's primary SD card once you are done creating it?
b) the SD-card is almost read-only, i.e. only configuration changes are written, everything else goes into memory mapped temp file systems - with that, risk of wearing out the SD card is minimal
c) the FW image is tiny (like 30-50MB) and won't grow significantly in the future; the blockchain is not stored on the SD (for what?), so the smallest SD-card available is still orders of magnitude too big for the FW - we won't run into space issues



This is the DIY thread, i.e. meant for those who are doing their own design and needed chips in smaller quantities to test prototypes. Chips will remain available at Bitmine's online-shop, either in production volumes or in single sample chip quantities.

As for the board design: if you are not going to design your own board, you might want to contact one of the various projects that are working on A1 based mining gear.

Of course I am reading this thread and working on real issues people bring up here.

The 'Official' thread was closed temporary not because Bitmine does not care, but to find ways to make it usable again as communication platform. First measures were already taken (reports to mods), next are being worked on.

I told already too much in the official thread - instead of honoring my openness, some users preferred to weight each word I wrote and to turn it into flames, insults, and personal attacks. With publicly stated threats of legal actions against Bitmine, even if I had something to say, I am not permitted to. For sure I am collecting objective feedback and will keep supporting customers and resolve problems, but I can't comment on company internals over what is posted by the management.

But look at the facts - not claims Bitmine does, but facts customers report. In essence, a) we are working as fast as possible (also on the Rig) - since with any delay any potential profit is melting away; and b) we are respecting the ToS, which guarantees that nobody will take a loss. Of course customers are disappointed for not getting 1500% ROI - but since nobody is asking for refunds, the CPP terms can't be that bad - even with the delays we have.


That's all I can write for now, official news regarding Rig status will follow when they are available.

Is this reproducible? I saw this only once some while ago and was not able to track it down. If it shows up regularly, please let me know and it will give me a great chance to resolve the issue.


Thanks,
zefir

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.

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

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.

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.

Ok, will do. Thanks for the hint.

That's my fault, since I did not figure out how to disable a driver for a specific OS. As Con already stated, this one is meant for an embedded system with SPI interface (e.g. RasPi) and does not make sense to be build for a desktop OS.

I'll dig deeper into the automake magic to find a clean way to add OS dependency for that driver (if possible at all).

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.

Received mine today (Switzerland).

All I want to say is this: I bought them for speculation only since I know shit about art. But when my wife (who hates bitcoin, since she lost me to it) unpacked the paintings, she immediately fell in love with and grabbed them for herself - looking for the best place to put them while I type

Therefore, looking forward for the next series.


Great work, Zorane.

Absolutely not, I have several mother tongues, but English is none of them. Besides mine being based on German school English (which has a reputation of being clumsy anyway), I am well aware of my limitations when it comes to lingual nuances - hell I'm only engineer and narrow minded by design

My argument was that 'Who cares?' is different from 'Who cares about the details, they won't change anything, do they?'. Maybe it is just me, but the second variant for me reverses the relation, i.e. the first one translates to 'f*ck off' towards the customer, the second to 'f*ck off, I don't care why you're late' from the customer. If that's not the case, I'll admit my failure and say sorry.


Now I hear customers yelling: time to discuss English language but no time for updates

I can give you some definitive ones from the SW side:

• CoinCraft Desk
  
  • done: the driver got integrated in upstream cgminer just today (check git repository)
  • done: all remaining FW parts (UI, sensors, actors) passed long term testing over night
  • done: with that, FW is ready for deployment
• CoinCraft Rig
  
  • done: IAP bootloader to reflash STM32 over SPI in the field
  • done: initial hashing proxy tunneling SPI comms between host and 2 chip chains
  • done: Initial cgminer driver
  • WIP: sensor and actors (temperature, voltage regulator, etc.)
  • WIP: self-optimization, long-term stability

Essentially, the FW for the Desk was done before time (devices are assembled / tested while I type), while the SW for the Rig will be ready just in time.

16 was just a number I pulled from thin air

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


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

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

Listen georgem, this is the second time you are turning the meaning of my words into a negative direction. I told and repeat herein: I understand your anger and it is of course justified. But I also see that no matter what I posted so far you picked something from isolated context and turned to sound negative or disrespectful - which by far is exactly the opposite of what it is intended. I would like to remain motivated to communicate here, but if whatever I say worsens the atmosphere, I better stop.

If I write 'who cares' I mean: 'it makes zero difference' - and that is pretty obvious from the context. In essence, if you come late to an appointment, the guy who you kept waiting does not care why you are late - he will note that you were late. Starting to explain why you are won't change anything for the good - you might end up like someone looking for excuses. Same goes here: what difference does it make whether it was the PCB manufacturer or the parcel service? You have a contract with Bitmine and they take the blame. The CPP / refund agreement given in the ToS is exactly meant to quantify the blame.

That is where my 'who cares' came from - I am not hostile or disrespectful to you in any way. Instead please try for a moment to assume that sometimes people act in good faith and with good intentions.

Folks, please understand: until ~10 days ago I most of all have been a customer like all of you. I have 5k chips ordered for my Zeta.Mining company that were supposed to mine from early January but instead are still sitting in some safe and loosing value by the day - I know exactly how you feel. I already ran into refund window and could ask for refund+10% at any time, but I still think that chips will be profitable if I get them converted to rig soon. That's why I am disappointed to have missed a great opportunity - but I know the worst case outcome will be a +10% ROI.

Also please note: becoming board member did not change anything for me. I am 200km away from Bitmine offices and consequently an SSH tunnel to their network to develop the SW is the only additional link I have. I am not sitting in their offices and aggregating news to update the thread here - nor am I approved to do so. What you can hold me responsible for is the SW, and if you are some DIY developer you already know what you can expect from me.


So in short: you can not expect me to fix what went wrong in the past, whereas you can expect me to work on improvements. I can not promise to succeed, but I promise to do everything I can to reduce the disappointment on your side. I already have some hope-founded reasons to assume that the fear and hate in this thread will not last much longer.


That's for the small talk. Now for the facts.

If I am not mistaking, no products were shipped last week. The plan was like this:

• German PCB manufacturer sends PCB lot on Wednesday to Italian assembler
• Italian assembler receives them Thursday and assembles 500 boards till Friday morning
• Bitmine drives to Italy over night, picks boards up and start product assembly
• first products ship Friday

Tight, but doable. This is what happened:

• German PCB manufacturer (who was reliable to the minute before) messed it up and did not ship the PCBs on time
• Italian assembler cancelled assembly slot

And since we are in Europe and nobody is working after Friday afternoon, a small issue added an effective delay of 3 days.


Now those are the details many are calling for in this thread. But seriously: how does this help waiting customers in any way? All that is important is the fact that shipping did not start as expected. Who cares about the details, they won't change anything, do they?


If they do, I am willing to commit to provide such information on a regular basis. But again I tend to hope the hard times will end soon.