Avalon ASIC users thread

[GenTarkin]

is there any module being obstructed by the power / data cables going from it to fpga? I noticed my top 2 modules had this issue right behind the fans that blew on them, those cables were blocking like 20% of the airflow... moving them to the side of the modules freed up this blocked air ... causing drop in temps for the lower module & probably the middle one.

[1714003849]

1714003849

[1714003849]

1714003849

[1714003849]

1714003849

[1714003849]

1714003849

[psjw4450]

is there any module being obstructed by the power / data cables going from it to fpga? I noticed my top 2 modules had this issue right behind the fans that blew on them, those cables were blocking like 20% of the airflow... moving them to the side of the modules freed up this blocked air ... causing drop in temps for the lower module & probably the middle one.

Opened it up, checked it and looked good.  Is it possible they might have forgotten some thermal compound somewhere and sensors aren't reading correct.

[ProfMac]

is there any module being obstructed by the power / data cables going from it to fpga? I noticed my top 2 modules had this issue right behind the fans that blew on them, those cables were blocking like 20% of the airflow... moving them to the side of the modules freed up this blocked air ... causing drop in temps for the lower module & probably the middle one.

Opened it up, checked it and looked good.  Is it possible they might have forgotten some thermal compound somewhere and sensors aren't reading correct.

In the cgminer stats log, does any value for the match_work_count stand out?

[mgio]

I get a REALLY large number of invalid shares with my Avalon.

I'm not sure whats going on. It's not consistent.

One day I'll be mining and I'll get 99+% valid shares and the next day or two it will only be 88% valid shares.

I've tried mining on Ozcoin and 50btc and it seems to be bad on both.

I don't think it is my network because my jalapenos only get <1% invalid shares.

I'm using the dynamically adjusting frequency and it usually settle at about 352 MHz or so and 82 GH/s on average. Of course, according to the pool, I'm only getting 70 GH/s or so due to all the invalid shares.

I have an AC feeding directly into the intake on the Avalon and no temperature gets above 48 or 49 or so (very rarely 50).

What could be wrong?

This is normal on stratum. Every time the block changes, you get invalids. Some days burn more blocks than others.

It seems like I have way more than other Avalon users, at least from what I've seen on Ozcoin. Most of them have only a couple percent invalid shares at most, while I will have 12 or 13% invalid shares. Right now I'm standing at about 94% efficiency on average, that's with 400,000 invalid shares in the less than a week I've been mining there.

That is definitely far more than you should be getting. There is a good chance you're submitting heaps of duplicates which may also be a different form of instability that the auto mode can't check for. Try setting a lower maximum speed if you're using auto mode because clearly you're not doing 82GH of useful work.

I also have 11% of rejected shares while HW is ~1.3%
Max temp is 48 C, ambient 28 C.
My command line is: --quiet --avalon-auto --avalon-freq 282-375 --avalon-cutoff 60

Last night it somehow stopped dumping rejected shares and so was till today, then I've caught blackout. After resuming it still generates 11% reject shares working at 352 MHz (autotuned).

It's odd in that it will run for a day or two and get 99.5% efficiency (about 0.5% rejected shares) and then all of a sudden (might coincide with a new round) it will start getting 10+% rejected shares for a day. I tried hard rebooting that when it happens and I'm hoping that might fix it.

I'm also going to play around with different clocks and see if that helps. It usually settles about 352 with max temps at around 49. It's strange that it can run like that for a day before the invalid shares start though. I've determined it is not likely to be my network as my 2 jalapenos only get <0.5% invalid shares.

[psjw4450]

is there any module being obstructed by the power / data cables going from it to fpga? I noticed my top 2 modules had this issue right behind the fans that blew on them, those cables were blocking like 20% of the airflow... moving them to the side of the modules freed up this blocked air ... causing drop in temps for the lower module & probably the middle one.

Opened it up, checked it and looked good.  Is it possible they might have forgotten some thermal compound somewhere and sensors aren't reading correct.

In the cgminer stats log, does any value for the match_work_count stand out?

When the ac is on it keeping the temps under 41 the match_work values are pretty similar.  Once I pull the ac off and the temp climbs above 41 their is a big difference in values from one to another.

[mgio]

So I attempted to upgrade the power supply on my 3-board Avalon...

It had a 750w Corsair in it already so I don't think it actually needed to be upgraded unless I decided to add a 4th board. I was getting a lot of invalid shares, though, so I figured a bigger power supply might help.

I bought a 850w OCZ ZW power supply and installed it and it didn't work! I'm not sure what was wrong. I could connect to the Avalon through the web interface, log in, and edit the configuration but the fans never spun up and it never started hashing.

I thought maybe I had broken it but I put the old power supply back in and it was fine.

I thought maybe I was missing a cable or something but I guess I just had a defective supply?

I plugged in:

The very wide main connector
The 8 pin connector that said "CPU" on it
The two red cables (GPU) that plug into the side of the supply.

The supply also had an additional connector, 8-pin but a different layout from the CPU power, I believe that looks like it would fit into another connector across from the CPU connector. It wasn't plugged in with the old power supply, so i didn't plug it in for the new one. Not sure what its for. Power supplies were always a mystery to me.

I wish there was a schematic or something that explained it. I haven't been able to find one for the Avalon miner.

PS Damn the Chinese engineer who designed the screws on that case!

[ProfMac]

is there any module being obstructed by the power / data cables going from it to fpga? I noticed my top 2 modules had this issue right behind the fans that blew on them, those cables were blocking like 20% of the airflow... moving them to the side of the modules freed up this blocked air ... causing drop in temps for the lower module & probably the middle one.

Opened it up, checked it and looked good.  Is it possible they might have forgotten some thermal compound somewhere and sensors aren't reading correct.

In the cgminer stats log, does any value for the match_work_count stand out?

When the ac is on it keeping the temps under 41 the match_work values are pretty similar.  Once I pull the ac off and the temp climbs above 41 their is a big difference in values from one to another.

I assume that each of the 24 numbers corresponds to a card of 10 chips, and that swapping the worst one out will be beneficial.

[WinTame2012]

That is definitely far more than you should be getting. There is a good chance you're submitting heaps of duplicates which may also be a different form of instability that the auto mode can't check for. Try setting a lower maximum speed if you're using auto mode because clearly you're not doing 82GH of useful work.

I also have 11% of rejected shares while HW is ~1.3%
Max temp is 48 C, ambient 28 C.
My command line is: --quiet --avalon-auto --avalon-freq 282-375 --avalon-cutoff 60

Last night it somehow stopped dumping rejected shares and so was till today, then I've caught blackout. After resuming it still generates 11% reject shares working at 352 MHz (autotuned).

Like I said, try setting a lower maximum.

Seems I found what cause this strange behavior. Maximum speed is nothing to do with it 'cause it's never reached.

