I've added custom temperature control to the avalon code in the cgminer git master.
It now acts like a simple PID controller trying to maintain a target temperature, which by default is set to 45 degrees, so it will try to keep the temp 43~45, but never going below a minimum fanspeed of 20% as a safety precaution and to maintain airflow.
You can modify this value with the new command:
--avalon-temp
Setting this to something very low will have the same effect as turning the fans up to maximum and vice versa.
If you are not running it from a command line, it can be added to the "More options" box in the web interface (once you have the binary on your machine).
Can someone please post a build of this? I haven't figured out how to compile it for openwrt yet. |
|
|
|
You haven't specified a backup pool  |
|
|
|
|
I've added custom temperature control to the avalon code in the cgminer git master.
It now acts like a simple PID controller trying to maintain a target temperature, which by default is set to 45 degrees, so it will try to keep the temp 43~45, but never going below a minimum fanspeed of 20% as a safety precaution and to maintain airflow.
You can modify this value with the new command:
--avalon-temp
Setting this to something very low will have the same effect as turning the fans up to maximum and vice versa.
If you are not running it from a command line, it can be added to the "More options" box in the web interface (once you have the binary on your machine).
|
|
|
|
The option to donate some of the hash rate (%) to the developers was not added , this also must be added
As I've said numerous times before - this proved to be a very controversial and at times unpopular feature and was very poorly subscribed previously. |
|
|
|
|
Compile. There's no command outside of what the driver does internally to change fanspeed. It's very hard to make some kind of meaningful interface to control that when most users rely on the web UI and changes to that lag far behind any command lines I add. Maybe I can add some command line parameters and you could add them to the "more options" section.
|
|
|
|
I modified the crontab to run cgminer-monitor every minute to help mitigate the effect.
say what? how do i do this? From the shell 'crontab -e' (this runs vi). Replace the */5 or */2 (varies with firmware version) with */1 to check if cgminer is hung up every minute. This would make it restart cgminer if a pool is down since it takes 1 min of pool downtime for cgminer to declare it dead reliably. |
|
|
|
I would never risk running the avalon higher then 325 on any of the stock PSU's not even the 2nd Batch Avalons.
Assuming ~85% efficiency for the PSU, and drawing 700W at the wall, that's only 595W draw, and the 2nd batch avalons have 750W PSUs. Yes I know not all PSUs are created equal, but that's running them at about 80% power draw. |
|
|
|
Anyone know what the settings would be for an overlock to 345mhz? I was running these with the Strombom firmware and appeared to get lesser hw errors
I haven't included support for 345 Ok, so I guess strombom had some custom additional modifications in his firmware? In his firmware the 345mhz seems to be the sweet spot for me. I am currently getting around a 2.3% HW error rate using the (hw/diff1shares+hw formula). Accepted shares 7555, HW 12034. Does this seem to high? Thanks I suggest you look at the hashrate reported and ignore the HW error count, as the cgminer driver for avalon doesn't count HW errors as part of the hashrate. That means that if the work is valid, the hashrate goes up, so that is your ultimate measure of useful work. Even if your HW error count worked out to 5%, if your overall hashrate was higher then you'd be earning more. I don't know if hardware errors themself mean the device is more likely to suffer damage though, since I don't know the voltage relationships, so I can't say... |
|
|
|
|
I take back what I said about the power usage, there was a problem from the angle I was looking at it, misreading the LCD. Power usage is 698W at speed 350, 240V.
|
|
|
|
Anyone know what the settings would be for an overlock to 345mhz? I was running these with the Strombom firmware and appeared to get lesser hw errors
I haven't included support for 345 |
|
|
|
|
Other windows monitoring tools don't actually use the ATI Display Library. They have direct access to certain registers and can read them which cgminer will never have.
|
|
|
|
Some results so far 350 with fans hacked to max speed  Elapsed 3h 10m 59s Diff1 Accepted 217849.00000000 1140.67/m 81652.35 I am positive that it will stay above 80 in long term I am very happy! Con, can you please advise us how to calculate HW error rate in %Thank you HW / (Diff1shares + HW) * 100 |
|
|
|
|
There appear to be 4 temperature sensors on your 5770. Cgminer only gets the one value offered from the ATI display library and reports it back. It seems the ATI Display Library is reporting back temperature GPU TS0 (whatever tf that is).
|
|
|
|
|
Mine is a batch 2 running at 240V for what it's worth, and it's a lot cooler here, being winter. Not sure which if any of the above are responsible for it, but it sounds like mine draws more power at regular speeds but less when overclocked compared to others' here?
|
|
|
|
Hmm, in one of my Avalons controller board freezes with 36:350 setting after 10-20 minutes. I need to power on/off. Con, is there any way how to reset it remotely?
Not unless you have an external power controller of some kind as far as I'm aware. |
|
|
|
|
From ASIC README:
34:375
36:350
39:325
43:300
45:282 (default)
47:270
50:256
|
|
|
|
Latest version of the firmware 06-07 produces a LOT of HW errors. For example, 102 accepted shares 62 HW errors. It also oddly stops hashing intermittently. I am guessing cgminer is crashing or something as the monitor script revives it and it resumes hashing but still with the unusually high error rate. 0519 has been rock solid for me so I flashed back to that version.
I'm running it at 300 if that has any bearing on anything. Anyone else noticing this or is it just my unit? I should also mention that I did not clear the settings before flashing to 06-07 (I told it to remember settings).
This is a combination of more accurate reporting of hw errors, and more software caused errors as a result of the changes. Fixes are in newer cgminer code which has yet to make it into a new firmware for you to flash. |
|
|
|
mv command returns mv: can't rename 'cgminer': No space left on device  . I'm not sure why as filesystem is rw. Flash filesystems aren't really rw. They are only write once and you cannot delete from them. When you delete a file, it makes the file inaccessible but you never regain the space till you flash the firmware again. Oh thanks for explanation, I have no experience with flash filesystems, so I was a little bit suprised by this behavior. Any idea how to change it without new fw flash? |
|
|
|
|
Show Posts
