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

[-ck]

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

These 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;

[1713888593]

1713888593

[1713888593]

1713888593

[cscape]

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.

[gingernuts]

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? 

[cscape]

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.

[KNK]

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

These 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;

Thanks!
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

[gingernuts]

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?

[-ck]

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

These 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;

Thanks!
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

Not quite

pn - 0x00400000
vs
pn + 0x00400000

But it's irrelevant since it doesn't work anyway.

[cscape]

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

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.

[gingernuts]

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! 

[KNK]

Not quite

pn - 0x00400000
vs
pn + 0x00400000

But it's irrelevant since it doesn't work anyway.

Ugh, right sorry - looked only at the numbers not the operation

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.

Can you explain a bit more or maybe an example. Thanks

[cscape]

I did a test on the S-HASH board. For one chip,  I marked all cores that returned a valid nonce.


The same test on another chip shows three missing rows:


The test has not run for very long, so some of the unmarked cores may still get a hit later.

Of 16 chips total, 10 have found nonces in all cores. The other 6 all have one or more missing rows at the top.

[cscape]

Can you explain a bit more or maybe an example. Thanks

Check the chainminer sources, fix_nonce() function.

Also, the different fixups aren't distributed equally. The -0x00800000 fixup is needed half the time, no fixup a third, and - 0x00400000 in the rest of the cases. So, if you try them in that order, you'll minimize the number of hashes needed in the software. Or use the method that chainminer uses to try to guess the correct fixup from the core (doesn't always work: some cores have two different possible fixups)

[KNK]

I am looking at the code now, but the number of rows and colums in your table is 35*20=700, in the code it seems to use 24*24=576 instead of 765 cores ... shouldn't it be 15*51 instead?

[punin]

AFAIK there's a "käpy" (finnish for pine-cone) in the internal bus that is limiting the chip reaching 5GH.

[cscape]

I am looking at the code now, but the number of rows and colums in your table is 35*20=700, in the code it seems to use 24*24=576 instead of 765 cores ... shouldn't it be 15*51 instead?

In my table, there are 36 rows and 21 columns (0 also counts), and 36*21=756. The code does % 24, so you'd expect 24 columns, but colums 5-7 are skipped, so only 21 left.

[KNK]

Stupid me ... i counted 765 cores, while they are 756. I guess it was too late for me to thing yesterday

[KNK]

AFAIK there's a "käpy" (finnish for pine-cone) in the internal bus that is limiting the chip reaching 5GH.

So that's why for over 2.3Gh/s the number of error increases no matter what you do.
To reach 3Gh/s after errors i had to make it work on 3.4-3.5 and the number of error increases  because of collisions on the internal bus ... or i got it wrong again 

[mjgraham]

AFAIK there's a "käpy" (finnish for pine-cone) in the internal bus that is limiting the chip reaching 5GH.

Quite interesting, although I have never heard of such a thing , I had been wondering why I had not seen anyone get the max rate. Is this what I am thinking just a wad of circuits coming together ? I would guess with so many cores there would be a lot of busses.

I did a test on the S-HASH board. For one chip,  I marked all cores that returned a valid nonce.


The same test on another chip shows three missing rows:


The test has not run for very long, so some of the unmarked cores may still get a hit later.

Of 16 chips total, 10 have found nonces in all cores. The other 6 all have one or more missing rows at the top.

Pretty cool to be able to visualize this, keep up the great work!

[kaerf]

What do you do if you have a busted H-Board and/or extra chips?

I made a mini H-board

pix: http://imgur.com/a/5Ebiw

De-soldered chips!



Standard chipset heat sinks




Running at ~20GH/s

speed:1257 noncerate[GH/s]:53.386 (2.224/chip) hashrate[GH/s]:55.205 good:3729 errors:205 spi-err:2 miso-err:0 jobs:297 cores:97% good:23 bad:1 off:0 (best[GH/s]:54.360) Sun Sep 29 05:45:42 2013
0:   825   33.086   34.637   2311   138   2   0   15   1   0   (2.068/chip)   95%
4:   432   20.301   20.569   1418   67   0   0   8   0   0   (2.538/chip)   100%

Not bad for my first attempt at (re)drawing a PCB =P

A few pages back I remember some folks complaining about hand placing 0402's...have a look at this cheap DIY pick and place: http://vpapanik.blogspot.com/2012/11/low-budget-manual-pick-place.html
even though I made one, I still ended up hand placing some of the 0402s because it was actually faster. but the pick and place helped a lot when you're really frustrated and hands are shaking.

It's running with R01F @ 4320 ohms (0.8492 V). It's using a TPS53353 (20A) regulator instead of the 30A (just a drop in replacement for the default TPS53355).

[Dexter770221]

DIY pick&place machine rocks
Some day I was thinking about buying DIY 3D printer. With replaced heads it can be a CNC driller, pick&place machine, paste placer machine, molding machine and of course 3D printer. Many in one, ideal solution for a hobbyst