Maybe so.

To be able to average 5 blocks per diff change I'd say, mitigating the loss if you'd miss getting a block across a diff rise which you will never recover.

cgminer lost its CPU mining code a long time ago now.

The hardware errors need to be divided by the diff... I'm absolutely sure you're not at 10-20% errors.

Hah, well don't take my word for it, as I said, it's pure speculation.

Very much dependent on the chips, so this can only be a wild guess, but... 80+ degrees?

I guessed this might be the case since the temperatures really aren't getting into the error range even with regular air cooling - especially since it's 3 degrees at my home overnight and the hashrate doesn't go up. I suspect the hashrate will only get higher with more voltage given to the chips.

And thank you

I'm sure instability can manifest in any number of ways, and it's probably either resetting the device regularly due to the chips failing or idling frequently due to the PSU not keeping up or something along those lines.

Unlike the GPU code, they're totally independent as. Clock speed is determined solely by hardware errors whereas fanspeed is determined by temperature. HW errors tend to run hand in hand with temperature rise on this sort of hardware whereas GPUs are designed to be deterministic right up to failure so hw errors are meant to almost never happen.

Hmm... Auto wont start changing clocks unless the actual nonces returned are within 10% of expected, so perhaps try enabling auto and start at lower clocks like 300.

Try restarting it a few times from the interface perhaps? I find it a bit less reliable to start up normally. But yeah, I don't know why that would be the case...

No idea why that would be the case. Auto tries to keep HW errors below 1.5%. Are you sure you're not mining at a higher diff?

Appreciate the donation, thanks  

In actual fact, the fans are told to slowly increase before the target is hit. The thing is, the fans don't really support such small increments in PWM settings and ignore it till certain thresholds. These fans don't support fine control like a GPU fan and really only have about 6 different speeds. Writing a true PID controller with the mathematics involved is truly overkill for this purpose, and the lack of granularity of fanspeed control would make it a futile exercise. The tiny overshoot followed by huge fan boost you describe should only happen when you first start your avalon for a few mins or if you set your temp to very close to the minimum temp your hardware will run at (something like 35?).

I'll look at further config options in the future, time permitting.

A few notes about the auto-clocking approach.

First and foremost, you can fry your hardware as you are running your avalon out of specification, especially if you try it on a batch 1 device with its lower power and quality PSU.

As is virtually always the case, manually fine tuning the final result will always be better than an automated process that guesses. With time I wish to get rid of the requirement to have fixed intervals and allow the user to specify any arbitrary value for the frequency, though the interface coping with it is a bit of an issue at the moment.

Ironically some people are finding the frequency a little too high and others a little too low. I suspect everyone is looking at a different endpoint for what is an ideal frequency in their eyes. The targets I've set are based on hardware error as a percentage, with hysteresis of +/- 0.25% - this is because a .5% increase in hardware errors works out to the amount the hashrate would rise with 2Mhz increments; i.e. if your hardware error count is going up at the same rate as the hashrate should rise, you are wasting energy. Ideally, a regression plot is what would be needed, getting the hashrate rise with each increment and the hw error percentage rise, and seeing when one grows faster than the other, but this is absurd stats to try to go looking for, especially when the values fluctuate wildly under normal circumstances only. By default with avalon-auto, you will get hardware errors of 1~1.5% . When looking at the hardware error count, make sure you are comparing it to the diff1 shares and not the accepted since you will almost certainly be mining at higher diff. Hardware errors are harmless in their own right but indicative of how hard you're pushing the chips for their available voltage and cooling. It sounds like these chips are capable of much more with more voltage but no one's done said mod yet.

The way to calculate hardware error percentage is:
HW * 100 / (diff1 + HW)

It's also worth mentioning that to simplify the calculation of different frequencies, the values passed to the avalon with this latest firmware on the "regular values", i.e. 300 and below, is slightly lower than the values that would have been passed to it, but it should make only a negligible difference to hashrate, lost in the noise of normal variance that happens with hashrate. The "timeout" value passed is also smaller now, which means you may hit the limit at lower speeds than you used to - but the old timeouts were too high, and even if you apparently had a higher hashrate, if you go back and check your stats you may find you were getting more rejects. This is because the higher timeouts were leading to duplicate shares being generated so it is only a disadvantage.

A sure fire sign that you're overdoing it is cgminer repeatedly being restarted by the avalon watchdog, or periods of hashrate dropping, or smoke coming out of your PSU.

Not any time soon, sorry, but you are missing packages to build it yourself.

With strombom they run your fans at 100%. You can achieve the same fanspeed with my firmware by using --avalon-temp 0

36 will be generating dupes. Check your rejects

There is a relationship, but you'll have to experiment and tell me what you find yourself. It's cold here so nothing runs hot even with fans at their lowest.

Thanks appreciate the donations ^_^  

It goes up by 2Mhz and down by 1 at a time, and the timeout is automatically adjusted via my new algorithm based on the highest I could find that wouldn't create dupes (the previous values still would on occasion). I spent a few hours playing with what ratio of hardware errors to hashrate yielded close to the ideal amount. It will be interesting to see if those with massive cooling, extra power, setting their target temp lower and so on, what speeds it will tune to. Mine sits at 351.

New release: version 3.3.1, 26th June 2013

Hotfix release. Last minute bug went into 3.3.0 preventing BFL SC singles from working as planned
Note now there are avalon firmware images in my directory as well, with the latest version.

Human readable changelog:

- Bugfix for BFL SC singles and minirigs which prevented them working.
- Bugfix for the usb wildcards 1:*
- Increased target temperature on Avalons to 50 since 45 was overkill
- Added overheat temperature cutoff to avalons
- Added dynamic automatic overclocking to avalons with --avalon-auto


Full changelog:

- Add an avalon-auto option which enables dynamic overclocking based on hardware
error rate for maximum effective hashrate.
- Add an --avalon-cutoff feature which puts the avalon idle should it reach this
temperature, defaulting to 60, re-enabling it when it gets to target
temperature.
- Change default avalon target temperature to 50 degrees.
- usbutils - incorrect test for * in bus:dev
- Redo +1 fix in bflsc.