With all this progress, why is Metabank saying they wont have a device until October at the earliest?
Original e-mail:
Здравствуйте,
В понедельник 29 июля мы должны получить чипы в Москве, после чего запускаем срочное производство.
Сейчас вам нужно принять решение, согласны ли вы использовать ваши биткоины для расчетов с поставщиками. После этого возврат будет уже невозможен.
По предварительной информации суммарная мощность сети осенью может достичь свыше 1 петахэша.
На данный момент мы имеем 4 варианта платы и списки комплектующих, некоторые из которых доступны только под заказ в необходимых нам количествах.
План производства ~ 2 недели с момента поставки комплектующих.
Если вы готовы забрать чипы, это можно сделать начиная со вторника.
Если вы не согласны с этим условиями, вы можете сделать возврат прямо сейчас без задержек.
Поставка не срочным методом возможна не ранее октября.
Просьба дать ответ в течение 4-х дней.
Translation:
Hello
On Monday, July 29, we have to get the chips in Moscow, and then run the urgent production.
Now you need to decide if you agree to use your Bitcoins for payment to suppliers. After that refund will be no longer possible.
According to preliminary information, the total power of the network in the autumn could reach over 1 petahash.
At the moment we have 4 different boards and lists of components, some of which are only available to order in the quantities we need.
The production plan ~ 2 weeks from the date of delivery of components.
If you are ready to pick up the chips, you can do starting Tuesday.
If you do not agree with these terms, you can now make a return without delay.
Delivery is not urgent method is possible not earlier than October.
Please give a reply within 4 days.
Topic: [ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE! - page 34. (Read 176729 times)
July 27, 2013, 09:01:11 PM
July 27, 2013, 08:39:55 PM
You are correct. The timing and pricing of the USB bitfury miner was not a compelling offer... so they took it off the market. They are now licensing the design instead.
https://bitcointalksearch.org/topic/m.2773593
https://bitcointalksearch.org/topic/m.2773593
July 27, 2013, 08:19:24 PM
For the price of a BitFury USB you can now get 1.90GH/s from ASICMiner Erupters, and they're shipping immediately.
How does this plan to stay competitive?
How does this plan to stay competitive?
Wrong thread... but can you link to whichever product you're talking about? I think you've found some spinoff product not directly related to Bitfury, but using Bitfury chips.
For example: starter kit gets 25GH/s for $1300 or $52/GH/s. The USB Erupters get 336 MH/s for around $50 or $148/GH/s.
July 27, 2013, 07:55:11 PM
For the price of a BitFury USB you can now get 1.90GH/s from ASICMiner Erupters, and they're shipping immediately.
How does this plan to stay competitive?
How does this plan to stay competitive?
Wrong thread... but can you link to whichever product you're talking about? I think you've found some spinoff product not directly related to Bitfury, but using Bitfury chips.
For example: starter kit gets 25GH/s for $1300 or $52/GH/s. The USB Erupters get 336 MH/s for around $50 or $148/GH/s.
July 27, 2013, 07:33:46 PM
For the price of a BitFury USB you can now get 1.90GH/s from ASICMiner Erupters, and they're shipping immediately.
How does this plan to stay competitive?
How does this plan to stay competitive?
July 27, 2013, 06:55:38 PM
The only limitation is the 4KB memory set aside for the coinbase data, which may be too small in some cases.
can you explain further what you mean by this?
July 27, 2013, 06:08:45 PM
Let me explain protocol.
...
SPI RESET sequence - rise MOSI and toggle SCK - that is treated as reset command and by default turns on chain of chips (i.e. all inputs are put to outputs OUT - chip is chaining)
Then - instructions for chaining accepted on bit-level
0 - is NOP - no instruction and ignored
100 - is 'break' chain - it is first broadcasted through whole chain and then - on final clock cycle chain is broken.
101 - establish asynchronous chain to next chip - all of SPI fill be forwarded to next chip in chain
110 - establish synchronous chain to next chip - the same as asynchronous but with additional registers for data - bits will be delayed by 2 in output! so give nop padding to frame of long chains
111 - DATA instruction
data instruction contains 1 byte that that has length in 32-bit words
and 16-bit address
...
SPI RESET sequence - rise MOSI and toggle SCK - that is treated as reset command and by default turns on chain of chips (i.e. all inputs are put to outputs OUT - chip is chaining)
Then - instructions for chaining accepted on bit-level
0 - is NOP - no instruction and ignored
100 - is 'break' chain - it is first broadcasted through whole chain and then - on final clock cycle chain is broken.
101 - establish asynchronous chain to next chip - all of SPI fill be forwarded to next chip in chain
110 - establish synchronous chain to next chip - the same as asynchronous but with additional registers for data - bits will be delayed by 2 in output! so give nop padding to frame of long chains
111 - DATA instruction
data instruction contains 1 byte that that has length in 32-bit words
and 16-bit address
I have a few questions -
1. Did the MOSI=1, SCK=1, SCK=0, MOSI=0 sequence change?
By looking at bitfury's source code it seems to be happening in a different order:
(presumes GPIO_10/MOSI is 0), (presumes GPIO_11/SCK is 0), SCK=1, (repeat 16 times MOSI=1, MOSI=0), SCK=0
or instead of :
"SPI RESET sequence - rise MOSI and toggle SCK"
do:
"SPI RESET sequence - rise SCK and toggle MOSI"
Code:
// Bit-banging reset, to reset more chips in chain - toggle for longer period... Each 3 reset cycles reset first chip in chain
void spi_reset(void)
{
int i;
INP_GPIO(10); OUT_GPIO(10);
INP_GPIO(11); OUT_GPIO(11);
GPIO_SET = 1 << 11; // Set SCK
for (i = 0; i < 16; i++) { // On standard settings this unoptimized code produces 1 Mhz freq.
GPIO_SET = 1 << 10;
...
GPIO_SET = 1 << 10;
GPIO_CLR = 1 << 10;
...
GPIO_CLR = 1 << 10;
}
GPIO_CLR = 1 << 10;
GPIO_CLR = 1 << 11;
2. SPI configuration - Does the chip read the MOSI data on SCK rising or falling edge? Judging from the code above it seems that while SCK is high MOSI shouldn't change, so it is likely on the rising edge - is that correct?
Also, does the chip output date on the MISO on SCK falling edge?
Code:
SCK : __________/----\_____________/------\____...
^ scan MOSI ^ scan MOSI
| | | |
| | | |
MOSI:======= ===========
| |
V data out on MISO V data out on MISO
MISO: ================x=============x x=====
3. SPI speed - is there a minimum speed? Can I clock the chip (SCK) at 10-50kHz? Or even lower?
Also - what is the maximum speed? (or what is the fastest observed one - that anyone has successfully tested with?)
4. Does the piece of code below work because the 0x04 value (100 command) is preceded by a bunch of zeros? (e.g. chip is reading 000 and treating it as NOP)?
Code:
void spi_emit_break(void) { spi_emit_buf("\x4", 1); }
void spi_emit_fsync(void) { spi_emit_buf("\x6", 1); }
EDIT: in the timing diagram above bit_0 should actually be bit_7 - from looking at the code it seems it is MSB first LSB last. Is that correct too?
July 27, 2013, 06:50:11 AM
p2pool works with stratum. All my miners are connecting via stratum to my p2p node (cgminer & bfgminer)
July 27, 2013, 03:34:17 AM
I don't know how p2pool works, but the firmware only supports stratum right now.
Does p2pool require a ton of memory ? Because that's probably going to be the limiting factor on the small CPU.
Edit: Note that every network connection also requires buffers, so maintaining connections with multiple peer doesn't sound like it would fit. However, you may still run the main p2pool software on a PC, and just offload the hashing to the board using getwork protocol.
Does p2pool require a ton of memory ? Because that's probably going to be the limiting factor on the small CPU.
Edit: Note that every network connection also requires buffers, so maintaining connections with multiple peer doesn't sound like it would fit. However, you may still run the main p2pool software on a PC, and just offload the hashing to the board using getwork protocol.
July 27, 2013, 03:21:46 AM
The problem with a completed embedded solution is that the pool management portion sucks (based on reading about asicminer blades). They dont support stratum, and lack rich pool management features that cgminer offers, like switching pools using API, having more than 2 failovers, and so on..
The firmware already supports stratum and 4 different pools with automatic switching if a pool is non-responsive. The only limitation is the 4KB memory set aside for the coinbase data, which may be too small in some cases.
cscape, so p2pool does not work, does it?
can you try it?
spiccioli
July 26, 2013, 08:41:36 PM
100Th/s about 250 400Gh/s miner full kit that alot of work.
July 26, 2013, 07:27:30 PM
Tytus brings up the first 100Gh/s for 100TH project: https://bitcointalksearch.org/topic/m.2811496
Awesome!So,where is the other 99.9TH?
ETA,please.
July 26, 2013, 06:35:29 PM
Tytus brings up the first 100Gh/s for 100TH project: https://bitcointalksearch.org/topic/m.2811496
July 26, 2013, 10:51:51 AM
It is any option to get board drawings, CAM, PDF, information of components used?
I am looking to take advantage of one manufacturer near by me.
I am looking to take advantage of one manufacturer near by me.
Email [email protected] for this
July 26, 2013, 07:36:00 AM
This board, with 16 chips, is targeted towards the small home miner with a limited budget. Put it in a nice case with power supply, and you have a neat little standalone unit.
Here I have to agree that this solution is better for small miners. 
July 26, 2013, 07:13:36 AM
The problem with a completed embedded solution is that the pool management portion sucks (based on reading about asicminer blades). They dont support stratum, and lack rich pool management features that cgminer offers, like switching pools using API, having more than 2 failovers, and so on..
The firmware already supports stratum and 4 different pools with automatic switching if a pool is non-responsive. The only limitation is the 4KB memory set aside for the coinbase data, which may be too small in some cases.
Awesome. I guess im stating the obvious, but have http api as well to configure pools, restart, monitor, etc. I wouldnt mind paying slightly higher for one controler per 16-chip board since its a lot more scalable/durable and each unit individually has value.
July 26, 2013, 07:07:36 AM
The problem with a completed embedded solution is that the pool management portion sucks (based on reading about asicminer blades). They dont support stratum, and lack rich pool management features that cgminer offers, like switching pools using API, having more than 2 failovers, and so on..
The firmware already supports stratum and 4 different pools with automatic switching if a pool is non-responsive. The only limitation is the 4KB memory set aside for the coinbase data, which may be too small in some cases.
July 26, 2013, 07:05:02 AM
If properly designed you need only one type of board. One populated fully, other 8 just with regulator. And this also opens perspective to make other communication solutions like USB to SPI bridge and control via PC (or RPi).
Yes, you could make the same board, and populate one partly. It still means you have to interconnect them some way. Suppose someone makes a case for it, that case will also need an extra opening for the interconnect, and then you'll have unprotected 3.3V CMOS level signals going from one board to another, with potential ESD and EMI problems. The board already has an option for RS-485 interconnect (it's on the unpopulated 3 pin connector along the side). That would be more suitable for board-to-board communication. Of course, that would still require the CPU, but that's only $5 @ qty 1000. I'm not too convinced the RS-485 is so great either. This board, with 16 chips, is targeted towards the small home miner with a limited budget. Put it in a nice case with power supply, and you have a neat little standalone unit.
July 26, 2013, 06:57:38 AM
The LPC + Ethernet is more like $15. That's less than a single ASIC. For a complete system with fan, heatsink, maybe a case, 12V power supply, the difference in cost is hardly worth the effort of having two types of PCBs and a new interconnect.
For lots of chips, the M/H board system is a better solution. Of course, an interesting option would be to replace the Raspberry Pi with an integrated CPU/Ethernet on the M-BOARD.
For lots of chips, the M/H board system is a better solution. Of course, an interesting option would be to replace the Raspberry Pi with an integrated CPU/Ethernet on the M-BOARD.
The problem with a completed embedded solution is that the pool management portion sucks (based on reading about asicminer blades). They dont support stratum, and lack rich pool management features that cgminer offers, like switching pools using API, having more than 2 failovers, and so on..
In an ideal world cgminer would act as proxy ( https://bitcointalksearch.org/topic/bounty-5btc-cgminer-add-getwork-proxy-functionality-251224 ) . Run 2 instances of each on real computers (or pi) and use these 2 proxies as pools in the embedded device.
July 26, 2013, 06:54:47 AM
It is any option to get board drawings, CAM, PDF, information of components used?
I am looking to take advantage of one manufacturer near by me.
I am looking to take advantage of one manufacturer near by me.
Jump to: