cur % is the percentage of the keyspace of the current getwork already calculated and checked. You have ~ 4 billion possible nonces per getwork that need to be tried. 50% would mean that we are currently trying nonce ~ 2 billion.

subm is the number of successfully submitted shares. It might be higher, lower or equal to the number of processed getworks.

stale is not quite appropriate as it includes both stale and invalid shares. Under normal circumstances, there shouldn't be any invalid ones, however with higher temperatures and too much OC, it is possible that the hardware starts calculating hashes incorrectly. Abnormally high stale numbers mean that there are hardware problems.

subm is the number of successfully submitted shares. It might be higher, lower or equal to the number of processed getworks.

How can this be possible...?And anyway why there is difference between processed and submitted?

Quote

stale is not quite appropriate as it includes both stale and invalid shares. Under normal circumstances, there shouldn't be any invalid ones, however with higher temperatures and too much OC, it is possible that the hardware starts calculating hashes incorrectly. Abnormally high stale numbers mean that there are hardware problems.

What is "abnormally high"?It would be very useful to know the number of "real" stale shares and the invalid ones to diagnose hw problems.For example, I've an efficiency of around only 90%: is this an "abnormally low" number?(I suspect it should be near 100%)

How can this be possible...?And anyway why there is difference between processed and submitted?

It is possible because you can have either 0, or 1 or more than 1 possible "solutions" for a single getwork.

Quote

What is "abnormally high"?It would be very useful to know the number of "real" stale shares and the invalid ones to diagnose hw problems.For example, I've an efficiency of around only 90%: is this an "abnormally low" number?(I suspect it should be near 100%)

Without -D I guess anything below 3% would be OK, with -D probably more. Stale percentage of 20 for example smells rather fishy.

There are also issues with the ADL monitoring I am currently working on.

And since I am building a small rig as well, I noticed some things that can be improved. For example we can log the output into a convinient to parse file or SQL database so that web frontend can be done much less painfully. So there is some work to do. I will hopefully release a new version in 2 or 3 weeks. No performance benefits expected though

Well,I know this sucks, but I am too tired of that "release early, release often" stuff. I need some more time to properly address all the issues instead of relying on feedback for each small incremental improvement and bugfix.

* progress now autosaved in a text file, json format. It is autosaved in ~/.hashkill/bitcoin.json . This file can be parsed in order to implement external tools that collect statistics, draw graphs, provide web interface and stuff. This feature will be extended in the future to provide GPU temps info and pool stats.

Shouldn't slow down. File is rather small. It is overwritten each 5 seconds so if you want to generate graphs or stuff, you gotta write a script that parses that each 5 secs and e.g updates a sql database. hashkill does not keep history of past values.

P.S if you need to tune speed, play with -D and -G2/-G3/-G4 options until you find a balance. -D -G2 works best for me (2x5870/1x6870).

It is surprisingly accurate eheh, real speeds vary up to +/- 1.5% as compared to estimations on real tests I've done on different hardware. Formula is rather simple, but anyway we are getting OT here...

So I guess 5850 is more energy efficient than 6950. But then other factors come into play (e.g you may be limited on pcie slots or stuff, then faster cards may be better even if they are not that power-efficient).

Heat is a bitch. But then, it could be much worse - there are places much warmer than Bulgaria. And electricity is cheap ATM (however with that renewable energy EU crap it might soon get much more expensive).