cscape
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 05:49:23 AM Last edit: July 30, 2013, 06:21:10 AM by cscape |
|
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.
|
Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
|
|
|
daemondazz
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 06: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.
|
Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
|
|
|
|
cscape
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 06:30:46 AM |
|
That just resets the SPI chain. I use that every time before I poll the chips to see if they are ready. 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.
|
Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
|
|
|
kano
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 07: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?
|
|
|
|
intron
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 427
Merit: 251
- electronics design|embedded software|verilog -
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 07:15:18 AM |
|
Is there a doc (or list) of the data commands or the only place is the source?
"Use the Source, Luke" :-)
|
|
|
|
cscape
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 07: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.
|
Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
|
|
|
ultrix
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 07: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.
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.
|
|
|
|
-ck
Legendary
Offline
Activity: 4200
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 07: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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
cscape
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 07: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.
|
Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
|
|
|
ultrix
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 08: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
|
|
|
|
kramble
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 08: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.
|
|
|
|
BenTuras
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 09: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 ?
|
|
|
|
cscape
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 09: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.
|
Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
|
|
|
cscape
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 09: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.
|
Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
|
|
|
ultrix
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 10: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. 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.
|
|
|
|
kramble
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 30, 2013, 10: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.
|
|
|
|
intron
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 427
Merit: 251
- electronics design|embedded software|verilog -
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2013, 11:19:32 AM |
|
Working on bi•fury now, a dual bitfury USB device. ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2F75M5PGU.gif&t=665&c=g2pW23GVljwtAA) 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
|
|
|
|
Foofighter
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2013, 11:25:25 AM |
|
looks nice intron! keep up the good work
|
ex official Canaan Distributor (Cryptouniverse)
|
|
|
itod
Legendary
Offline
Activity: 1974
Merit: 1077
^ Will code for Bitcoins
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 03, 2013, 12:15:21 PM |
|
Very early stage though, no idea yet if we will get it hashing:)
If you succeed, it should hash somewhere around 10Ghs, right?
|
|
|
|
|