Hi ckolivas, thanks for everything. What I have noticed is STROMBOM's firmware + 325 mhz is giving about 1-2% HW errors. On the other hand the latest you put out with the --auto and temp targetting is throwing 15-20% HW errors at the same clock. Is there any way to combine the best of both worlds and get strombom's level of HW errors, but with the ability to control the temp? Would be greatly appreciated.
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? 
Topic: Avalon ASIC users thread - page 155. (Read 438600 times)
fans are heavily circulating from min to around 3400 rpm when i set target-temp to 48 degrees
they are influencing power draw above values are taken @min speed
high speed will draw about +15W
will try agin with default temp;)
donated 1BTC to ckolivas 7a398e9723d533dfc13d99ec44e040645704f939e037851a84cddc430dab0d00-000
rpm starts a min raises to over 3000rpm when target-temp is hit and then slowing down to min step by step
seems not the optimal strategy - I think better raise fans slowly before target is hit
@ckolivas
and if I'm allowed to express a wish:
40% fanspeed as min also will be fine for me;)
or also configurable as knows from gpus..
Appreciate the donation, thanks they are influencing power draw above values are taken @min speed
high speed will draw about +15W
will try agin with default temp;)
donated 1BTC to ckolivas 7a398e9723d533dfc13d99ec44e040645704f939e037851a84cddc430dab0d00-000
rpm starts a min raises to over 3000rpm when target-temp is hit and then slowing down to min step by step
seems not the optimal strategy - I think better raise fans slowly before target is hit
@ckolivas
and if I'm allowed to express a wish:
40% fanspeed as min also will be fine for me;)
or also configurable as knows from gpus..
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.
Hi ckolivas, thanks for everything. What I have noticed is STROMBOM's firmware + 325 mhz is giving about 1-2% HW errors. On the other hand the latest you put out with the --auto and temp targetting is throwing 15-20% HW errors at the same clock. Is there any way to combine the best of both worlds and get strombom's level of HW errors, but with the ability to control the temp? Would be greatly appreciated.
fans are heavily circulating from min to around 3400 rpm when i set target-temp to 48 degrees
they are influencing power draw above values are taken @min speed
high speed will draw about +15W
will try agin with default temp;)
donated 1BTC to ckolivas 7a398e9723d533dfc13d99ec44e040645704f939e037851a84cddc430dab0d00-000
rpm starts a min raises to over 3000rpm when target-temp is hit and then slowing down to min step by step
seems not the optimal strategy - I think better raise fans slowly before target is hit
@ckolivas
and if I'm allowed to express a wish:
40% fanspeed as min also will be fine for me;)
or also configurable as knows from gpus..
Appreciate the donation, thanks they are influencing power draw above values are taken @min speed
high speed will draw about +15W
will try agin with default temp;)
donated 1BTC to ckolivas 7a398e9723d533dfc13d99ec44e040645704f939e037851a84cddc430dab0d00-000
rpm starts a min raises to over 3000rpm when target-temp is hit and then slowing down to min step by step
seems not the optimal strategy - I think better raise fans slowly before target is hit
@ckolivas
and if I'm allowed to express a wish:
40% fanspeed as min also will be fine for me;)
or also configurable as knows from gpus..
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.
Thank you for taking the time to write this informative description and update.
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.
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.
what is the source of HW errors? --avalon-auto on the new firmware is throwing a 1:1 ratio of accepted: HW ... any ideas?
testing ckolivas auto feature now -> very nice
ATX: Corsair AX860
speed Mhz power @wall @230V
300 595 Watt
310 610
320 630
330 650
341 670 seems to stop @ this frequency?
giving me additional 6-7 GHs
fans are heavily circulating from min to around 3400 rpm when i set target-temp to 48 degrees
they are influencing power draw above values are taken @min speed
high speed will draw about +15W
will try agin with default temp;)
donated 1BTC to ckolivas 7a398e9723d533dfc13d99ec44e040645704f939e037851a84cddc430dab0d00-000
rpm starts a min raises to over 3000rpm when target-temp is hit and then slowing down to min step by step
seems not the optimal strategy - I think better raise fans slowly before target is hit
@ckolivas
and if I'm allowed to express a wish:
40% fanspeed as min also will be fine for me;)
or also configurable as knows from gpus..
great job!!!
go on
ATX: Corsair AX860
speed Mhz power @wall @230V
300 595 Watt
310 610
320 630
330 650
341 670 seems to stop @ this frequency?
giving me additional 6-7 GHs
fans are heavily circulating from min to around 3400 rpm when i set target-temp to 48 degrees
they are influencing power draw above values are taken @min speed
high speed will draw about +15W
will try agin with default temp;)
donated 1BTC to ckolivas 7a398e9723d533dfc13d99ec44e040645704f939e037851a84cddc430dab0d00-000
rpm starts a min raises to over 3000rpm when target-temp is hit and then slowing down to min step by step
seems not the optimal strategy - I think better raise fans slowly before target is hit
@ckolivas
and if I'm allowed to express a wish:
40% fanspeed as min also will be fine for me;)
or also configurable as knows from gpus..
great job!!!
go on
It seems that only one of my Avalons benefits from the new automatic clock adjustment option. The other two decrease such that setting them at a set, higher point yields obviously better results - at least based on the "MHSav" reading.
BTW, CGMiner team is awesome!
Hi.
I've uploaded a new firmware with the about-to-be-released cgminer 3.3.1 with 2 new features which I hope you'll like:
http://ck.kolivas.org/apps/cgminer/avalon/20130626/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin
--avalon-auto Adjust avalon overclock frequency dynamically for best hashrate
--avalon-cutoff Set avalon overheat cut off temperature (default: 60)
this is in addition to the existing options:
--avalon-options Set avalon options baud:miners:asic:timeout:freq
--avalon-temp Set avalon target temperature (default: 50)
I've uploaded a new firmware with the about-to-be-released cgminer 3.3.1 with 2 new features which I hope you'll like:
http://ck.kolivas.org/apps/cgminer/avalon/20130626/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin
--avalon-auto Adjust avalon overclock frequency dynamically for best hashrate
--avalon-cutoff
this is in addition to the existing options:
--avalon-options
--avalon-temp
I flashed my Batch 2 with this and now I cant connect. What's the IP ?
would be the same as before, can you see it at the router? something went wrong during flashing?
I got in. Thanks !
Hi.
I've uploaded a new firmware with the about-to-be-released cgminer 3.3.1 with 2 new features which I hope you'll like:
http://ck.kolivas.org/apps/cgminer/avalon/20130626/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin
--avalon-auto Adjust avalon overclock frequency dynamically for best hashrate
--avalon-cutoff Set avalon overheat cut off temperature (default: 60)
this is in addition to the existing options:
--avalon-options Set avalon options baud:miners:asic:timeout:freq
--avalon-temp Set avalon target temperature (default: 50)
I've uploaded a new firmware with the about-to-be-released cgminer 3.3.1 with 2 new features which I hope you'll like:
http://ck.kolivas.org/apps/cgminer/avalon/20130626/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin
--avalon-auto Adjust avalon overclock frequency dynamically for best hashrate
--avalon-cutoff
this is in addition to the existing options:
--avalon-options
--avalon-temp
I flashed my Batch 2 with this and now I cant connect. What's the IP ?
would be the same as before, can you see it at the router? something went wrong during flashing?
Hi.
I've uploaded a new firmware with the about-to-be-released cgminer 3.3.1 with 2 new features which I hope you'll like:
http://ck.kolivas.org/apps/cgminer/avalon/20130626/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin
--avalon-auto Adjust avalon overclock frequency dynamically for best hashrate
--avalon-cutoff Set avalon overheat cut off temperature (default: 60)
this is in addition to the existing options:
--avalon-options Set avalon options baud:miners:asic:timeout:freq
--avalon-temp Set avalon target temperature (default: 50)
I've uploaded a new firmware with the about-to-be-released cgminer 3.3.1 with 2 new features which I hope you'll like:
http://ck.kolivas.org/apps/cgminer/avalon/20130626/openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin
--avalon-auto Adjust avalon overclock frequency dynamically for best hashrate
--avalon-cutoff
this is in addition to the existing options:
--avalon-options
--avalon-temp
I flashed my Batch 2 with this and now I cant connect. What's the IP ?
And what should be the recommended PSU wattage for 350 Mhz and 4 modules?
+1. Iam going to upgrade 3avalons with a 4th module from my 4th unit..... eill this need more than 850w psu? what psu Is highly recommended
How are you getting a 4th module?
And what should be the recommended PSU wattage for 350 Mhz and 4 modules?
+1. Iam going to upgrade 3avalons with a 4th module from my 4th unit..... eill this need more than 850w psu? what psu Is highly recommended
How are you getting a 4th module?
yes I did that and they sitting at 354 since 5 hours. Can you make a binary only to test with up to 5% HW rate? I don't get it cross compiled...
...can not find curses.h or ...../mips-openwrt-linux-uclibc/bin/ld: cannot find -lcurl
Not any time soon, sorry, but you are missing packages to build it yourself....can not find curses.h or ...../mips-openwrt-linux-uclibc/bin/ld: cannot find -lcurl
Code:
export STAGING_DIR=/home/mike/openwrt/trunk/staging_dir
export TOOLCHAIN_DIR=$STAGING_DIR/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2
export PATH=$TOOLCHAIN_DIR/bin:$PATH
export LDCFLAGS=$TOOLCHAIN_DIR/usr/lib/
export LD_LIBRARY_PATH=$TOOLCHAIN_DIR/usr/lib/
./configure --build=mips-openwrt-linux-uclibc --disable-opencl --disable-adl --enable-avalon
make CC=mips-openwrt-linux-uclibc-gcc LD=mips-openwrt-linux-uclibc-ld
My 2 avalons sitting at 355/352. Temps 35/41 and 35/39
--avalon-temp 40
With strombom firmware they run @365 86.9 GH after 20h
With strombom they run your fans at 100%. You can achieve the same fanspeed with my firmware by using --avalon-temp 0--avalon-temp 40
With strombom firmware they run @365 86.9 GH after 20h
...can not find curses.h or ...../mips-openwrt-linux-uclibc/bin/ld: cannot find -lcurl
My 2 avalons sitting at 355/352. Temps 35/41 and 35/39
--avalon-temp 40
With strombom firmware they run @365 86.9 GH after 20h
With strombom they run your fans at 100%. You can achieve the same fanspeed with my firmware by using --avalon-temp 0--avalon-temp 40
With strombom firmware they run @365 86.9 GH after 20h
...can not find curses.h or ...../mips-openwrt-linux-uclibc/bin/ld: cannot find -lcurl
My 2 avalons sitting at 355/352. Temps 35/41 and 35/39
--avalon-temp 40
With strombom firmware they run @365 86.9 GH after 20h
With strombom they run your fans at 100%. You can achieve the same fanspeed with my firmware by using --avalon-temp 0--avalon-temp 40
With strombom firmware they run @365 86.9 GH after 20h
[timeout] => 33
[frequency] => 354
I think the timeout is to low. With 365 i had to change timeout to 36 to avoid restarts.
36 will be generating dupes. Check your rejects [frequency] => 354
I think the timeout is to low. With 365 i had to change timeout to 36 to avoid restarts.
which one do i want to get?
the platinum one if you care about energy consumption
and think about this
http://www.amazon.co.uk/Corsair-Series-Platinum-CP-9020044-UK-Warranty/dp/B00AO0YRMI/ref=sr_1_1?s=computers&ie=UTF8&qid=1372177927&sr=1-1&keywords=corsair+860
has more reserve
just spotted this one..... i presume it is better
http://www.amazon.co.uk/Corsair-Professional-Digital-Modular-Platinum/dp/B00A74X9T8/ref=sr_1_2?ie=UTF8&qid=1372178161&sr=8-2&keywords=corsair+750w+platinum
EDIT: http://www.amazon.co.uk/Seasonic-X-750-module-ATX12V-Supply/dp/B002VAFDQS/ref=sr_1_1?ie=UTF8&qid=1372178289&sr=8-1&keywords=seasonic+gold+750w
or the above?
In the current heat wave where I am, my Avalon is pulling about 780 watts from the wall. I'd go with something bigger than 750 watts.
yeah i ordered some 860 platinum
Jump to: