Avalon ASIC users thread

[gyverlb]

...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"?

I'm not trying to humiliate you. I'm asking if you have a valid use for the figure. Whether it changes your mining in any way?

The %age isn't really useful because it's an average over the whole cgminer process lifetime (recent changes won't be detected by looking at it on a long-lived cgminer process). If you restart cgminer on a regular basis, it becomes useful as any large variation is cause for concern and might warrant opening a case, inspecting and maybe resetting, reapplying thermal grease, repairing...

I suspect that what SolarSilver would like is a %age of recent hardware errors (over the last 10000 diff1 shares for good precision maybe). SolarSilver, you might want to look at Zabbix and how to use "differential" items to compute this kind of probe.

[SolarSilver]

I suspect that what SolarSilver would like is a %age of recent hardware errors (over the last 10000 diff1 shares for good precision maybe). SolarSilver, you might want to look at Zabbix and how to use "differential" items to compute this kind of probe.

Ah yes, finally somebody who can read minds ;-) Spot on and thank you for the explanation.

[-ck]

The --avalon-auto option already does precisely that: it uses a rolling average to adjust frequency rather than an all time average.

[SolarSilver]

The --avalon-auto option already does precisely that: it uses a rolling average to adjust frequency rather than an all time average.

Yes and it would be nice if one could pull the current % value out of the cgminer process and display it on the stats page (which is what Ben is trying to accomplish)

[ProfMac]

I flashed with 2013-08-10 yesterday, and my hashrate appears to have dropped.  I was using 2013-07-03 earlier.

[-ck]

I flashed with 2013-08-10 yesterday, and my hashrate appears to have dropped.  I was using 2013-07-03 earlier.

Yes there's a small regression in the auto code, I'm working on it now.

great:)

Here's updated firmware:

http://ck.kolivas.org/apps/cgminer/avalon/20130813-1/

[2weiX]

2x 4 module with 1250W PSU and firmware 20130723.

I'm using --avalon-auto --avalon-fan 90-100 and Chip Frequency: 350M, MHS5s shows ~105000 for both.


Questions:

1) Is there a way to determine if the chips are really hashing and not just producing what I know as "Hardware Errors"?

2) One of the machines only shows a number under "Fan3", the other one under "Fan1" and "Fan3". Need I be worried?

[weirdgod]

I am using WIFI...
Today (after 3 days of not checking the unit), i found it with LOAD of over 18, and hashing at 5xxx MH only...
I did a cgminer restart in system-services and hash rates returned to normal... (90.000MH), but load stayed over 15 ...
any ideas?

i checked kernel log, and looks normal until approx 3,5day into operation when bunch of entries like these show:
[316582.730000] usb 1-1: clear tt 1 (9031) error -71
[316584.160000] usb 1-1: clear tt 1 (8030) error -71
[316584.180000] usb 1-1: clear tt 1 (8030) error -71
[316584.190000] usb 1-1: clear tt 1 (8030) error -71
[316584.200000] usb 1-1: clear tt 1 (0030) error -71
[316589.840000] usb 1-1: clear tt 1 (8030) error -71
[316589.850000] usb 1-1: clear tt 1 (8030) error -71
[316589.860000] usb 1-1: clear tt 1 (8030) error -71
...
..
16824.590000] usb 1-1: clear tt 1 (8030) error -71
[316824.620000] usb 1-1: clear tt 1 (0030) error -71
[316828.000000] usb 1-1.1: USB disconnect, device number 3
[316828.150000] usb 1-1: reset high-speed USB device number 2 using ehci-platform
[316828.630000] usb 1-1.1: new full-speed USB device number 4 using ehci-platform
[316828.810000] ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected
[316828.850000] usb 1-1.1: Detected FT232RL
[316828.850000] usb 1-1.1: Number of endpoints 2
[316828.850000] usb 1-1.1: Endpoint 1 MaxPacketSize 16384
[316828.860000] usb 1-1.1: Endpoint 2 MaxPacketSize 16384
[316828.860000] usb 1-1.1: Setting MaxPacketSize 64
[316828.870000] usb 1-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
[316830.890000] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[316830.900000] ftdi_sio 1-1.1:1.0: device disconnected

I notice that sometimes the total MHS5s hashrate drops to weird low number (like 4 digits only)... is this normal?

No.

If you are using an ethernet connection, you must delete the WWAN device from the 'network' interfaces, and under network/wifi/avalon_ap make sure it shows 'wireless network is disabled'. Until I did both of these step I had the same problem.

Since this describes my problem, i tried this link below, but its not working no more?
ideas?

thanks,
Jaka

One of my batch 3 avalons is performing very poorly due to a high HW errors.  Unplugging all by one module, each module individually has between a 25 and 75% HW error rate at either 256 or 300Mhz.

This degraded performance starting after about 6 hours of mining at 300Mhz.

Is there anything I should try before trying to make a warranty claim?

I was calculating the hardware error rate wrong.  It should be HW/LocalWork, which brings the error rates i'm seeing to a much more reasonable 1%.

Regardless, 3 out of 4 of my batch 3 units end up with <10Gh/s after 3-12hrs of mining, some more frequently than others.

Could this behavior be due to the new temperature throttling feature?  I have the default temperature limits of 70C target and 90C cutoff, but I don't see the temps going over 70C.

I'm having this same issue.

EDIT: so is the solution is to disable wifi or to implement the load monitor with auto-restart? Is this issue resolved?

For me, disabling/removing wifi/wlan wasn't enough.

If you already removed wifi and it's still a problem, look at your load avg, if it's spiking, then you probably need the auto-restart I posted at https://bitcointalk.org/index.phptopic=140539.msg2898478#msg2898478

If the load avg is low (under 1.0) then you should check all the connectors inside your avalon.  I did have one of the wide ribbon cables wiggle loose (I probably bumped it installing the psu) and the result was about 20%+ lower peak hashes and odd hangups.

[sahkan]

Have you seen this wiki post:

 About [usb 1-1: clear tt 1 (8030) error -71]

Not all 703n have this problem. ignore this section if you never meet this error

    There is a power issue with the 703N, The 703N is drawing to much power it caused the USB HUB chip on Senseless's FPGA controller to nearly destroy itself. See the destruction [ http://www.mysenselesslife.com/avalon/DSCN5212.JPG here]

    In order to fix it you need had to power down the WiFi modem by disable it, use Eithernet instead. The kernel no long report -71 errors. thanks to senseless and others who help on identify the issue.

    If your avalon was far away from your router. eithernet cable not fit. you may want try those kind of devices
        TP-LINK TL-PA500(For mainland China) : http://www.tp-link.com.cn/product_adapter_263.html
        TP-LINK TL-PA511 : http://www.tp-link.com/en/products/details/?model=TL-PA511

[GandalfG]

2x 4 module with 1250W PSU and firmware 20130723.

I'm using --avalon-auto --avalon-fan 90-100 and Chip Frequency: 350M, MHS5s shows ~105000 for both.


Questions:

1) Is there a way to determine if the chips are really hashing and not just producing what I know as "Hardware Errors"?

2) One of the machines only shows a number under "Fan3", the other one under "Fan1" and "Fan3". Need I be worried?

2weiX thx for ask for that.

Is it possible to perform  tests which will determine which chip in the chain is  generates errors/are broken?
Usually chains contain 10 chips (Avalon and Burnin BB)
Any one can write some procedure which will return the test result of individual chips ?

[ProfMac]

Has anyone produced a graph of clock frequency vs wall power on a batch #2 unit?

I have a GX 850 power supply, and I have mixed messages whether it is enough to power a 4 module unit clocked at 347 MHz.

[jermwerty]

Has anyone produced a graph of clock frequency vs wall power on a batch #2 unit?

I have a GX 850 power supply, and I have mixed messages whether it is enough to power a 4 module unit clocked at 347 MHz.

I wouldn't even dare.

4 module B3 stock @300mhz draws ~850W from the wall.  Load a PSU @ 100% 24/7 is asking for a bad time!

[PsychoticBoy]

I used firmware 20130703 before upgrading to 20130813-1, I get more HW errors and the chips are clocked to 346mhz instead of the normal 350-355mhz.
It is a batch2 avalon.

What could be the case?

[ProfMac]

I used firmware 20130703 before upgrading to 20130813-1, I get more HW errors and the chips are clocked to 346mhz instead of the normal 350-355mhz.
It is a batch2 avalon.

What could be the case?

