Regarding T=361680. You're so right. 10hrs * 3600 = 360000 (oops should be 36000) + 28 mins * 60 = 1680. Total 37680 seconds. Geez the original 361680 gave me the magic number I was looking for that I did not even double check the math. How coincidental is that? Furthermore, I did not even multiply A * 65536. What a brain fart on my part. With the given correct number of seconds and using your formula A * 65536 T, the new number is 3908096*65536/37680=6797265.909 or 6.8mhs. You've got it. Is that suppose to be an average of something? Or is that how CM computes mhs at any given time?
My 2 blades run cool at the touch even around the voltage regulators. I've got it clocked conservatively at 800mhz. No usb errors ever in the system logs since I got them a little over a week ago. And the first (and last) week on weminerltc, they ran at a steady 10-10.5mhs on their charts.
The 9th and 10th hour just came in at 5.41 and 5.24. And the Last Hour Hashrate right now is 5.2mhs. cgminer is still rocking at 10.8mhs. I'm not sure what's going on. Could you explain your formula a bit more? Thanks much for the input.
Edit: I think I know what's going on. Since the formula for the hash rate is based on accepted shares, all 4 of my blade boards had the proper hash rate, BUT 2 of them did not have the proper wu rates which led to improper accepted rates. ahha. I decided to reset the system and give it another whirl. So far so good. All 4 boards are logging expected numbers. Hopefully, the numbers will reconcile with CM's hash rate. Thanks again for the road map and interesting conversation.
cgminer's "A" is "difficulty 1 shares". In scrypt context a "diffculty 1" share has a probability of 1/65536 (2^16), i.e. on average one out of 65536 hashes will be a diff 1 share. Since we know the number of shares (A) and the probability of each share (1/65536) we can estimate how many hashes the miner calculated (A * 65536). Divided that by the number of seconds and you get hashes per second. The pool must be using something similar to calculate your hashrate, perhaps A+R instead of just A.
WU is directly related to that, I just don't remember the exact formula right now. If some of your boards had a much lower WU, then that's obviously an issue. You can calculate the estimated hashrate for each board separately using the same formula, and if it's been running long enough you can just eyeball the "A" for each board and see which ones are lagging. 10-20% could be normal variance, more than that is certainly suspicious.
I hope you'll get it sorted out.
