Avalon ASIC users thread

[uhoh]

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.

Wow, that's damn impressive. I smell a hashrate spike! 

[1713962393]

1713962393

[1713962393]

1713962393

[1713962393]

1713962393

[irritant]

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.

does the Avalon  temp increase?

[-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.

does the Avalon  temp increase?

Indeed, but the fans also increase, so it only went up by 2 degrees here max here (it's winter here).

[Sitarow]

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.

Wow, that's damn impressive. I smell a hashrate spike!  

Nice work and thank you for sharing your results.

I upgraded to the 860i and I find that as long as the ambient temps are in the 20 range then the hardware should be able to cope with the increased speed.

[loshia]

Con,

Just a thought about 39:325. I do not know why 40:300 was increased to 43:300 with latest updates, but i am positive that 3.1 with 40:300 is making 70500-71000 stable. Following that logic will 37:325 be better?

 

[-ck]

Con,

Just a thought about 39:325. I do not know why 40:300 was increased to 43:300 with latest updates, but i am positive that 3.1 with 40:300 is making 70500-71000 stable. Following that logic will 37:325 be better?

 

No, the latency number (43) only affects the risk of duplicates and the code has been so drastically changed since the original code that the higher value is actually better since it reloads work less frequently and uses less CPU without any chance of dupes.

[loshia]

Con,

Just a thought about 39:325. I do not know why 40:300 was increased to 43:300 with latest updates, but i am positive that 3.1 with 40:300 is making 70500-71000 stable. Following that logic will 37:325 be better?

 

No, the latency number (43) only affects the risk of duplicates and the code has been so drastically changed since the original code that the higher value is actually better since it reloads work less frequently and uses less CPU without any chance of dupes.

Super!

Thank you for the explanation.
Best

[jspielberg]

Wow... with all these improvements, Batch3 is going to be great!

[-ck]

Okay I experimented with different frequencies around 350, and the hardware error count was about 1.8% by the time it was at 350, but the effective useful hashrate was the highest there, so on my hardware at least, 350 really is a sweet spot. It ran for 45 minutes and averaged about 82.3GH of submitted shares. An extra 11GH for another 10W is ... quite remarkable. I get ~82GH for 605W (at 240V) at the wall now where I used to get ~71GH at 595W at frequency 300.

Wow... with all these improvements, Batch3 is going to be great!

Actually this is all software...

[loshia]

Okay I experimented with different frequencies around 350, and the hardware error count was about 1.8% by the time it was at 350, but the effective useful hashrate was the highest there, so on my hardware at least, 350 really is a sweet spot. It ran for 45 minutes and averaged about 82.3GH of submitted shares. An extra 11GH for another 10W is ... quite remarkable. I get ~82GH for 605W (at 240V) at the wall now where I used to get ~71GH at 595W at frequency 300.

Wow... with all these improvements, Batch3 is going to be great!

Actually this is all software...

And the guy who is making it 

Thank You!

[gyverlb]

I haven't looked at the driver yet (still waiting for my Avalon... so not much motivation here) but would it be possible to tune each blade frequency independently of the others (or with even finer granularity)?

If we have access to hardware errors and frequency settings blade by blade or by groups of chips or even by individual chips I'm thinking of some nice automatic overclocking...

[-ck]

No firmware yet, but if you know how to use the binary directly on the avalon here is a binary with the new speeds supported from the latest cgminer git:
http://ck.kolivas.org/apps/cgminer/temp/cgminer

[caoxg]

a quick question, I'm not familar with openwrt:

root@OpenWrt:~df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                  320.0K    228.0K     92.0K  71% /
/dev/root                 2.5M      2.5M         0 100% /rom
tmpfs                    14.2M    540.0K     13.7M   4% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock3          320.0K    228.0K     92.0K  71% /overlay
overlayfs:/overlay      320.0K    228.0K     92.0K  71% /

it seems only /tmp have enough free space for new cgminer binary.
But it is a tmpfs so it will gone when restart , right?

[Vicus]

a quick question, I'm not familar with openwrt:

root@OpenWrt:~df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                  320.0K    228.0K     92.0K  71% /
/dev/root                 2.5M      2.5M         0 100% /rom
tmpfs                    14.2M    540.0K     13.7M   4% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock3          320.0K    228.0K     92.0K  71% /overlay
overlayfs:/overlay      320.0K    228.0K     92.0K  71% /

it seems only /tmp have enough free space for new cgminer binary.
But it is a tmpfs so it will gone when restart , right?

Yes, you need to upload it again.

[dopamine]

No firmware yet, but if you know how to use the binary directly on the avalon here is a binary with the new speeds supported from the latest cgminer git:
http://ck.kolivas.org/apps/cgminer/temp/cgminer

can you give step by step instructions? I seem to get

kern.err kernel: [51298.090000] usb 1-1: clear tt 1 (00e0) error -71

wondering if I should try to solve this first before I try to fine tune this beast

[server]

No firmware yet, but if you know how to use the binary directly on the avalon here is a binary with the new speeds supported from the latest cgminer git:
http://ck.kolivas.org/apps/cgminer/temp/cgminer

Thanks man, stable as a rock

[-ck]

a quick question, I'm not familar with openwrt:

root@OpenWrt:~df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                  320.0K    228.0K     92.0K  71% /
/dev/root                 2.5M      2.5M         0 100% /rom
tmpfs                    14.2M    540.0K     13.7M   4% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock3          320.0K    228.0K     92.0K  71% /overlay
overlayfs:/overlay      320.0K    228.0K     92.0K  71% /

it seems only /tmp have enough free space for new cgminer binary.
But it is a tmpfs so it will gone when restart , right?

This is what I did, wget the file to /tmp

(don't forget to chmod 755)

and replace the old cgminer with a symbolic link

cd /usr/bin
mv cgminer cgminer.old
ln -s /tmp/cgminer cgminer

Be aware this will trash it on startup as you suspected since there will be no binary in /tmp on reboot.

[Kuma]

a quick question, I'm not familar with openwrt:

root@OpenWrt:~df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                  320.0K    228.0K     92.0K  71% /
/dev/root                 2.5M      2.5M         0 100% /rom
tmpfs                    14.2M    540.0K     13.7M   4% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock3          320.0K    228.0K     92.0K  71% /overlay
overlayfs:/overlay      320.0K    228.0K     92.0K  71% /

it seems only /tmp have enough free space for new cgminer binary.
But it is a tmpfs so it will gone when restart , right?

This is what I did, wget the file to /tmp

(don't forget to chmod 755)

and replace the old cgminer with a symbolic link

cd /usr/bin
mv cgminer cgminer.old
ln -s /tmp/cgminer cgminer

mv command returns mv: can't rename 'cgminer': No space left on device  . I'm not sure why as filesystem is rw.

[server]

I see I moved cgminer to /tmp/cgminer.old

Be aware this will trash it on startup as you suspected since there will be no binary in /tmp on reboot.

I know.. it's better to wait on a Xiangfu release.

Or use this one from Strombom:

https://bitcointalk.org/index.php?topic=210186.msg2544524#msg2544524

[-ck]

mv command returns mv: can't rename 'cgminer': No space left on device  . I'm not sure why as filesystem is rw.

Flash filesystems aren't really rw. They are only write once and you cannot delete from them. When you delete a file, it makes the file inaccessible but you never regain the space till you flash the firmware again.