Avalon ASIC users thread

[goxed]

Can anyone report what is maximum safe operating temperatures for Avalon?

There are three temperature values reported Temp1, Temp2, Temp3. What do these correspond to?
With the current weather and temperatures I wanted to know at what cutoff point should I downclock the avalon.

Also, what is the max safe junction temperature of avalon chips?

[1715316845]

1715316845

[1715316845]

1715316845

[mtbitcoin]

Anyone try the latest firmware?

Cheers

[loshia]

Anyone try the latest firmware?

Cheers

I did. Accourding to my testing 3.2 clocked at 300 is making about 68000 compared to 3.1 70500. 24 hours run. I downgraded to cgminer 3.1. I do not know what is the reason, but there is performance decrease.

Will Anyone else to share the cgminer 3.2 results?

[Kuma]

Anyone try the latest firmware?

Cheers

I did. Accourding to my testing 3.2 clocked at 300 is making about 68000 compared to 3.1 70500. 24 hours run. I downgraded to cgminer 3.1. I do not know what is the reason, but there is performance decrease.

Will Anyone else to share the cgminer 3.2 results?

Hi,
I noticed that too and asked CKolivas. He replied:

The old avalon code lied about the hashrate and lied about the hardware errors. It counted hardware errors as hashrate (and since it's a hardware error it can't be valid hashes that it's doing) and didn't count "no matching work" scenarios as hardware errors. So the new code will appear to have a lower hashrate and a higher hw error count, but in fact it's doing more useful work and just not lying about the rates (along with all the other benefits in the new code).

https://bitcointalk.org/index.php?topic=28402.msg2406402#msg2406402

[loshia]

Hi,
I noticed that too and asked CKolivas. He replied:

The old avalon code lied about the hashrate and lied about the hardware errors. It counted hardware errors as hashrate (and since it's a hardware error it can't be valid hashes that it's doing) and didn't count "no matching work" scenarios as hardware errors. So the new code will appear to have a lower hashrate and a higher hw error count, but in fact it's doing more useful work and just not lying about the rates (along with all the other benefits in the new code).

https://bitcointalk.org/index.php?topic=28402.msg2406402#msg2406402

With my deep respect to Con and Kano i can state following:

I calculate my ACTUAL hash rate as advised by Kano taking in account Diff1 shares accepted from pool(s) and cgminer up-time. This gives me EXACT (Real) hashrate. Knowing the fact my network was fine and i did not have downtime due to Network issues, pool issues or FPGA controller hangs (I am monitoring it every two minutes + automated power off/on no reboots) i am 100% sure that 3.2 is not performing. The magic can be this commit:

https://github.com/ckolivas/cgminer/commit/bd6bc6bd23424958ebf1d49f22d6a50070d13d23

Not tested yet. Avalon image was released before that

It may turn out that 24 Hours run is not enough because of the variance and/or bad luck - that is the only fact that makes me uncertain about 3.2 performance. I will give it another 48 hours run next weekend and i will report back the results. Mean while i will stick to 3.1

Best

PS: just for the reference (do math yourself)

Computer: cgminer 3.1.1
Elapsed: 7h 11m 30s
Difficulty Accepted:431530.00000000
MHS:71587.77

That was not happening with 3.2

[Kuma]

Hi,
I noticed that too and asked CKolivas. He replied:

The old avalon code lied about the hashrate and lied about the hardware errors. It counted hardware errors as hashrate (and since it's a hardware error it can't be valid hashes that it's doing) and didn't count "no matching work" scenarios as hardware errors. So the new code will appear to have a lower hashrate and a higher hw error count, but in fact it's doing more useful work and just not lying about the rates (along with all the other benefits in the new code).

https://bitcointalk.org/index.php?topic=28402.msg2406402#msg2406402

With my deep respect to Con and Kano i can state following:

I calculate my ACTUAL hash rate as advised by Kano taking in account Diff1 shares accepted from pool(s) and cgminer up-time. This gives me EXACT (Real) hashrate. Knowing the fact my network was fine and i did not have downtime due to Network issues, pool issues or FPGA controller hangs (I am monitoring it every two minutes + automated power off/on no reboots) i am 100% sure that 3.2 is not performing. The magic can be this commit:

https://github.com/ckolivas/cgminer/commit/bd6bc6bd23424958ebf1d49f22d6a50070d13d23

Not tested yet. Avalon image was released before that

It may turn out that 24 Hours run is not enough because of the variance and/or bad luck - that is the only fact that makes me uncertain about 3.2 performance. I will give it another 48 hours run next weekend and i will report back the results. Mean while i will stick to 3.1

Best

PS: just for the reference (do math yourself)

Computer: cgminer 3.1.1
Elapsed: 7h 11m 30s
Difficulty Accepted:431530.00000000
MHS:71587.77

That was not happening with 3.2

To be honest, I haven't tried to compute that and I don't have the old reference numbers. As new FW is rock stable for me, I haven't tried other things yet due the time restrictions  . Of course if performance can be better, I'll be glad  .

[loshia]

To be honest, I haven't tried to compute that and I don't have the old reference numbers. As new FW is rock stable for me, I haven't tried other things yet due the time restrictions  . Of course if performance can be better, I'll be glad  .

I do agree with you 3.1 still needs power off/on on occasions. This happens rare for sure but still happens. As long as i solved this from day one, 3 000 MHS do matter for me and i am sticking to 3.1
Let us wait for Con comments.

Best

 

[cypherdoc]

I removed the F1 fuses on my two Avalons this morning - It's surprisingly easy (DISCLAIMER - I'm not responsible for any issues), I just pinched off the fuses with my leatherman pliers.

All back up and running perfectly.

For anyone interested, after running for a week with the fuses, there was no noticeable damage to the chips on the control boards. However, it's still recommended to remove the fuses.

Aren't all current units arriving with this modification already performed?

[Elokane]

What's the most up to date Avalon set up/user guide?

[darkip]

Aren't all current units arriving with this modification already performed?

Mine were part of the earlier batch 2 deliveries with the F1 fuse still present.

[xiangfu]

Hi Avalon users

The first direct usb firmware released (Version: 20130607)
  Please read the ChangeLog before reflash, here: https://en.bitcoin.it/wiki/Avalon#20130607
  How to reflash: https://en.bitcoin.it/wiki/Avalon#How_to_reflash

If you have any problem on Avalon, please read/search this page first: https://en.bitcoin.it/wiki/Avalon.

Best Regards
Xiangfu

[PuertoLibre]

May I ask what the direct USB feature is?

[goxed]

May I ask what the direct USB feature is?

Somewhat along these lines: USB communication to the USB chip without UART emulation

[Syke]

I would like to set all this up in my house.  Here, we have 120 volt lines and 15 amp breakers.

so on circuit you can have 120 x 15= 1800 Watts maximum (not taking in account Cos phi effects and such)

Buy a kill-a-watt and mesure the exact consumption of your individual machines in action. Slap on some extra safety margin

For example, with this weather, my Batch #1 Avalon @ 300 MHz are consuming 655 Watts

So three machines would be > 1800 (and I would not try to load it to 99%)

You should not go over 80% for a continuous load like a miner. Keep it under 1440 watts for a 15 amp breaker.

[-ck]

With my deep respect to Con and Kano i can state following:

I calculate my ACTUAL hash rate as advised by Kano taking in account Diff1 shares accepted from pool(s) and cgminer up-time. This gives me EXACT (Real) hashrate. Knowing the fact my network was fine and i did not have downtime due to Network issues, pool issues or FPGA controller hangs (I am monitoring it every two minutes + automated power off/on no reboots) i am 100% sure that 3.2 is not performing.

PS: just for the reference (do math yourself)

Computer: cgminer 3.1.1
Elapsed: 7h 11m 30s
Difficulty Accepted:431530.00000000
MHS:71587.77

That was not happening with 3.2

Found the regression and I've rewritten the code to avoid this performance loss. It is committed to the master git tree now and will be in the next release. Hopefully xiangfu will be able to make an official testing firmware with it before then too.

[loshia]

With my deep respect to Con and Kano i can state following:

I calculate my ACTUAL hash rate as advised by Kano taking in account Diff1 shares accepted from pool(s) and cgminer up-time. This gives me EXACT (Real) hashrate. Knowing the fact my network was fine and i did not have downtime due to Network issues, pool issues or FPGA controller hangs (I am monitoring it every two minutes + automated power off/on no reboots) i am 100% sure that 3.2 is not performing.

PS: just for the reference (do math yourself)

Computer: cgminer 3.1.1
Elapsed: 7h 11m 30s
Difficulty Accepted:431530.00000000
MHS:71587.77

That was not happening with 3.2

Found the regression and I've rewritten the code to avoid this performance loss. It is committed to the master git tree now and will be in the next release. Hopefully xiangfu will be able to make an official testing firmware with it before then too.

I will test it tonight And i will share my findings in the morning. Let us hope that bitminter will not be dosed overnight

Thank you very much CON!

[-ck]

Even better, I've tried implementing overclocking to higher frequencies and can get my Avalon stable at 350 (without any voltage mods).

It was unstable at 375, but this is at 350 (diff 56) after a few mins:
(5s):81.58G (avg):81.55Gh/s | A:144  R:0  HW:135  U:22.4/m  WU:1158.3/m

[loshia]

Even better, I've tried implementing overclocking to higher frequencies and can get my Avalon stable at 350 (without any voltage mods).

It was unstable at 375, but this is at 350 (diff 56) after a few mins:
(5s):81.58G (avg):81.55Gh/s | A:144  R:0  HW:135  U:22.4/m  WU:1158.3/m

Nice!

What timing have you used (--avalon-options)?

Did you change PSU? I am positive that stock green power 650W will die. Did you measure Power consumption?

PS: Can you post a patch for overclocking somewhere?

10X
And Congats Enjoy your Avalon toy!

[-ck]

After a few more minutes it's up to
               

Code:

(5s):83.39G (avg):82.64Gh/s | A:350  R:0  HW:357  U:21.4/m  WU:1173.2/m   

Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README

34:375
36:350
39:325

Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this.

[loshia]

After a few more minutes it's up to
              

Code:

(5s):83.39G (avg):82.64Gh/s | A:350  R:0  HW:357  U:21.4/m  WU:1173.2/m   

Power usage only went up by 5W going to 325 and 10W going to 350. 375 was unstable. The code is already in git master along with the values in ASIC README

34:375
36:350
39:325

Since mine is a batch 2, it has a 750W PSU and it does not seem to be a power issue at 350, but HW errors go nuts above this.

Thanks a lot!

It seems that it will be sleepless night for me   I will be gentle start with 325 first