Quote from: BkkCoins on May 30, 2013, 12:49:57 AM

Quote from: kano on May 29, 2013, 11:52:22 PM

Hopefully this information chips per bank, for each bank, is available, so calculating the hash rate can be done properly

(Edit: I will add I can calculate this using specific nonce test cases if I knew the layout but since the chips are only ~300MH/s it might take a while to test ... i.e. 'seconds')

My plan is to code a detect function that sequentially feeds a known "golden" data set to each chip and listen for the nonce returned. So this would be hard coded into the firmware. Mostly this is to test chip presence and function. However, by using a nonce that is X hashes away from golden, a brief timing of the result could give you actual speed. I wasn't planning this for now as the calculations would be more difficult on a PIC than using pre-calculated tables.

What I have partly coded is an array [8] of nonce base count, timer divider, and tick count values. So when detecting eg. 5 chips per bank I use that value to choose that I'll send N = 2^32 / 2 / 5 as base count for each range. So nonce1 starts 0, nonce 2 starts N, nonce 3 starts N+N, etc. Then I have a counter that runs at 12MHz / 256 / X value where X is set based on hash clock config. This would be chosen to tick very close to every 256,000 hashes and should be reliable. Now I count these ticks, and for current chip count I compare to the table value to decide when to push more work. This should find me pushing new work just before the end of each nonce range is reached, and have a tick count value for work aborts that allows reporting how far we got within 256,000 hashes.

What I could use is a reference to code into the firmware. I realize that any new block would have valid values. I thought it may be nice to code in a special one. eg. midstate all zeros or data 0xdeadbeef... etc.

The Icarus golden nonce I found last year by going through the blockchain (with a php script I wrote)
(I needed one that was fast to test the presence of the Icarus - the Icarus one is 0.53ms on an Icarus)

On the other hand if you want specific case results (but not specific values like you mentioned) it's probably easier to add a few lines of code into cgminer looking for a result "type" you want and spit it out if it ever finds one while mining normally.

My Jalapeno would be good for this since they return all the nonce values (well up to a max of 8 ) for a given work item.
Anyway if you want to be specific about the chip layout and the expected nonce range (I'm not too clear from what you said) I could look for a work item that returns values effectively for each chip and thus I'd know if it only returned say 3 of 4 values, which chip was missing ... as an example.

However, I'd also suggest it's probably easier to divide up the nonce range with a fixed N
As you know, it doesn't matter if you don't use the whole range, and simply sending the work 1/8 to each chip (if there are a max of 8 per bank) and obviously not using all 8 of 1/8 if there is a chip missing, should make things even simpler I'd imagine for you ... and more 'constants', less 'variables'

Again, the only reason I'd need to know the chip count would be if some are missing/faulty to determine the MH/s
Breaking the nonce range up depending on the chip count is OK if it's easy for you to do, but I was just thinking that breaking it up on a constant size would be easier - but that's up to you.