[ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE!

[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.

[daemondazz]

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.

[KNK]

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://bitcointalk.org/index.php?topic=228677.msg2411738#msg2411738

Is there a doc (or list) of the data commands or the only place is the source?

[cscape]

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://bitcointalk.org/index.php?topic=228677.msg2411738#msg2411738

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.

[kano]

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]

Is there a doc (or list) of the data commands or the only place is the source?

"Use the Source, Luke" :-)

[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)
...

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.

[ultrix]

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]

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.

[cscape]

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.

[ultrix]

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]

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]

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]

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.

[cscape]

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.

[ultrix]

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]

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]

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

[Foofighter]

looks nice intron! keep up the good work

[itod]

Very early stage though, no idea yet if we will
get it hashing:)

If you succeed, it should hash somewhere around 10Ghs, right?