Con, your new cgminer with bigger oc capabilities is just amazing. Thanks a lot.
I'd consider donation 
(and I'll donate when I receive and mine off my unit)
Topic: Avalon ASIC users thread - page 169. (Read 438600 times)
(and I'll donate when I receive and mine off my unit)
Con, your new cgminer with bigger oc capabilities is just amazing. Thanks a lot.
Latest version of the firmware 06-07 produces a LOT of HW errors. For example, 102 accepted shares 62 HW errors. It also oddly stops hashing intermittently. I am guessing cgminer is crashing or something as the monitor script revives it and it resumes hashing but still with the unusually high error rate. 0519 has been rock solid for me so I flashed back to that version.
I'm running it at 300 if that has any bearing on anything. Anyone else noticing this or is it just my unit? I should also mention that I did not clear the settings before flashing to 06-07 (I told it to remember settings).
This is a combination of more accurate reporting of hw errors, and more software caused errors as a result of the changes. Fixes are in newer cgminer code which has yet to make it into a new firmware for you to flash. I'm running it at 300 if that has any bearing on anything. Anyone else noticing this or is it just my unit? I should also mention that I did not clear the settings before flashing to 06-07 (I told it to remember settings).
Latest version of the firmware 06-07 produces a LOT of HW errors. For example, 102 accepted shares 62 HW errors. It also oddly stops hashing intermittently. I am guessing cgminer is crashing or something as the monitor script revives it and it resumes hashing but still with the unusually high error rate. 0519 has been rock solid for me so I flashed back to that version.
I'm running it at 300 if that has any bearing on anything. Anyone else noticing this or is it just my unit? I should also mention that I did not clear the settings before flashing to 06-07 (I told it to remember settings).
I'm running it at 300 if that has any bearing on anything. Anyone else noticing this or is it just my unit? I should also mention that I did not clear the settings before flashing to 06-07 (I told it to remember settings).
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.. I'm not sure why as filesystem is rw.Oh thanks for explanation, I have no experience with flash filesystems, so I was a little bit suprised by this behavior. Any idea how to change it without new fw flash?
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.. I'm not sure why as filesystem is rw.Oh thanks for explanation, I have no experience with flash filesystems, so I was a little bit suprised by this behavior. Any idea how to change it without new fw flash?
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. . I'm not sure why as filesystem is rw.
I see I moved cgminer to /tmp/cgminer.old
I know.. it's better to wait on a Xiangfu release.
Or use this one from Strombom:
https://bitcointalksearch.org/topic/m.2544524
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://bitcointalksearch.org/topic/m.2544524
a quick question, I'm not familar with openwrt:
it seems only /tmp have enough free space for new cgminer binary.
But it is a tmpfs so it will gone when restart , right?
Quote
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% /
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.a quick question, I'm not familar with openwrt:
it seems only /tmp have enough free space for new cgminer binary.
But it is a tmpfs so it will gone when restart , right?
Quote
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% /
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
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
http://ck.kolivas.org/apps/cgminer/temp/cgminer
Thanks man, stable as a rock
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
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
a quick question, I'm not familar with openwrt:
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.Quote
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% /
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?
a quick question, I'm not familar with openwrt:
it seems only /tmp have enough free space for new cgminer binary.
But it is a tmpfs so it will gone when restart , right?
Quote
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% /
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?
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
http://ck.kolivas.org/apps/cgminer/temp/cgminer
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...
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...
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.
Actually this is all software...
And the guy who is making it Wow... with all these improvements, Batch3 is going to be great!
Actually this is all software...
Thank You!
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.
Actually this is all software...
Wow... with all these improvements, Batch3 is going to be great!
Actually this is all software...
Wow... with all these improvements, Batch3 is going to be great!
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.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?
Super!
Thank you for the explanation.
Best
Jump to: