What's your hashrate?
Topic: Avalon ASIC users thread - page 96. (Read 438596 times)
anyone tried replacing the thermal paste between the chips and the heatsink?
or adding thermal paste between the heatsink and the casing (where the heatsinks are mounted onto the case) ?
I am or adding thermal paste between the heatsink and the casing (where the heatsinks are mounted onto the case) ?
So what did u do? Replace thermal paste or put thermal paste between hs and case?
What kind of thermal paste did use? Non conductive?
Just watch the freq carefully when using --avalon-auto. New firmware is much more aggressive in overclocking.
After 1.5 hrs on a B3 4M unit with stock PSU, the HW error rate started climbing rapidly while running @360 MHz (6%+ error rate over the runtime, up from 1.7% minutes earlier). Clock speed was not ramping to down to compensate.
Now using --avalon-freq 345-355 to see if that prevents a runaway.
And before anyone says it, yes that unit is getting a PSU swap later this weekend.
After 1.5 hrs on a B3 4M unit with stock PSU, the HW error rate started climbing rapidly while running @360 MHz (6%+ error rate over the runtime, up from 1.7% minutes earlier). Clock speed was not ramping to down to compensate.
Now using --avalon-freq 345-355 to see if that prevents a runaway.
And before anyone says it, yes that unit is getting a PSU swap later this weekend.
What's your hashrate?
anyone tried replacing the thermal paste between the chips and the heatsink?
or adding thermal paste between the heatsink and the casing (where the heatsinks are mounted onto the case) ?
I am or adding thermal paste between the heatsink and the casing (where the heatsinks are mounted onto the case) ?
So what did u do? Replace thermal paste or put thermal paste between hs and case?
What kind of thermal paste did use? Non conductive?
Just watch the freq carefully when using --avalon-auto. New firmware is much more aggressive in overclocking.
After 1.5 hrs on a B3 4M unit with stock PSU, the HW error rate started climbing rapidly while running @360 MHz (6%+ error rate over the runtime, up from 1.7% minutes earlier). Clock speed was not ramping to down to compensate.
Now using --avalon-freq 345-355 to see if that prevents a runaway.
And before anyone says it, yes that unit is getting a PSU swap later this weekend.
we'll see. my power supply already replaced.After 1.5 hrs on a B3 4M unit with stock PSU, the HW error rate started climbing rapidly while running @360 MHz (6%+ error rate over the runtime, up from 1.7% minutes earlier). Clock speed was not ramping to down to compensate.
Now using --avalon-freq 345-355 to see if that prevents a runaway.
And before anyone says it, yes that unit is getting a PSU swap later this weekend.
My other B3 unit with an external 1200w PSU is behaving fine.
Just watch the freq carefully when using --avalon-auto. New firmware is much more aggressive in overclocking.
After 1.5 hrs on a B3 4M unit with stock PSU, the HW error rate started climbing rapidly while running @360 MHz (6%+ error rate over the runtime, up from 1.7% minutes earlier). Clock speed was not ramping to down to compensate.
Now using --avalon-freq 345-355 to see if that prevents a runaway.
And before anyone says it, yes that unit is getting a PSU swap later this weekend.
we'll see. my power supply already replaced. After 1.5 hrs on a B3 4M unit with stock PSU, the HW error rate started climbing rapidly while running @360 MHz (6%+ error rate over the runtime, up from 1.7% minutes earlier). Clock speed was not ramping to down to compensate.
Now using --avalon-freq 345-355 to see if that prevents a runaway.
And before anyone says it, yes that unit is getting a PSU swap later this weekend.
anyone tried replacing the thermal paste between the chips and the heatsink?
or adding thermal paste between the heatsink and the casing (where the heatsinks are mounted onto the case) ?
I am or adding thermal paste between the heatsink and the casing (where the heatsinks are mounted onto the case) ?
Just watch the freq carefully when using --avalon-auto. New firmware is much more aggressive in overclocking.
After 1.5 hrs on a B3 4M unit with stock PSU, the HW error rate started climbing rapidly while running @360 MHz (6%+ error rate over the runtime, up from 1.7% minutes earlier). Clock speed was not ramping to down to compensate.
Now using --avalon-freq 345-355 to see if that prevents a runaway.
And before anyone says it, yes that unit is getting a PSU swap later this weekend.
After 1.5 hrs on a B3 4M unit with stock PSU, the HW error rate started climbing rapidly while running @360 MHz (6%+ error rate over the runtime, up from 1.7% minutes earlier). Clock speed was not ramping to down to compensate.
Now using --avalon-freq 345-355 to see if that prevents a runaway.
And before anyone says it, yes that unit is getting a PSU swap later this weekend.
anyone tried replacing the thermal paste between the chips and the heatsink?
or adding thermal paste between the heatsink and the casing (where the heatsinks are mounted onto the case) ?
or adding thermal paste between the heatsink and the casing (where the heatsinks are mounted onto the case) ?
looks like the new firmware is super, but the flashing orange LED annoying. Is this normal?
I also did a crazy remote session;) upload speed at actual place is to slow, so I always got a timeout. so I got a teamviewer session to an other remote place with faster internet connection and did the fw upload over this connection
hitting 360 MHz after few minutes - very nice! with 20130703 it was toggeling in the range of 354-358
will see if this is going on;)
set --avalon-fan 70-100 but the fans stayed at around 800rpm until it was over target temp -> then speeding up
can anyone confirm this behavior?
hitting 360 MHz after few minutes - very nice! with 20130703 it was toggeling in the range of 354-358
will see if this is going on;)
set --avalon-fan 70-100 but the fans stayed at around 800rpm until it was over target temp -> then speeding up
can anyone confirm this behavior?
New firmware:
http://ck.kolivas.org/apps/cgminer/avalon/20130818/
Higher hashrate with avalon-auto.
You can now use d for timeout instead of a number in avalon-options when manually configuring to allow cgminer to automatically determine the optimal timeout.
http://ck.kolivas.org/apps/cgminer/avalon/20130818/
Higher hashrate with avalon-auto.
You can now use d for timeout instead of a number in avalon-options when manually configuring to allow cgminer to automatically determine the optimal timeout.
I flashed 20130818 to an Avalon batch #2 at 11:20 CDT and kept the old settings. I did not power off the system. It has been running 58 minutes.
The Avalon now is at 350 MHz, up from it's typical 343-347 MHz. Both temp2 and temp3 are at 50°C, temp1 is 22°C, the basement is 60°F. This is hotter for temp2. The fans are turning significantly faster, and they seem to change speeds frequently.
I think it is too soon to interpret the eligius statistics. However, the preliminary impression is that variance is lower.
The orange led is flashing on and off at about 1 Hz. I have never seen this behavior before. I am curious what it means.
Interesting. My temps are essentially unchanged, ambient 21-22c as well.
Can't comment on LED appearance as I'm remote from my equipment at the moment.
New firmware:
http://ck.kolivas.org/apps/cgminer/avalon/20130818/
Higher hashrate with avalon-auto.
You can now use d for timeout instead of a number in avalon-options when manually configuring to allow cgminer to automatically determine the optimal timeout.
http://ck.kolivas.org/apps/cgminer/avalon/20130818/
Higher hashrate with avalon-auto.
You can now use d for timeout instead of a number in avalon-options when manually configuring to allow cgminer to automatically determine the optimal timeout.
I flashed 20130818 to an Avalon batch #2 at 11:20 CDT and kept the old settings. I did not power off the system. It has been running 58 minutes.
The Avalon now is at 350 MHz, up from it's typical 343-347 MHz. Both temp2 and temp3 are at 50°C, temp1 is 22°C, the basement is 60°F. This is hotter for temp2. The fans are turning significantly faster, and they seem to change speeds frequently.
I think it is too soon to interpret the eligius statistics. However, the preliminary impression is that variance is lower.
The orange led is flashing on and off at about 1 Hz. I have never seen this behavior before. I am curious what it means.
Edit -->
I bet it can get better. Old config line:
--avalon-auto --avalon-freq 256-350 --avalon-temp 50
How should I incorporate the 'd' timeout option? I have the idea that --avalon-auto & --avalon-options don't always play nice together.
New firmware:
http://ck.kolivas.org/apps/cgminer/avalon/20130818/
Higher hashrate with avalon-auto.
You can now use d for timeout instead of a number in avalon-options when manually configuring to allow cgminer to automatically determine the optimal timeout.
http://ck.kolivas.org/apps/cgminer/avalon/20130818/
Higher hashrate with avalon-auto.
You can now use d for timeout instead of a number in avalon-options when manually configuring to allow cgminer to automatically determine the optimal timeout.
Initial impression (1hr runtime): excellent. Best firmware yet. Very low rejected shares.
batch2 3module: ~85GH/s @ 359-362 MHz
batch2 4module: ~111GH/s @ 352-359 MHz
Much appreciated.
New firmware:
http://ck.kolivas.org/apps/cgminer/avalon/20130818/
Higher hashrate with avalon-auto.
You can now use d for timeout instead of a number in avalon-options when manually configuring to allow cgminer to automatically determine the optimal timeout.
http://ck.kolivas.org/apps/cgminer/avalon/20130818/
Higher hashrate with avalon-auto.
You can now use d for timeout instead of a number in avalon-options when manually configuring to allow cgminer to automatically determine the optimal timeout.
does anyone use 4 modules with batch1 avalons?
i see the power board PDU is different than batch2 or 3 and i wonder if it is enough to power 4 modules.
i see the power board PDU is different than batch2 or 3 and i wonder if it is enough to power 4 modules.
me...
it's enough
PSU's the more important part.
does anyone use 4 modules with batch1 avalons?
i see the power board PDU is different than batch2 or 3 and i wonder if it is enough to power 4 modules.
i see the power board PDU is different than batch2 or 3 and i wonder if it is enough to power 4 modules.
Yes it works pretty well. I tested it and So did the bitcoin foundation. They received a batch1 with 4 modules.
does anyone use 4 modules with batch1 avalons?
i see the power board PDU is different than batch2 or 3 and i wonder if it is enough to power 4 modules.
i see the power board PDU is different than batch2 or 3 and i wonder if it is enough to power 4 modules.
If 50BTC is using a large coinbase, you might have been getting struck by the excessive CPU usage limitation in older firmware just like p2pool was. This might manifest as duplicate shares and only show up as rejects at your pool. Most of the recent updates were created to address precisely that problem. Try my latest firmware.
http://ck.kolivas.org/apps/cgminer/avalon/20130814/
Thank you, ckolivas. I'll consider to move to the new firmware as it gets mature. I just read the feedback that new FW are affected by the lower hashrate than 0703.http://ck.kolivas.org/apps/cgminer/avalon/20130814/
Actually I'm very happy with the 20130813 release and further, it's a lot more stable on 4 hash module Avalons.
Two of my machines always ended up hanging showing values '0' for hash rate, temperature and fan speed. I've always blamed this on the FPGA controler board in the past. All my other machines did not do this. Coincidence, the two problem machines were 4 module machines, the others have 3 modules.
I always had to cold restart them using the PDU and this made their average hash rate over a day much lower than sometimes a 3 module machine. Sometimes they would soft restart themselves but flipflop in and out of idling. Only cold restart really helps.
So far 4 or so days without any need for restart...
More testing is required before I draw conclusions but it seems the problem has been fixed.
Give the new release a try, the reported hash rate is cosmetic.
Moved from bitparking to 50btc and now I'm constantly getting a lot of Rejected shares at Diff8 
Does anybody have fixed issue like this?
Edit: FW both 20130703 and 20130723
Does anybody have fixed issue like this?
Edit: FW both 20130703 and 20130723
Change your diff to 64 on 50btc under settings for miner is probs why you getting too many rejected shares.
Going from 8diff to 64diff simply means your Reject share variance increases.
Coz on average you find 1/8 of the rejected shares ... but they are worth 8 times as much each.
If 50BTC is using a large coinbase, you might have been getting struck by the excessive CPU usage limitation in older firmware just like p2pool was. This might manifest as duplicate shares and only show up as rejects at your pool. Most of the recent updates were created to address precisely that problem. Try my latest firmware.
http://ck.kolivas.org/apps/cgminer/avalon/20130814/
Jump to: