The bi•fury heatsinks got a nice color now and you
might bump into some at The European Bitcoin
Convention in Amsterdam:)
intron
That belongs in Amsterdam - in a window with it's own red light over it, it's porn!
Topic: [ANN] Bitfury is looking for alpha-testers of first chips! FREE MONEY HERE! - page 12. (Read 176728 times)
September 26, 2013, 02:22:25 PM
The bi•fury heatsinks got a nice color now and you
might bump into some at The European Bitcoin
Convention in Amsterdam:)
intron
That belongs in Amsterdam - in a window with it's own red light over it, it's porn!
September 26, 2013, 02:18:56 PM
The last one is the same as the second, so its expected that it won't be reached. It seems the chip can get bits 23 and/or 24 wrong ... and engineering chips probably 26 too
I wonder is it an error from the core to the shift register or only when read from the register i.e. SPI communication problem
I wonder is it an error from the core to the shift register or only when read from the register i.e. SPI communication problem
There's a clear pattern when you map the X/Y coordinates from the core to the variant, so it's not a communication problem, but a systematic issue.
September 26, 2013, 02:17:30 PM
The sample software runs through and tests a number of nonce offsets for each return values (6). In my testing of the BF1 USB stick, only 3 of those offsets ever succeed to return values. So either the nonce offsets/nonce calculation used in the sample software are wrong, or half the cores don't work.
Would you please tell me which ones are those 3 ... i am just about to add some debugging code in that part and would like to put them first in the listThese work:
Code:
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn) ? pn : 0;
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn-0x00400000) ? pn - 0x00400000 : 0;
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn-0x00800000) ? pn - 0x00800000 : 0;
These never return anything:
Code:
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn+0x02800000) ? pn + 0x02800000 : 0;
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn+0x02C00000) ? pn + 0x02C00000 : 0;
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn+0x00400000) ? pn + 0x00400000 : 0;
The last one is the same as the second, so its expected that it won't be reached. It seems the chip can get bits 23 and/or 24 wrong ... and engineering chips probably 26 too
I wonder is it an error from the core to the shift register or only when read from the register i.e. SPI communication problem
pn - 0x00400000
vs
pn + 0x00400000
But it's irrelevant since it doesn't work anyway.
September 26, 2013, 02:16:04 PM
Does that mean that there are some valid nonces (~25%) that the chips just can't find, or can the S/W shift the starting nonce values to scan that space too? 
First. Every core has 10 nonce bits hard coded, so 25% of the nonces won't be found.
Thanks - that makes sense! I wonder if the rest wouldn't fit within the die-size budget, or they're there, but just don't work?
September 26, 2013, 02:13:52 PM
The sample software runs through and tests a number of nonce offsets for each return values (6). In my testing of the BF1 USB stick, only 3 of those offsets ever succeed to return values. So either the nonce offsets/nonce calculation used in the sample software are wrong, or half the cores don't work.
Would you please tell me which ones are those 3 ... i am just about to add some debugging code in that part and would like to put them first in the listThese work:
Code:
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn) ? pn : 0;
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn-0x00400000) ? pn - 0x00400000 : 0;
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn-0x00800000) ? pn - 0x00800000 : 0;
These never return anything:
Code:
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn+0x02800000) ? pn + 0x02800000 : 0;
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn+0x02C00000) ? pn + 0x02C00000 : 0;
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn+0x00400000) ? pn + 0x00400000 : 0;
The last one is the same as the second, so its expected that it won't be reached. It seems the chip can get bits 23 and/or 24 wrong ... and engineering chips probably 26 too
I wonder is it an error from the core to the shift register or only when read from the register i.e. SPI communication problem
September 26, 2013, 02:10:11 PM
Does that mean that there are some valid nonces (~25%) that the chips just can't find, or can the S/W shift the starting nonce values to scan that space too?
First. Every core has 10 nonce bits hard coded, so 25% of the nonces won't be found.
September 26, 2013, 02:08:17 PM
Note that only 756/1024 of the total nonce space is checked, the remaining part is just not implemented on the chip. Also, some chips perform worse than others. They could have some manufacturing defect, affecting part of the cores. Raising the frequency too far also increases the error rate. Unstable power regulator could have the same effect... and then there's always communication and software errors.
Does that mean that there are some valid nonces (~25%) that the chips just can't find, or can the S/W shift the starting nonce values to scan that space too?
September 26, 2013, 01:38:54 PM
Code:
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn+0x02800000) ? pn + 0x02800000 : 0;
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn+0x02C00000) ? pn + 0x02C00000 : 0;
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn+0x00400000) ? pn + 0x00400000 : 0;
Ah, yes, I misunderstood what you were talking about. I've never seen those used either. Probably some superfluous code in the first iteration. In my code, I only check the other 3. Chainminer doesn't check them either.
September 26, 2013, 01:31:53 PM
The sample software runs through and tests a number of nonce offsets for each return values (6). In my testing of the BF1 USB stick, only 3 of those offsets ever succeed to return values. So either the nonce offsets/nonce calculation used in the sample software are wrong, or half the cores don't work.
Would you please tell me which ones are those 3 ... i am just about to add some debugging code in that part and would like to put them first in the listThese work:
Code:
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn) ? pn : 0;
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn-0x00400000) ? pn - 0x00400000 : 0;
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn-0x00800000) ? pn - 0x00800000 : 0;
These never return anything:
Code:
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn+0x02800000) ? pn + 0x02800000 : 0;
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn+0x02C00000) ? pn + 0x02C00000 : 0;
s |= rehash(op->midstate, op->m7, op->ntime, op->nbits, pn+0x00400000) ? pn + 0x00400000 : 0;
September 26, 2013, 01:09:07 PM
The sample software runs through and tests a number of nonce offsets for each return values (6). In my testing of the BF1 USB stick, only 3 of those offsets ever succeed to return values. So either the nonce offsets/nonce calculation used in the sample software are wrong, or half the cores don't work.
Would you please tell me which ones are those 3 ... i am just about to add some debugging code in that part and would like to put them first in the list September 26, 2013, 12:57:58 PM
Note that only 756/1024 of the total nonce space is checked, the remaining part is just not implemented on the chip. Also, some chips perform worse than others. They could have some manufacturing defect, affecting part of the cores. Raising the frequency too far also increases the error rate. Unstable power regulator could have the same effect... and then there's always communication and software errors.
September 26, 2013, 12:46:20 PM
The sample software runs through and tests a number of nonce offsets for each return values (6). In my testing of the BF1 USB stick, only 3 of those offsets ever succeed to return values. So either the nonce offsets/nonce calculation used in the sample software are wrong, or half the cores don't work.
September 26, 2013, 10:24:44 AM
But ... is the reason: a portion of the chip doesn't work properly?
i.e. the chip has some design flaw in it that means it only gets ... a bit over half of that 5GHash?
... so that Gen 2 chips would just be the fully working version of the Gen 1 chip?
Anyone got any info on that?
Each chip has 756 hashing cores. I've done some tests, and seen that in most chips, nearly all of them return results. The fact that they don't get 5GH/sec is probably due to max clock being lower than expected.i.e. the chip has some design flaw in it that means it only gets ... a bit over half of that 5GHash?
... so that Gen 2 chips would just be the fully working version of the Gen 1 chip?
Anyone got any info on that?
Quote
Though, I will also add another question: Who's idea on the single USB 'thing' was it, to have it NOT return results, until it completes the nonce range?
Does nobody learn for the mistakes of others or have any experience in doing this stuff?
It's a little bit more work to return nonces as soon as they are found. The chainminer software does it, though. Does nobody learn for the mistakes of others or have any experience in doing this stuff?
September 26, 2013, 10:20:19 AM
But ... is the reason: a portion of the chip doesn't work properly?
All cores work fine, but ...Quote
i.e. the chip has some design flaw in it that means it only gets ... a bit over half of that 5GHash?
correct, the fast clock is not working and it is difficult to get it running stable at higher clocks, but by design it should be able to reach 500MHz which is 5.88GH and it could be 5GH at 450MHzQuote
... so that Gen 2 chips would just be the fully working version of the Gen 1 chip?
bitfury said (if he didn't change his mind yet), that there will be no second mask for the current design i.e. Gen 2 will be a different chip
September 26, 2013, 10:10:27 AM
So ... I've been wondering why the chip has printed on it 5GHash
I had my suspicions ... then I've had two people mention some things about the way they work ...
(I don't have any of these chips ... so I can't verify it)
But ... is the reason: a portion of the chip doesn't work properly?
i.e. the chip has some design flaw in it that means it only gets ... a bit over half of that 5GHash?
... so that Gen 2 chips would just be the fully working version of the Gen 1 chip?
Anyone got any info on that?
If you have a lot of these chips hashing away, then an analysis of the range of the share nonce values would be pretty clear about this.
(though you may have to account for endian-ness also)
Though, I will also add another question: Who's idea on the single USB 'thing' was it, to have it NOT return results, until it completes the nonce range?
Does nobody learn for the mistakes of others or have any experience in doing this stuff?
Sigh.
I've given this info to quite a few hardware designers that I've spoken to in the past - but it seems the BitFury team wasn't interested in this free info so they did it ... wrong
https://bitcointalksearch.org/topic/optimal-firmwarehardware-design-for-mining-with-cgminer-294499
I had my suspicions ... then I've had two people mention some things about the way they work ...
(I don't have any of these chips ... so I can't verify it)
But ... is the reason: a portion of the chip doesn't work properly?
i.e. the chip has some design flaw in it that means it only gets ... a bit over half of that 5GHash?
... so that Gen 2 chips would just be the fully working version of the Gen 1 chip?
Anyone got any info on that?
If you have a lot of these chips hashing away, then an analysis of the range of the share nonce values would be pretty clear about this.
(though you may have to account for endian-ness also)
Though, I will also add another question: Who's idea on the single USB 'thing' was it, to have it NOT return results, until it completes the nonce range?
Does nobody learn for the mistakes of others or have any experience in doing this stuff?
Sigh.
I've given this info to quite a few hardware designers that I've spoken to in the past - but it seems the BitFury team wasn't interested in this free info so they did it ... wrong
https://bitcointalksearch.org/topic/optimal-firmwarehardware-design-for-mining-with-cgminer-294499
September 26, 2013, 04:22:02 AM
The bi•fury heatsinks got a nice color now and you
might bump into some at The European Bitcoin
Convention in Amsterdam:)
intron
September 25, 2013, 05:19:45 PM
Cheers for the quick reply - yeah, I hope those input voltage levels are the wrong way round too 
I guess I should have plenty of margin, doubt I'd try more than 1.0v VDD.
I guess I should have plenty of margin, doubt I'd try more than 1.0v VDD.
September 25, 2013, 04:55:36 PM
Just a quick question - if I connect IOREF to VDD rather than building a voltage divider for 1/2 IOVDD, what happens as I raise VDD from the nominal 0.8v towards 1.0v? Does the I/O get flaky, and if so, does anyone know at what point?
Cheers.
Cheers.
Part of your answer is in this reply from bitfury:
Pad diagram: https://mega.co.nz/#!SctDlaJY!TMVG_E6gOVI-MMky8BS0hTy_h-AqpBeVfgrKF_d0J7g
central pad - ground
35 pads - VDD - on three sides - core voltage - 0.6 .. 0.9 V with high amperage.
I/O (required for testing):
IOVDD - feed it with 1.8 V
IOREF - feed it with 0.9 V for standard signalling (better not take VDD but put resistive divider between GND and IOVDD) and some cap to remove pulsations.
INCLK - input clock (in case if internal oscillator not works)
central pad - ground
35 pads - VDD - on three sides - core voltage - 0.6 .. 0.9 V with high amperage.
I/O (required for testing):
IOVDD - feed it with 1.8 V
IOREF - feed it with 0.9 V for standard signalling (better not take VDD but put resistive divider between GND and IOVDD) and some cap to remove pulsations.
INCLK - input clock (in case if internal oscillator not works)
and part is in that pad diagram file referred there - where it says about IOREF:
Quote
LOGIC 0 INPUT INPUT > IOREF + 50 mV (+- 50%)
LOGIC 1 INPUT INPUT < IOREF + 50 mV (+- 50%)
LOGIC 0 OUTPUT GND
LOGIC 1 OUTPUT IOVDD
(and I think the 0 and 1 levels are vice versa - INLOGIC 1 INPUT INPUT < IOREF + 50 mV (+- 50%)
LOGIC 0 OUTPUT GND
LOGIC 1 OUTPUT IOVDD
So, when you increase IOVDD that threshold may get off a bit, but most likely everything will still work just fine.
September 25, 2013, 04:43:57 PM
Just a quick question - if I connect IOREF to VDD rather than building a voltage divider for 1/2 IOVDD, what happens as I raise VDD from the nominal 0.8v towards 1.0v? Does the I/O get flaky, and if so, does anyone know at what point?
Cheers.
Cheers.
September 25, 2013, 12:19:21 PM
Great news! Just make working 1-chip miner with or without the chip a priority please, everything else will be easier and you will be out of the awful pre-order loop. People will get hold of the chips one way or the other, there are *no* kits on the market right now, especially open source ones. It will be a hit.
Will do! Hardware hacking is sort of both a hobby and profession for me. In fact, I literally just noticed that two MSP430 FRAM dev kits showed up on my desk this morning ;-)by the way - there are 1-chip projects out there - e.g. mine / NanoFury
(and the plan is to have that as an open source too)
If it will ever become opensource is not an issue, problem is it is not opensource now. If there is no other opensource competition it may never become one. At current difficulty increases and NanoFury prices (0.9BTC minimal with shipping, depending on destination) it already is not profitable and currently shipping miners never will be, see:
http://mining.thegenesisblock.com/a/aa12fe32dd
That's why goodney's work is so important, he may single handily make those USB Bitfury miners profitable if he succeeds and offer kits which will reduce the price inside the ROI margins.
A few clarifications:
- price as we stand now will be less than 0.55BTC + $0-$4/device shipping. (and not 0.9)
- open source: we're already providing access to the files for those that are interested. I even sent a bunch of the sample boards to several people wanting to experiment. PM me if you're interested.
Jump to: