Avalon ASIC users thread

[driksson]

Nope sorry for the confusion, I was just giving some details on my hardware setting, each Avalon is slightly different, I have also replaced the TIM with paste on each module to allow it to run cooler allowing me to run at 360 Mhz stable. From my testing the hashing indeed remains constant, however H/W increase over time e.g. over 48 hours without restart, after running for long periods I see 6 - 8% which is just wasted electricity, so a quick cgminer restart solves all this

My advice for your setup is to have cgminer restart every x amount of hours keeping H/W errors low, use whatever Mhz setting keeps your units hashing high as possible and stable. Hope this makes sense.

Thanks yes i understood that. super. I mean, the line you gave, maybe ill change it to every 20 hours, as it looks quite stable and high for even 70 hours.. but keeping a restart on a daily basis should be fine.
As for 360, maybe i will try 350, since they are in 20dgr ac room, but no hardware mods at all.

[smoothrunnings]

Nope sorry for the confusion, I was just giving some details on my hardware setting, each Avalon is slightly different, I have also replaced the TIM with paste on each module to allow it to run cooler allowing me to run at 360 Mhz stable. From my testing the hashing indeed remains constant, however H/W increase over time e.g. over 48 hours without restart, after running for long periods I see 6 - 8% which is just wasted electricity, so a quick cgminer restart solves all this

My advice for your setup is to have cgminer restart every x amount of hours keeping H/W errors low, use whatever Mhz setting keeps your units hashing high as possible and stable. Hope this makes sense.

Sorry for budding in here, but are you saying the HW on the status page is the errors? And when you mention keeping it low, what's the magic number?

Thanks

[driksson]

Nope sorry for the confusion, I was just giving some details on my hardware setting, each Avalon is slightly different, I have also replaced the TIM with paste on each module to allow it to run cooler allowing me to run at 360 Mhz stable. From my testing the hashing indeed remains constant, however H/W increase over time e.g. over 48 hours without restart, after running for long periods I see 6 - 8% which is just wasted electricity, so a quick cgminer restart solves all this

My advice for your setup is to have cgminer restart every x amount of hours keeping H/W errors low, use whatever Mhz setting keeps your units hashing high as possible and stable. Hope this makes sense.

Sorry for budding in here, but are you saying the HW on the status page is the errors? And when you mention keeping it low, what's the magic number?

Thanks

what i realised, was that my units was running (b2 3u) at 83-85gh for 3-4 days on eligius. then all of a sudden, they drop to 75-70gh.. for no real reason, hashrate seems same on machines, but hw rate increases. Basically, if you see 83gh on eligius or in your pool always, you don't have our problem. if you see it dropping, add reset script line.

[AdamKD]

If you have issues with hardware error rate add some solder around the buffers.  That fixes the HW error rate which is *usually* related to the buffers on the individual hash boards.

[natbyte]

Buffers? Care to share a picture of where you mean, thanks.

[GandalfG]

If you have issues with hardware error rate add some solder around the buffers.  That fixes the HW error rate which is *usually* related to the buffers on the individual hash boards.

There isn't buffers in original Avalon design. May you mean 74LVC2G34 on the signaling bus ? (Config_P/N ReportP/N)
But I never see bad solder on this parts.

[AdamKD]

If you have issues with hardware error rate add some solder around the buffers.  That fixes the HW error rate which is *usually* related to the buffers on the individual hash boards.

There isn't buffers in original Avalon design. May you mean 74LVC2G34 on the signaling bus ? (Config_P/N ReportP/N)
But I never see bad solder on this parts.

Those.  There's 3 of them (U13, U14, and U15) per hash board.  My friend and I've seen hundreds (if not thousands) of them under a solder rework microscope.  They all looked good from almost every angle.  Touching them up all of them usually fixed a HW error problem (Once we narrowed it down to the right hash board).  I'm not going to guarantee that it will fix a HW error problem.  I'm just going to state that there's a good probability that it will fix a HW error problem.

[ste0024]

Buffers? Care to share a picture of where you mean, thanks.

+100

[GandalfG]

If you have issues with hardware error rate add some solder around the buffers.  That fixes the HW error rate which is *usually* related to the buffers on the individual hash boards.

There isn't buffers in original Avalon design. May you mean 74LVC2G34 on the signaling bus ? (Config_P/N ReportP/N)
But I never see bad solder on this parts.

Those.  There's 3 of them (U13, U14, and U15) per hash board.  My friend and I've seen hundreds (if not thousands) of them under a solder rework microscope.  They all looked good from almost every angle.  Touching them up all of them usually fixed a HW error problem (Once we narrowed it down to the right hash board).  I'm not going to guarantee that it will fix a HW error problem.  I'm just going to state that there's a good probability that it will fix a HW error problem.

Thx for advice. I reflow all my boards and have 1.6% HW at 430MHz.
But observe interesting thing, HW percentage are depends from length and quality ribbon cable. Maybe in conjunction with solder quality on buffers ?

[smoothrunnings]

If you have issues with hardware error rate add some solder around the buffers.  That fixes the HW error rate which is *usually* related to the buffers on the individual hash boards.

