Posts Tagged ‘asic miner


KnCMiner has just announced that they are already in the testing/tweaking/assembly stage of their 20 nanometer Neptune ASIC processors in Sweden and shipping should commence some time later this week. The Neptune processors are quite an interesting technological achievement as they are actually the first commercially available 20 nanometer processor shipped to end users… and we are not talking about ASIC miners only. Intel for example is currently shipping 22nm CPUs, though they are already preparing for a 14nm launch maybe sometime later this year, and AMD’s latest processors take advantage of 28nm fabrication process. So it is interesting to see a Bitcoin ASIC manufacturer pushing advanced technology ahead of other much larger and more established companies are able to do so.

The Neptune is a 1440-core 55×55 mm package tailor-made for the Bitcoin mining (SHA-256 ASIC). Each Neptune miner will consist of 5 ASIC chips and comes in new sturdier enclosure and packaging and should be capable of 3 THS or even more while consuming about 2.1 KW of power at the wall. That results out to just about 0.7 watts of power used per GHS, so really god power efficiency and KnC does promise to possibly further increase the performance of the device with software updates. The first two batches of the Neptune Bitcoin miners are already sold-out and KnCMiner is taking pre-orders for Batch three at the moment. They expect to start shipping Batch 1 to customers this week and to Batch 2 pre-orders before the end of the month.


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.


If you ever wondered how hot does the Bitmain AntMiner S1 Bitcoin ASIC Miner get when operating and mining for BTC now you can get a better idea about the temperatures thanks to some thermal images that we’ve made of one of these BTC ASIC miners. The AntMiner S1 has the cooling radiators on the other side of the PCBs and not on the one where the SHA-256 mining chips are placed, so the operating temperature of the chips is not so low. Running at the default hashrate of about 180 GH/s you can see temperature of about 68 degrees Celsius and it is of the voltage regulators above the chips. As you can see the temperature on the left is lower than that on the right side of the board due to the fact that the cooling fan is on the left side.


Moving on to the exhaust side of the AntMiner S1 cooler where the hot air passing through the cooling radiator passes you can see that on the hotter output end the maximum temperature is about 61 degrees Celsius. A the same time the web interface reports operating temperatures of about 45 degrees Celsius for the two boards with chips that make the Bitmai AntMiner S1. As you can see it is a good idea to think more about the improvement of the cooling of the ASIC miner, especially if you do plane to overclock it to 190 GH/s or even 200 GH/s. The hardware is probably able to handle pretty well higher temperatures than these, but ensuring good cooling will make it perform great for longer period of time and you would want to have that when talking about a BTC ASIC miner.