I have updated from 20130703, to 20130810 for a few hours, then to 20130810-1 most of today.  I will let it run overnight, but I seem to see a decrease also.

[-ck]

2x 4 module with 1250W PSU and firmware 20130723.

I'm using --avalon-auto --avalon-fan 90-100 and Chip Frequency: 350M, MHS5s shows ~105000 for both.


Questions:

1) Is there a way to determine if the chips are really hashing and not just producing what I know as "Hardware Errors"?

2) One of the machines only shows a number under "Fan3", the other one under "Fan1" and "Fan3". Need I be worried?

1. Hashrate is only calculated from non-HW errors on the avalon driver
2. No

[CoinHoarder]

Has anyone produced a graph of clock frequency vs wall power on a batch #2 unit?

I have a GX 850 power supply, and I have mixed messages whether it is enough to power a 4 module unit clocked at 347 MHz.

Although I was advised against this, I've had all 7 four module Avalons running at 350mhz with Avalon's stock 850w PSU running stable for exactly 2 weeks now. I did have one PSU die the first day, but I have had no problems with the others. I just replaced the PSU and she was back to hashing within minutes. I assume you would have to be incredibly unlucky for a blown PSU to damage the Avalon's components. In all my years (aka. 1 year  ) of GPU mining, never has a blown PSU caused any extra hardware failure (again, in my experience... your mileage may vary.)

As we used to say when I was a snowboard bum in Colorado for a few years after graduating high school, "go big or home." (then proceed to pee your pants while hucking a 50 ft cliff)  

[thejestre]

Hi all,

Just saw the new firmware 20130813-1 and thought I'd upgrade from 20130703, which was giving me ~78Gh/s on my batch 2 Avalon.  I was using just --avalon-auto to achieve this.

I'm getting less Gh/s now, probably about 72 or so.  I'm using these options:

--avalon-auto --avalon-cutoff 80 --avalon-freq 300-360 --avalon-temp 70

Am I doing something wrong, do these numbers look completely off base?

Should batch 2 Avalons just stick to the 20130703 firmware?

Thanks,

_theJestre

[-ck]

Hi all,

Just saw the new firmware 20130813-1 and thought I'd upgrade from 20130703, which was giving me ~78Gh/s on my batch 2 Avalon.  I was using just --avalon-auto to achieve this.

I'm getting less Gh/s now, probably about 72 or so.  I'm using these options:

--avalon-auto --avalon-cutoff 80 --avalon-freq 300-360 --avalon-temp 70

Am I doing something wrong, do these numbers look completely off base?

Should batch 2 Avalons just stick to the 20130703 firmware?

Thanks,

_theJestre

Interesting. I uploaded a 20130814 (which is basically the same as the 20130813-1 firmware, just with the cgminer 3.3.4 tag). What I've found with the changed code is that my (batch2) avalon hovers at a lower frequency of 345 instead of 352, but ends up with the same hashrate. If there was something I'd recommend for you on batch 2, it is NOT setting your temperature so high. That is almost certainly contributing to your hardware errors and may damage your chips. If you really want to run them high, I'd suggest 60/70 instead of 70/80, but the defaults are there for a reason.

[thejestre]

--avalon-auto --avalon-cutoff 80 --avalon-freq 300-360 --avalon-temp 70

Interesting. I uploaded a 20130814 (which is basically the same as the 20130813-1 firmware, just with the cgminer 3.3.4 tag). What I've found with the changed code is that my (batch2) avalon hovers at a lower frequency of 345 instead of 352, but ends up with the same hashrate. If there was something I'd recommend for you on batch 2, it is NOT setting your temperature so high. That is almost certainly contributing to your hardware errors and may damage your chips. If you really want to run them high, I'd suggest 60/70 instead of 70/80, but the defaults are there for a reason.

Maybe I misunderstood something I read earlier, I'm a bit confused with the different batches wanting different temperatures.

I thought with the new firmware that "70 was the new 50" for Batch 2 Avalons.  Did I get that totally wrong?

Thanks,

_theJestre

[-ck]

Maybe I misunderstood something I read earlier, I'm a bit confused with the different batches wanting different temperatures.

I thought with the new firmware that "70 was the new 50" for Batch 2 Avalons.  Did I get that totally wrong?

For batch 3 Avalons, so yes you got it wrong. Remove those lines ASAP.