The download and compiling worked (i changed the max hashrate before). Now it understands the d sign. I only have to test now if it changes things.
But i dont understand the java API stats part. Is this a java program part? I dont have a clue how to use it. I saw the commands you gave but i cant find where to enter that command.
If you have java installed on your computer then in the cgminer folder type:
java API statsand it will report all the extra internal stats and related debug info stored in cgminer
The Avalon extra stats are there plus the BTB voltage.
Another question regarding the most efficient settings. Where can i see this best. WU seems to be the whole work. Including HW and rejected shares. There is unfortunately no U stat. And the hashrate seems to include rejected shares too. So where can i see the cleaned stat for the useful hashingresults so that i know the best settings? I till now use the average hashrate and WU but those are polluted with useless work. Is there somethine better? Maybe using a timer and counting the accepted shares?
WU: is 1diff and work returned by the device that isn't a HW error.
You can also reset it but you will zero all the important stats in cgminer when you do it:
java API "zero|all,true"However, the 'true' on the end means it will print a full summary of everything before it zeros them all
The way the Avalon code works, you can't get a reliable estimate of the result of a change without waiting an hour or so.
The Avalon code uses the found nonces to determine the hash rate (which is of course greatly affected by variance)
Of course over a long period of time that's pretty accurate, but over a short period (even 1 hour) it's not all that accurate at all.
However, WU: is of course the best thing to use.
The old U: was meaningless on any pool with variable diff
You may notice now that A: and R: are also 1diff since again on a variable diff pool the old versions were meaningless.
Anyway. I tried the d-param and found that its not the best value. For example when i run it at 475mhz and 1400mV its a whole lot worse than when i give the timeout. I tend to believe that the needed timeout might be changed by the voltage but i dont know since i cant tell what timeout that is at all.
The temperature was at 44°C when running at 1.4V and 475mhz too only. With full hashing at 1340V and 450mhz its at normal 49°C.
So raising the hashrate gives worse results. The temperature is lower, the chips work less.
The d param cant help. I tried many different values with no success. Its like the chips wont work anymore. Maybe its really some border of the board parts. But i doubt a bit since at 1.4V and 375mhz the wattage is 340W instead nearly 500 when it fully runs at 450mhz and 1340V.
Ill set it back to these settings now since i dont know better ones yet.
...
timeout is in ms
The timeout calculated is simply how the Avalon has always done it since it was added
I've not actually thought about why it is exactly "12690 / freq"
The point of it though is to ensure the chips don't repeat the hashing they are doing.
So if it is too high, you can get duplicate hashes and loss of GH/s due to redoing work.
If it is too low, you get more latency due to having to send work more often.
If someone wants to check that and come up with a better calculation for BTB - let me know - and explain it - and I'll use it