Hi,
I noticed that too and asked CKolivas. He replied:
The old avalon code lied about the hashrate and lied about the hardware errors. It counted hardware errors as hashrate (and since it's a hardware error it can't be valid hashes that it's doing) and didn't count "no matching work" scenarios as hardware errors. So the new code will appear to have a lower hashrate and a higher hw error count, but in fact it's doing more useful work and just not lying about the rates (along with all the other benefits in the new code).
https://bitcointalksearch.org/topic/m.2406402
With my deep respect to Con and Kano i can state following:
I calculate my ACTUAL hash rate as advised by Kano taking in account Diff1 shares accepted from pool(s) and cgminer up-time. This gives me EXACT (Real) hashrate. Knowing the fact my network was fine and i did not have downtime due to Network issues, pool issues or FPGA controller hangs (I am monitoring it every two minutes + automated power off/on no reboots) i am 100% sure that 3.2 is not performing. The magic can be this commit:
https://github.com/ckolivas/cgminer/commit/bd6bc6bd23424958ebf1d49f22d6a50070d13d23
Not tested yet. Avalon image was released before that
It may turn out that 24 Hours run is not enough because of the variance and/or bad luck - that is the only fact that makes me uncertain about 3.2 performance. I will give it another 48 hours run next weekend and i will report back the results. Mean while i will stick to 3.1
Best
PS: just for the reference (do math yourself)
Computer: cgminer 3.1.1
Elapsed: 7h 11m 30s
Difficulty Accepted:431530.00000000
MHS:71587.77
That was not happening with 3.2
To be honest, I haven't tried to compute that and I don't have the old reference numbers. As new FW is rock stable for me, I haven't tried other things yet due the time restrictions . Of course if performance can be better, I'll be glad .