Quote from: DiabloD3 on March 14, 2011, 02:47:10 AM

Quote from: Cerebrum on March 13, 2011, 02:59:19 PM

Quote from: planalpha on March 12, 2011, 02:28:29 PM

Thanks, Diablo3!
That got it working. But any idea why I'm only getting about 5000khps? Seems like something's wrong...

Did you try using -f 1? That improved my performance on a 5970 from about 15M Hash/s to about 330M Hash/s.

I have no idea why DiabloMiner is affected by the -f option so much more than poclbm, but apparently it is.

Also, is there a way that we can have DiabloMiner output all those interesting statistics about mining like the modified version of poclbm that's been going around here? (Invalid/Stale Percentage, Current position in the getwork, Ratio of getworks to submissions, hashrate, ratio of getworks to answers with more work in them) Those were great for getting a very condensed picture of how your mining is going.

-f effects it because my global run size code is more finely tuned than his. If larger -fs work, that indicates either a driver bug or a bug in the OS's scheduler.

I don't intend on adding all those numbers to -d because they have no use. You have zero control over those, and they are not informative.

I'd debate whether those statistics are informative or not. I don't give a damn about that efficiency statistic, nor the current getwork number, or the spot in the current getwork. However, a statistic on how many of the hash solutions found were invalid/stale would be great. That's what's telling me that I should stick with DiabloMiner instead of switching to poclbm, since poclbm reports that 3-5% of hash solutions are invalid, but gets about 2% better hashrate than DiabloMiner.

However, since DiabloMiner remains mute on that subject, I assume that no hashes computed by DiabloMiner are invalid or stale. This leads me to the conclusion that I should use DiabloMiner over poclbm, so it would be good to include that statistic, if only to allow the users to make a more informed decision about which miner they should use to get the most out of their hardware investments.

And about that not being controllable: As I understand it, that metric is within the user's control as soon as overclocking is involved. If overclocked too aggressively, cards start producing invalid hashes more frequently, no? This may be a useful tool for properly tuning overclocking settings.