There isn't buffers in original Avalon design. May you mean 74LVC2G34 on the signaling bus ? (Config_P/N ReportP/N)
But I never see bad solder on this parts.

Those.  There's 3 of them (U13, U14, and U15) per hash board.  My friend and I've seen hundreds (if not thousands) of them under a solder rework microscope.  They all looked good from almost every angle.  Touching them up all of them usually fixed a HW error problem (Once we narrowed it down to the right hash board).  I'm not going to guarantee that it will fix a HW error problem.  I'm just going to state that there's a good probability that it will fix a HW error problem.

Thx for advice. I reflow all my boards and have 1.6% HW at 430MHz.
But observe interesting thing, HW percentage are depends from length and quality ribbon cable. Maybe in conjunction with solder quality on buffers ?

If you think the HW errors has to do with the ribbon cable, have you tried replacing them with 80pin cables? Remember back in the old days when there was IDE which 40pin, you could get an 80pin cable (Ultra 100/133) that had a 40pin connector, maybe this would reduce the HW errors?

Also how are you determining the % HW at MHz?

[AdamKD]

If you have issues with hardware error rate add some solder around the buffers.  That fixes the HW error rate which is *usually* related to the buffers on the individual hash boards.

There isn't buffers in original Avalon design. May you mean 74LVC2G34 on the signaling bus ? (Config_P/N ReportP/N)
But I never see bad solder on this parts.

Those.  There's 3 of them (U13, U14, and U15) per hash board.  My friend and I've seen hundreds (if not thousands) of them under a solder rework microscope.  They all looked good from almost every angle.  Touching them up all of them usually fixed a HW error problem (Once we narrowed it down to the right hash board).  I'm not going to guarantee that it will fix a HW error problem.  I'm just going to state that there's a good probability that it will fix a HW error problem.

Thx for advice. I reflow all my boards and have 1.6% HW at 430MHz.
But observe interesting thing, HW percentage are depends from length and quality ribbon cable. Maybe in conjunction with solder quality on buffers ?

Most of our modules were in the .5% hardware error rate with some in the .1 and some in the .9 range @ 375 and 390 .  Didn't go higher due to power (375, for us, is ~1150 watts at wall for 4 modules) and cooling (low cfm fans) issues.

It could be a bunch of things.  Touching up the buffers consistently solved the problem for us - which is why I dropped the idea here.

[nox_]

Make sure your ribbon cables are tight to that module and make sure the backplane is snug into the hash boards.

Check the power cable for that module also, inspect the connectors on both ends for any evidence of heating due to poor connections.

If the cables are ok inspect the module for burnt capacitors in the defective miner sections.

If you have a meter you can compare the C1 voltage readings between miner sections.

C1 - 680uf - is also the capacitor that has been failing on some of the units.

A late reply, but better late than never, thanks for the advice it was a loose backplane.. I actually fixed it by turning the unit on the side (I have since seated it properly).

Another question from me :-)

I have added the fourth module into my batch #2 Avalon and upgraded the PSU to a OCZ 1250W.

Since adding the fourth module and running --Avalon-auto I get a fairly high HW error rate at 344 Mhz (>2.5 %) but dropping down to 319/320 gives me 1.5%.

However CGMiner is restarting itself every 6 - 9 hours.

Running firmware version '20130923'

Temp1 - 20
Temp2 - 48
Temp3 - 45

I've moved the PSU out of the case incase it was pushing too much hot air onto some chips but no difference.

Does anywhere know where I can see some logs of why CGMiner is crashing?

Thanks,

nox_

[nox_]

(Actually reading up some of the latest posts about ribbon cables causing HW errors might be the cause on the latest module)

Any advice appreciated, but I'll read back a few pages for some ideas too!

[smoothrunnings]

...however, what are you doing with that figure?

OK, at the risk of this being a trick question, I'm going to humiliate myself by saying "we display the value thus adding readability"?

How are you seeing the %? I am running the latest CK firmware and I don't see the % in my HW stats.

[Tigggger]

How are you seeing the %? I am running the latest CK firmware and I don't see the % in my HW stats.

https://bitcointalk.org/index.php?topic=254331.0

[SolarSilver]

How are you seeing the %? I am running the latest CK firmware and I don't see the % in my HW stats.

[smoothrunnings]

How are you seeing the %? I am running the latest CK firmware and I don't see the % in my HW stats.

https://bitcointalk.org/index.php?topic=254331.0

Thanks, now how do I save the changes in vi again? It's been years since I have touched Linux.

[el_rlee]

How are you seeing the %? I am running the latest CK firmware and I don't see the % in my HW stats.

https://bitcointalk.org/index.php?topic=254331.0

Thanks, now how do I save the changes in vi again? It's been years since I have touched Linux.

ESC-:-wq-ENTER

[smoothrunnings]

How are you seeing the %? I am running the latest CK firmware and I don't see the % in my HW stats.

https://bitcointalk.org/index.php?topic=254331.0

Thanks, now how do I save the changes in vi again? It's been years since I have touched Linux.

ESC-:-wq-ENTER

are the dashes dashes or spaces?

[smoothrunnings]

Wow my device hardware% is quite low, lower on my B1 than my B2.

B1



B2