-ck
Legendary
Offline
Activity: 4284
Merit: 1645
Ruu \o/
|
|
September 26, 2013, 06: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 list These work: 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: 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;
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
cscape
|
|
September 26, 2013, 06:38:54 PM |
|
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.
|
Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
|
|
|
gingernuts
Member
Offline
Activity: 89
Merit: 10
|
|
September 26, 2013, 07: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?
|
|
|
|
cscape
|
|
September 26, 2013, 07: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.
|
Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
|
|
|
KNK
|
|
September 26, 2013, 07: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 list These work: 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: 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
Member
Offline
Activity: 89
Merit: 10
|
|
September 26, 2013, 07: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?
|
|
|
|
-ck
Legendary
Offline
Activity: 4284
Merit: 1645
Ruu \o/
|
|
September 26, 2013, 07: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 list These work: 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: 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 - 0x00400000vs pn + 0x00400000But it's irrelevant since it doesn't work anyway.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
cscape
|
|
September 26, 2013, 07: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
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.
|
Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
|
|
|
gingernuts
Member
Offline
Activity: 89
Merit: 10
|
|
September 26, 2013, 07: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!
|
|
|
|
KNK
|
|
September 26, 2013, 07:31:07 PM |
|
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
|
|
September 26, 2013, 07:32:21 PM Last edit: September 26, 2013, 09:09:33 PM by 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.
|
Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
|
|
|
cscape
|
|
September 26, 2013, 07:33:35 PM Last edit: September 26, 2013, 07:54:55 PM by 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)
|
Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
|
|
|
KNK
|
|
September 26, 2013, 10:31:41 PM |
|
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
|
|
September 26, 2013, 11:38:00 PM |
|
AFAIK there's a "käpy" (finnish for pine-cone) in the internal bus that is limiting the chip reaching 5GH.
|
|
|
|
cscape
|
|
September 27, 2013, 03:41:19 AM |
|
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.
|
Happy with your c-scape product ? Consider a tip: 16X2FWVRz6UzPWsu4WjKBMJatR7UvyKzcy
|
|
|
KNK
|
|
September 27, 2013, 08:12:50 AM |
|
Stupid me ... i counted 765 cores, while they are 756. I guess it was too late for me to thing yesterday
|
|
|
|
KNK
|
|
September 27, 2013, 11:12:57 AM |
|
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
|
|
September 27, 2013, 12:14:36 PM |
|
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
|
|
September 29, 2013, 06:26:10 AM |
|
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/5EbiwDe-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
Legendary
Offline
Activity: 1029
Merit: 1000
|
|
September 29, 2013, 06:41:15 AM |
|
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
|
Under development Modular UPGRADEABLE Miner (MUM). Looking for investors. Changing one PCB with screwdriver and you have brand new miner in hand... Plug&Play, scalable from one module to thousands.
|
|
|
|