Thanks for all the explaination.
I guess i dont have Java installed then on the rpi, i used a noob image for raspi. Raspberian or so. But i will try again when im home.
Is WU including rejected shares too? I found an interesting thing in the morning when i tested with the timeout a bit. I sat 1340mV, 450MHz and 25, or was it 20ms? timeout. After 10 minutes there were zero rejected shares. ZERO. While normally 13% rejected shares appear. I cant explain but the hashrate at the pool went from 38GH to 42GH by doing this. So it looks it really has an effect. The hashrate in cgminer didnt change by doing that so i think rejected shares are included and its not a safe value to judge efficient. Maybe its best to use the pool for the value since it only seems to count hashrate that delivers correct shares.
So at the moment i believe WU includes rejected shares too since they didnt change.
Im still puzzled about the drop in hashrate, wattage and all when using higher values. I hope burnin finds an explaination.
Meh, I wish my 2nd RPi would hurry up and arrive.
I run Arch on my RPi now and it's in my garage, so it's annoying to switch it back to Raspbian temporarily to check anything
(also one of the reasons why I bought a 2nd RPi)
Anyway I think the package is:
apt-get install openjdk-7-jdkRejected shares are not HW errors.
Rejected shares should only be during an LP - coz of:
1) Your hardware latency is high
This can be reduced by aborting the work at LP rather than waiting for it to finish.
I'm pretty sure it can't be done with an Avalon, but there was mention of adding an abort to the BTB firmware
Reducing the timeout will also reduce this, but reducing the timeout too much is also bad as I mentioned before
2) Your pool latency is high
Speed up your connection to the pool (too many hops, too much latency through the net from you to the pool ...)
Tell the pool to do better when supplying you with LP information - e.g. use Stratum (not GetWork or GBT)
3) Some pools don't handle diff changes properly or don't handle a stratum reconnect properly ...
Some pools also pay Stale shares (which is what a Rejected share is in cgminer) so you shouldn't get them on those pools
The pool itself also replies with the reason why the share was rejected - that's what's in the () at the end
HW is ignore since indeed it is a fault of the hardware.
I was able to install that java package but when i run that command in cgminer dir and cgminer is running "bash: java: unknown command" for all commands you wrote.
Anyway. I know the formula now. I calculated that 450MHz should be 28.2ms timeout. Im not sure if its perfect because when i tested it at the day i got 10% rejected shares. One ms less zero rejected shares. But now, at the evening i cant replicate that anymore. The d param works now and no rejected shares. I dont know why.
My pool doesnt count rejected shares and i wouldnt want my pool paying out rejected shares to others when i know how i can prevent rejected shares.
Based on this i started another test. I sat the mhz to 450 and didnt bother with HW. Only WU was of interest for me. Even with >50% HW the WU calculates all shares. Every test i ran for 15minutes after that my htc ringed to read the values. After that time the values have relatively good settled. So i tested and found that the optimum voltage is 1228mV with 670WU. Unfortunately when it became later and the temperature went down outside the bitburner cooled down too. Which leaded to the effect that the temperature went from 50°C to 46°C and at the same time 1228mV only was 630WU anymore. Instead the optimum voltage was at 1224 now. 4mV less because 4°C less. So 4mV does have such a big impact. I tend to believe a settings per °C is needed because one cant change it back and forth when you host it at a datacentre.
*sigh* And i hoped to find an ideal setting...
At least its interesting to know that the voltage always has a sweet spot at a working temperature. Going 100mV above or below has a big impact. Even one mV can have a not small effect. I cant explain why.