In my case 11% rejects caused  by the auto-tuning process itself. As cgminer starts climbing from 282 to its stable 350 it dumps rejects all the way up Once it settles at the 350-352 - rejects immediately stops to grow.
Now my workaround for this (till you'll have a chance to investigate it) is just set --avalon-freq 340-375. It quickly climbs this 10-12 MHz up and the rejects % is just fine.

P.S. I use http://mmpool.bitparking.com just in case you'd try to reproduce it on your side. But it also the same picture with the Slush's pool.

[crazyearner]

Anyone know what this is

[   11.730000] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
[   15.030000] device eth0 entered promiscuous mode
[   15.380000] eth0: link up (100Mbps/Full duplex)

[   15.380000] br-lan: port 1(eth0) entered forwarding state
[   15.390000] br-lan: port 1(eth0) entered forwarding state
[   17.390000] br-lan: port 1(eth0) entered forwarding state

[   24.990000] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[   25.010000] ftdi_sio 1-1.1:1.0: device disconnected

Now wont connect up?

[luffy]

anyone succeded of connecting another device in the USB hub of the Avalon (like a jalapeno or usb erupter)
and start hashing with it via Avalon's cgminer?

[loshia]

anyone succeded of connecting another device in the USB hub of the Avalon (like a jalapeno or usb erupter)
and start hashing with it via Avalon's cgminer?

Yes you will succeed but you need to recompile the image with new cgmminer with support to both your avalon and your second device

[loshia]

Anyone know what this is

[   11.730000] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
[   15.030000] device eth0 entered promiscuous mode
[   15.380000] eth0: link up (100Mbps/Full duplex)

[   15.380000] br-lan: port 1(eth0) entered forwarding state
[   15.390000] br-lan: port 1(eth0) entered forwarding state
[   17.390000] br-lan: port 1(eth0) entered forwarding state

[   24.990000] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[   25.010000] ftdi_sio 1-1.1:1.0: device disconnected

Now wont connect up?

Yes it is called hotplug
Take it easy just to avoid this message comment ftdi and usb serial in /etc/modules

[bennybong]

So I attempted to upgrade the power supply on my 3-board Avalon...

It had a 750w Corsair in it already so I don't think it actually needed to be upgraded unless I decided to add a 4th board. I was getting a lot of invalid shares, though, so I figured a bigger power supply might help.

I bought a 850w OCZ ZW power supply and installed it and it didn't work! I'm not sure what was wrong. I could connect to the Avalon through the web interface, log in, and edit the configuration but the fans never spun up and it never started hashing.

I thought maybe I had broken it but I put the old power supply back in and it was fine.

I thought maybe I was missing a cable or something but I guess I just had a defective supply?

I plugged in:

The very wide main connector
The 8 pin connector that said "CPU" on it
The two red cables (GPU) that plug into the side of the supply.

The supply also had an additional connector, 8-pin but a different layout from the CPU power, I believe that looks like it would fit into another connector across from the CPU connector. It wasn't plugged in with the old power supply, so i didn't plug it in for the new one. Not sure what its for. Power supplies were always a mystery to me.

I wish there was a schematic or something that explained it. I haven't been able to find one for the Avalon miner.

PS Damn the Chinese engineer who designed the screws on that case!

Same problem with my OCZ ZX 850w 

No idea what is causing it.

[SolarSilver]

Same problem with my OCZ ZX 850w 

No idea what is causing it.

My OCZ ZX 1250 worked fine just direct out of the box (well, the old GPU miner I salvaged it from)

No idea what could be your problem though

Do you have an alternative power supply to try?

[mdbssm]

I am in Slush's pool and I noticed they found a block in 9 seconds (247343).  The stats say I got 0 shares.  What is the issue?  Why would the Avalons not be able to submit valid shares while others in the pool were able to do so? 

Perhaps share difficulty. If you are submitting every 15 seconds you might have missed the window.

[tronic1704]

Have same Problem with block in 9 seconds (247343).  The stats say I got 0 shares. That´s not correctly. I´m balance mining at 2 different pools. My Setting at slush´s pool is 32@42GH/s.

[-ck]

Avalons have an inefficiency with changing work, so that even if you were to receive the block change notification immediately (and there is in reality always going to be a delay), if the avalons were just loaded with new work, you'd have to wait about 2 seconds before you could load new work on them. At max overclock of 82GHash and a target diff of 64, you'll be generating less than 18 shares per minute. That's one every 3.3 seconds. So there are maybe 5 seconds where you may not get a share in on average over a block change. Now bear in mind share return is a stochastic process which means they won't come in perfectly every 3.3 seconds. Throw in some network delay from slush propagating the block change and it's easily possible for you to miss submitting a share during a 9 second block.

I can't comment on how quickly slush propagates the block change, but if there's a delay there that could be improved upon, and there's that huge design crapulence in the Avalon that you are also suffering from. It is much more of a hindrance on p2pool which had 10 second blocks but now has 30 second blocks. There's still a penalty (of about 1/30) and it's not p2pool's fault, but the Avalon's FPGA design.

[stfnnn]

i'm sure people will eventually need it when a fan or two goes out

My first goal was to install more powerful 252CFN fans as ambient temperatures now over +30c.
Also overclocked it to 360Mhz, hw errors near 1.6% 1.7%. Temperatures now like 32 / 48 with new fans even not running at full! To be exact, the model is TFC1212DE-SP07 and it's used in HP DL580 servers.

So I did a little experiment and partly covered the intake of fan3.
Result ? Better cooling and higher Mhz!

I also just covered fan hole and unplugged it to prevent air go back.

Are there other people here who tried some of those inverted pwm fans? I've installed 3 TFC1212DE, flashed the modified 20130714 firmware with inverted pwm support  and set the --avalon-invert-pwm option. But for some reason the fans do not seem to speed up when the temp is getting up. The fan RPM stays stable at around 2580 RPM, and my temp2 and temp3 sensors are 60C.

Any ideas why my fans don't run any harder when the temp is getting up? According to specs fans are 5500 rpm. When I only connect +12V and ground fans spins at 4800RPM, so they can spin harder dan this 2580 rpm.

Also option  --avalon-fan 100 does not seem to work.

[ProfMac]

Last night I set --avalon-temp 45 on my unit and let it mine for a few hours.  The hash rate slowed down, so I set it back to 50.

My idea was, a lower temperature setting would make the fans run faster, and the extra cooling would let the unit hash faster.

Perhaps starting at 48 would have worked better.

http://eligius.st/~wizkid057/newstats/userstats.php/18bLcVkviErQi75zB8X39jZXxHNpSZggdC

[-ck]

Last night I set --avalon-temp 45 on my unit and let it mine for a few hours.  The hash rate slowed down, so I set it back to 50.

My idea was, a lower temperature setting would make the fans run faster, and the extra cooling would let the unit hash faster.

Perhaps starting at 48 would have worked better.

http://eligius.st/~wizkid057/newstats/userstats.php/18bLcVkviErQi75zB8X39jZXxHNpSZggdC

It would have had trouble keeping it under 45 so it would have throttled the speed to try to do so... If you want the fans to constantly run higher, just set the fanspeed instead.