Topic: [ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE! - page 33. (Read 176728 times)
July 30, 2013, 02:43:09 AM
Finishing work fully taking 1.5 seconds is the same lacklustre problem as the Avalon design. That's on average .75 seconds of work wasted per 30 seconds on p2pool which is 2.5% of work lost. That's more than many pools' fees.
July 30, 2013, 02:39:44 AM
How often does the work change ? I don't know if bitfury chips can be interrupted. For normal mining, I just let them finish the old work (takes on average 1.5 seconds), which is acceptable since the work only changes every new block (nominally every 10 minutes)
If there's a way to interrupt bitfury chips, I'd be happy to modify the firmware to support quick work switching.
Edit: I looked it up. Apparently work changes every 10 seconds, which would make the 1.5 second delay too much. So, it all depends on whether the bitfury chips can be interrupt. I don't know that yet.
If there's a way to interrupt bitfury chips, I'd be happy to modify the firmware to support quick work switching.
Edit: I looked it up. Apparently work changes every 10 seconds, which would make the 1.5 second delay too much. So, it all depends on whether the bitfury chips can be interrupt. I don't know that yet.
Haven't had time to get a board up yet, but if it behaves like bitfury's fpga, just try sending it the new work prior to completion. So to test, find a work that does not find a solution and one that returns a nonce very quickly. Send the one that does not find a nonce, then immediately send the one that does. Then measure the return time for the expected nonce.
July 30, 2013, 02:18:33 AM
How often does the work change ? I don't know if bitfury chips can be interrupted. For normal mining, I just let them finish the old work (takes on average 1.5 seconds), which is acceptable since the work only changes every new block (nominally every 10 minutes)
...
Wait what?...
Work should change at least every 30s at worst every 60 seconds.
Are you designing hardware that is inherently BAD for bitcoin?
I meant a prevhash change of course. Like I said, the firmware uses stratum, so it generates new work all the time.
July 30, 2013, 02:15:18 AM
Is there a doc (or list) of the data commands or the only place is the source?
"Use the Source, Luke" :-)
July 30, 2013, 02:09:59 AM
How often does the work change ? I don't know if bitfury chips can be interrupted. For normal mining, I just let them finish the old work (takes on average 1.5 seconds), which is acceptable since the work only changes every new block (nominally every 10 minutes)
...
Wait what?...
Work should change at least every 30s at worst every 60 seconds.
Are you designing hardware that is inherently BAD for bitcoin?
July 30, 2013, 01:30:46 AM
Not sure if it resets just the SPI or the entire chip, but you may try using "SPI RESET sequence - rise MOSI and toggle SCK" https://bitcointalksearch.org/topic/m.2411738
That just resets the SPI chain. I use that every time before I poll the chips to see if they are ready. Quote
Is there a doc (or list) of the data commands or the only place is the source?
All I know about is bitfury's postings in this thread and his source code, and neither mentions an 'abort job' feature. July 30, 2013, 01:28:18 AM
Not sure if it resets just the SPI or the entire chip, but you may try using "SPI RESET sequence - rise MOSI and toggle SCK" https://bitcointalksearch.org/topic/m.2411738
Is there a doc (or list) of the data commands or the only place is the source?
Is there a doc (or list) of the data commands or the only place is the source?
July 30, 2013, 01:12:45 AM
Edit: I looked it up. Apparently work changes every 10 seconds, which would make the 1.5 second delay too much. So, it all depends on whether the bitfury chips can be interrupt. I don't that yet.
The share time was recently increased to 30 seconds, primarily to assist with ASICs that can't respond that fast.
July 30, 2013, 12:49:23 AM
How often does the work change ? I don't know if bitfury chips can be interrupted. For normal mining, I just let them finish the old work (takes on average 1.5 seconds), which is acceptable since the work only changes every new block (nominally every 10 minutes)
If there's a way to interrupt bitfury chips, I'd be happy to modify the firmware to support quick work switching.
Edit: I looked it up. Apparently work changes every 10 seconds, which would make the 1.5 second delay too much. So, it all depends on whether the bitfury chips can be interrupt. I don't know that yet.
If there's a way to interrupt bitfury chips, I'd be happy to modify the firmware to support quick work switching.
Edit: I looked it up. Apparently work changes every 10 seconds, which would make the 1.5 second delay too much. So, it all depends on whether the bitfury chips can be interrupt. I don't know that yet.
July 29, 2013, 10:37:11 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.
Your assumptions are correct. P2Pool is not an option for standalone operation on a Cortex M3. It requires maintaining the blockchain (which basically means running bitcoind) and connections to the P2Pool network.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.
Setting up a dedicated bitcoind/P2Pool server with a getwork/Stratum front-end is the only option here.
running a p2pool node is totally out of the question. You have to use a real computer for that.
The reason to ask about p2pool compatibility is something to do with how fast can the device interrupt work. In p2pool the work changes very often. IIRC some ASIC devices(Avalon? ASICMINER blades?) are unable to drop the existing work and start work on the fresh one which makes them very inefficient for p2pool resulting in high DOA...
July 29, 2013, 10:29:55 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.
Your assumptions are correct. P2Pool is not an option for standalone operation on a Cortex M3. It requires maintaining the blockchain (which basically means running bitcoind) and connections to the P2Pool network.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.
Setting up a dedicated bitcoind/P2Pool server with a getwork/Stratum front-end is the only option here.
July 28, 2013, 08:04:53 PM
...
...You can see in the code that the initialization code says mode=0, so it's using SPI mode 0 (data valid on rising edges)
...
cscape - thanks for the clarifications!
btw I did see that it is initializing it in mode 0, and looked at the http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf but didn't find my answer (at least not in the section at page 20 and didn't read much further) .. Anyways - it's clear now, so thanks again!
July 28, 2013, 08:39:28 AM
Thanks intron.
My board is two sided.
The multilayer board will be more expensive so i choosed the more cheep.
Also i think to choose the maximum thickness of the copper layer. Less voltage drop will be and cooling will be better.
My board is two sided.
The multilayer board will be more expensive so i choosed the more cheep.
Also i think to choose the maximum thickness of the copper layer. Less voltage drop will be and cooling will be better.
July 28, 2013, 07:15:31 AM
Thanks for reply.
I made a simple board for one chip. And it is ok.
I want to build something similar.
I think you have the following layer stack:
top - power plane and jumpers (if any chip will be damaged)
layer1 - Ground and SPI connection between chips
layer2 - Ground and IOVDD conection
bottom - Ground plane
Am i correct?
I made a simple board for one chip. And it is ok.
I want to build something similar.
I think you have the following layer stack:
top - power plane and jumpers (if any chip will be damaged)
layer1 - Ground and SPI connection between chips
layer2 - Ground and IOVDD conection
bottom - Ground plane
Am i correct?
A small board with a single bitfury can be a bi-layer indeed.
Wouldn't take changes when making a board with many ASICs
Here you can see the different layers:
Layer top is Vcore (0V6..0V9), rest is GND with vertical
going wires on layer 3 and horizontal going wires
going on layer 2. Except near the upper edge
were current density is low. Layer bottom is also GND.
In the power section layer top is also GND.
intron
July 28, 2013, 06:56:02 AM
Thanks for reply.
I made a simple board for one chip. And it is ok.
I want to build something similar.
I think you have the following layer stack:
top - power plane and jumpers (if any chip will be damaged)
layer1 - Ground and SPI connection between chips
layer2 - Ground and IOVDD conection
bottom - Ground plane
Am i correct?
I made a simple board for one chip. And it is ok.
I want to build something similar.
I think you have the following layer stack:
top - power plane and jumpers (if any chip will be damaged)
layer1 - Ground and SPI connection between chips
layer2 - Ground and IOVDD conection
bottom - Ground plane
Am i correct?
July 28, 2013, 06:22:33 AM
cscape intron was stating that this board is 4 layer. I can't understand why four layers are needed?
Top - power plane
inside1 - SPI connections between chips
inside2 -
?
bottom - ground plane
Could you explain?
Top - power plane
inside1 - SPI connections between chips
inside2 -
?bottom - ground plane
Could you explain?
Four layers were used to yield un-interrupted power and ground planes,
giving nice return paths and minimizes ground bounce. Also when using a
4-layer board, the distance between top and layer 1 and bottom and
layer 2 is rather small, giving extra capacitance to fight power noise.
We are switching massive currents here, so decoupling could be a
problem.
It was an absolute rush job, design was done in a few days.
So there was no time to take changes trying to cut costs
and end up with a flakey board.
intron
July 28, 2013, 05:42:36 AM
cscape intron was stating that this board is 4 layer. I can't understand why four layers are needed?
Top - power plane
inside1 - SPI connections between chips
inside2 -?
bottom - ground plane
Could you explain?
Top - power plane
inside1 - SPI connections between chips
inside2 -
?bottom - ground plane
Could you explain?
July 28, 2013, 04:26:02 AM
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
There is still an ad for them here on BTCtalk, that's how I found them. https://bitcointalksearch.org/topic/m.2773593
July 28, 2013, 12:03:36 AM
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"
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"
The code is correct. Toggling SCK for a reset wouldn't make sense, because that's the same as writing data.
Quote
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?
Also, does the chip output date on the MISO on SCK falling edge?
You can see in the code that the initialization code says mode=0, so it's using SPI mode 0 (data valid on rising edges)
Quote
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?)
AFAIK there's no minimum speed. Not sure what max speed is (I think it's > 10 MHz). I'm running the SPI bus at 500 kHz, which is about the fastest you can get for 16 chips in fasync mode.Also - what is the maximum speed? (or what is the fastest observed one - that anyone has successfully tested with?)
Quote
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); }
Yes.
July 27, 2013, 11:50:44 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?
If you look at the stratum documentation, you see it involves merging together coinbase strings plus the extranonce, and then performing a double SHA256 hash over the result. Now, the coinbase strings can -- in theory -- be very large, and this will overwhelm the limited memory inside the embedded device. Right now, I have a 4KB buffer for the total coinbase data.
In practice, most mining pools have coinbase strings that are just a few hundred bytes.
Also note that really large coinbase data may also not work very well on devices like the Raspberry Pi. Even though they have more memory, the hashing speed is still limited, and performing the SHA256 hash over a megabyte of data to generate a piece of work may slow down the device to the point where it has an effect on total hashing speed.
Jump to: