Got through the design rule check:
intron
intron
Awesome intron.
So when can we expect this to be in market.?
With the demand for AM USB BE's increasing and supply decreasing, i think getting this project done ASAP would be wise.
Topic: [ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE! - page 32. (Read 176729 times)
August 05, 2013, 06:12:45 AM
Awesome intron.
So when can we expect this to be in market.?
With the demand for AM USB BE's increasing and supply decreasing, i think getting this project done ASAP would be wise.
August 05, 2013, 03:44:02 AM
Got through the design rule check:
intron
intron
August 04, 2013, 01:43:48 AM
Working on bi•fury now, a dual bitfury USB device.
It will have two bitfury ASICs, user settable
overclocking options and a temperature sensor
to provide for overtemperature protection.
Very early stage though, no idea yet if we will
get it hashing:)
intron
It will have two bitfury ASICs, user settable
overclocking options and a temperature sensor
to provide for overtemperature protection.
Very early stage though, no idea yet if we will
get it hashing:)
intron
Oh gosh i do hope that works out!!
August 04, 2013, 01:34:14 AM
Punin is fine - I think he's pretty busy with a board design of his own. We were just discussing logistics around August order delivery...he's still with you folks...
Thanks Dave.You might want to give him a hint to take care of his customers too now and then.
He nor we need another escalating communication problem, we've enough of those here.
Cheers.
August 04, 2013, 01:23:39 AM
Punin is fine - I think he's pretty busy with a board design of his own. We were just discussing logistics around August order delivery...he's still with you folks...
August 03, 2013, 03:17:47 PM
@bitfury: When was the last time you had contact with Punin (EURO bitfury sales)?
He has gone very quiet, people are wondering ...
He has gone very quiet, people are wondering ...
August 03, 2013, 02:45:55 PM
Nice, intron! We just sent our 2chip stick prototype to an assembly house. No idea if it will work yet =P. I'll post video/pix if we get it working. If it does work, I don't think we'll mass it though. I dont think it will be cost effective.
Maybe not now with the current price of bitfury asics... But still nice to have in your back pocket. Congrats guys!
August 03, 2013, 02:42:21 PM
Nice, intron! We just sent our 2chip stick prototype to an assembly house. No idea if it will work yet =P. I'll post video/pix if we get it working. If it does work, I don't think we'll mass it though. I dont think it will be cost effective.
August 03, 2013, 07:49:28 AM
Very early stage though, no idea yet if we will
get it hashing:)
get it hashing:)
If you succeed, it should hash somewhere around 10Ghs, right?
Aiming for 4..5 GH/s standard operation, more with adequate
cooling and overclocking.
We did a test with a single bitfury, and with about 2 Amps power
we got nearly 2.5 GH/s. See:
https://bitcointalksearch.org/topic/m.2611999
intron
August 03, 2013, 07:15:21 AM
Very early stage though, no idea yet if we will
get it hashing:)
get it hashing:)
If you succeed, it should hash somewhere around 10Ghs, right?
August 03, 2013, 06:25:25 AM
looks nice intron! keep up the good work
August 03, 2013, 06:19:32 AM
Working on bi•fury now, a dual bitfury USB device.
It will have two bitfury ASICs, user settable
overclocking options and a temperature sensor
to provide for overtemperature protection.
Very early stage though, no idea yet if we will
get it hashing:)
intron
It will have two bitfury ASICs, user settable
overclocking options and a temperature sensor
to provide for overtemperature protection.
Very early stage though, no idea yet if we will
get it hashing:)
intron
July 30, 2013, 05:25:27 AM
Its probably based on ngzhang's original Icarus design which goes to sleep after finding a valid nonce, behavior based on a misunderstanding of the bitcoin hashing algorithm since more than one valid share can be found for any given getwork, though it is relevant for solo mining. I don't know why nobody has fixed this since the FPGA code has been public for quite a while now.
The bitfury design continues searching the nonce space and will report all that it finds. Only when the search is exhausted, it switches to the next job. It has a FIFO with the 15 most recent nonces found. If you don't supply the next job in time, it will restart old work and you end up with dupes.Yeah, sorry, my OP was referring to the Avalon rather than bitfury. I'm sure bitfury has done the job properly.
July 30, 2013, 05:10:16 AM
How deep is this queue and what happens if you add one more unit of work than the queue can hold ?
Does it abort the current job ?
The queue is 2 deep. One job it is currently working on, and one job scheduled for later. Every time you poll the chip to see if the job is finished, you supply the next job at the same time (it's in the same SPI transfer), so typically the next job will be sent a few times. I've never seen any evidence of aborted jobs. I figure it just overwrites the next job. Does it abort the current job ?
what about updating the counters register? ala spi_emit_data(0x0100, (void*)counters, 16); But with bases other than 61 (break step to check for reportable nonce) and 4 (start step for that would possibly reduce the number of iterations needed to complete a loop? Or is this queued as well? It may take some experimenting with values, but changing the values should yield timing differences to determine if its queued or not when the values are changed. Just a thought.
July 30, 2013, 04:10:20 AM
How deep is this queue and what happens if you add one more unit of work than the queue can hold ?
Does it abort the current job ?
The queue is 2 deep. One job it is currently working on, and one job scheduled for later. Every time you poll the chip to see if the job is finished, you supply the next job at the same time (it's in the same SPI transfer), so typically the next job will be sent a few times. I've never seen any evidence of aborted jobs. I figure it just overwrites the next job. Does it abort the current job ?
July 30, 2013, 04:06:15 AM
Its probably based on ngzhang's original Icarus design which goes to sleep after finding a valid nonce, behavior based on a misunderstanding of the bitcoin hashing algorithm since more than one valid share can be found for any given getwork, though it is relevant for solo mining. I don't know why nobody has fixed this since the FPGA code has been public for quite a while now.
The bitfury design continues searching the nonce space and will report all that it finds. Only when the search is exhausted, it switches to the next job. It has a FIFO with the 15 most recent nonces found. If you don't supply the next job in time, it will restart old work and you end up with dupes. July 30, 2013, 04:01:19 AM
I don't know how the FPGA works, but on the ASIC, the chip is working on job #0, while you send data for job #1. As soon as it finishes job #0, it automatically switches to job #1. Sending job #1 does not abort job #0, so if there's a way to abort #0, it must use a different mechanism.
How deep is this queue and what happens if you add one more unit of work than the queue can hold ?Does it abort the current job ?
July 30, 2013, 03:49:30 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.
Its probably based on ngzhang's original Icarus design which goes to sleep after finding a valid nonce, behavior based on a misunderstanding of the bitcoin hashing algorithm since more than one valid share can be found for any given getwork, though it is relevant for solo mining. I don't know why nobody has fixed this since the FPGA code has been public for quite a while now.
July 30, 2013, 03:12:27 AM
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.
I don't know how the FPGA works, but on the ASIC, the chip is working on job #0, while you send data for job #1. As soon as it finishes job #0, it automatically switches to job #1. Sending job #1 does not abort job #0, so if there's a way to abort #0, it must use a different mechanism.
Would be nice to have a set of register addresses and prescribed behavior. Possibly there exists an unintentional reset method, such as reprogramming the clock config, which may force reset for metastability, or the round processing counters, which seem to influence the start step and stop step of the core (see FIRST_BASE and SECOND_BASE and config_reg(0x0100, ...), which could quickly skip the rest of the calculation.
Edit: sorry wrong value for config_reg arg
July 30, 2013, 02:47:44 AM
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.
I don't know how the FPGA works, but on the ASIC, the chip is working on job #0, while you send data for job #1. As soon as it finishes job #0, it automatically switches to job #1. Sending job #1 does not abort job #0, so if there's a way to abort #0, it must use a different mechanism.
Jump to: