Crypto Mining Blog

Thanks to our friends at MinerEU we were able to get remote access to test an early prototype of a A2BOX Scrypt ASIC miner. These miners us the new 28nm Innosilicon A2 Scrypt ASIC chips, 48 of them on 6 modules with each chip running at 1.5M with about 10W power consumption. The total hashrate of the complete miner is 72 MHS and can be further overclocked up to about 80 MHS or even more. Do note that the tests below are ran on an early prototype of the miner, so the final products tat customers will receive will be improved and should handle even better. In fact after finishing the tests and reporting our findings there were apparently already some improvements on the software part that should improve the results people that get the final product will be getting. We are going to be doing some more tests probably later this week of the final production units to check the progress, so stay tuned for more interesting information. For the moment we are only able to provide some first impressions and performance results from our remote access testing. We are going to try to also do a hands on review later on when we are able to get our hands on the actual hardware.

The miner itself is contained in a 4U case and aside from the 6 modules with the ASIC chips it also has a power supply inside the case as well as a Raspberry Pi controller with the software to control the miner. The software itself is a modified version of cgminer 3.9.0 with support for the Innosilicon A2 Scrypt ASIC chips and by default it is only a console only version of the miner, though the unit we tested also had Scripta installed to make it easier to monitor and control the miner. In overall things were running pretty smooth and easy with the cgminer in the back and Scripta as a frontend, though we’ve noticed some things that could be improved and hopefully they will be in the final miners that will be shipped to people that have ordered them. The 72-80 MHS A2BOX miners are pretty big and expensive at $12000 USD each, so they are not going to be accessible to all, however we may also get smaller units with 1 or 2 modules available as well that should be slower in terms of hashrate, but also more affordable and easier to get by miners that have a smaller budget for hardware.

The default operating frequency as per the A2 chips specifications is 1 GHz with a 1.5 MHS hashrate per chip running at that frequency, though the chips should be capable of 1.1 GHz with 1.65 MHS and 1.2 GHz with 1.8 MHS per chip. Increasing the operating frequency will bring up the power consumption and the heat generated, so proper cooling gets more important in order to actually get higher performance. The modified cgminer 3.9.0 with support for A2 on the Raspberry Pi actually allowed us to set a frequency of 1000, 1080, 1100, 1200, 1280, 1300 and 1400, if set to over 1400 MHz or under 1000 MHz defaults to 1000 MHz. Another good thing is that you can set individual frequency for each module, so you can find out if any of them can work fine at a higher frequency an other at low for optimum performance. It would be good however if a finer grain frequencies could be set by the user as currently the steps you can set in terms of operating frequency are pretty high.

Here is how things looked at 1200 MHz operating frequency of the miner, pretty much the highest one that is worth running the miner at. Scripta is reporting 87 MHS local hashrate and at the pool (scryptguild) we are getting about 80 MHS average, so pretty much what is promised as achievable in terms of overclocking. Do note however that two of the modules are running at lower hashrate as compared to the others and we have found the reason for that is some cores on the chips withing the two modules were not fully functional. Do remember however that here we are testing an earlier prototype of the miner, so it is expected that some things might not be working perfectly, though the good thing is that cgminer reports that and if you have similar problem you will be able to easily notice it when running the miner. We suspect that the reason for getting significantly higher number of HW errors on these two particular modules is also a result from that fact. But even in that situation we are still getting pretty good results when overclocked to 1200 MHz, even with higher than recommended number of HW errors. We got a notice that further optimizations have been made to reduce the HW errors, so the final products should be handling better.

Example output for module 3, 410 active cores out of 432:

[2014-05-08 13:50:02] spidev0.0(cs3): Found 8 A1 chips
[2014-05-08 13:50:02] Found chip 1 with 52 active cores
[2014-05-08 13:50:02] Found chip 2 with 51 active cores
[2014-05-08 13:50:02] Found chip 3 with 53 active cores
[2014-05-08 13:50:02] Found chip 4 with 42 active cores
[2014-05-08 13:50:02] Found chip 5 with 52 active cores
[2014-05-08 13:50:02] Found chip 6 with 53 active cores
[2014-05-08 13:50:02] Found chip 7 with 54 active cores
[2014-05-08 13:50:02] Found chip 8 with 53 active cores
[2014-05-08 13:50:02] Found 8 chips with total 410 active cores

Going higher in terms of overclocking brings up the local hashrate, however it also reduces the poolside one due to lower efficiency of the chips as more HW errors are being generated. So for example at 1280 MHz we were getting about 92 MHS local hashrate, but just 72 MHS poolside, clearly showing that there is no point to go higher than 1200 MHz, even when cgminer allows us to set the frequency up to 1400 MHz. Going a step lower to 1100 MHz we’ve got about 81 MHS local hashrate and about 77 MHS poolside, so at that frequency we are getting a lower difference between the local and the poolside hashrate than at 1200 MHz. Going one more step down to the default frequency of 1000 MHz (the minimum allowable by cgminer) we’ve managed to get about 72 MHS local hashrate and about 65 MHS poolside, so it seems that 1100 MHz seemed the optimal one where you are not pushing the chips too much. We have noticed that even at the lower operating frequencies the number of HW errors of the two modules that had some of their cores not properly working were still at more than 10% which is a value that is a bit too much for an ASIC device. So it seemed that the problematic cores were indeed the cause of us getting more HW errors and not pushing the chips to a higher frequency and with all of the chips properly working the local and poolside hashrate should increase a bit more than the one we’ve managed to get out of the early prototype that we were testing here.

In short, the new A2BOX miners based on Innosillicon A2 Srypt ASIC chips do seem to work quite good and stable, though there are still some thing that needed work and improvement. Hopefully they will be addressed in time for the final production miners to start shipping to people and we already got information as mentioned that things have been improved already and we are soon going to be able to remotely test not an early prototype, but a final product to confirm this by ourselves, so stay tuned for more information.