OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[-ck]

Anyone seen below error before and perhaps knows what it relates to? I'm suspecting it's some kind of limitation on USB hubs (1a40:0101 Terminus Technology Inc.).

Code:

USB: AMU0 read1 buffering 252 extra bytes

It means cgminer found a lot more information from the device than it was expecting, but it's harmless and the equivalent to a hardware error.

[-ck]

Quick update, version 3.3.0 has a last minute regression that prevents new firmware singles and minirigs from working, and only the latest git will work. I'll be posting a hotfix release in the not too distant future. This is the problem with us not having physical hardware yet to confirm everything works as expected

[bicer]

thx ck.

After cgminier restart the same unit that was showing that error now shows zero value for A: R: and /m but correct hashing speed. Is it safe to assume the unit is actually not doing anything?

Anyone seen below error before and perhaps knows what it relates to? I'm suspecting it's some kind of limitation on USB hubs (1a40:0101 Terminus Technology Inc.).

Code:

USB: AMU0 read1 buffering 252 extra bytes

It means cgminer found a lot more information from the device than it was expecting, but it's harmless and the equivalent to a hardware error.

[-ck]

Anyway, are you gonna add in the scrypt OpenCL optimization somebody posted on the Litecoin forums?

Discussed before. It does nothing.

[kano]

thx ck.

After cgminier restart the same unit that was showing that error now shows zero value for A: R: and /m but correct hashing speed. Is it safe to assume the unit is actually not doing anything?

Anyone seen below error before and perhaps knows what it relates to? I'm suspecting it's some kind of limitation on USB hubs (1a40:0101 Terminus Technology Inc.).

Code:

USB: AMU0 read1 buffering 252 extra bytes

It means cgminer found a lot more information from the device than it was expecting, but it's harmless and the equivalent to a hardware error.

I added  a buffer into the Icarus driver to handle the VERY rare case of getting 2 answers back at the same time (extremely rare ...)
The 2nd answer seems to be rubbish when it happens.

It showed up this particular issue you see, of sometimes getting extra data back from libusb.
It doesn't affect anything but the data at the time it happens - which either doesn't contain a share or has a corrupted one in it.

[Subw]

Can devs cooment on mulipool issue i have https://bitcointalk.org/index.php?topic=28402.msg2569165#msg2569165 ?
thanks

[ebereon]

can anyone help me with the flags for cross compiling to avalon openwrt?

I do:

Code:

./configure --build=mips-openwrt-linux-uclibc --disable-opencl --disable-adl --enable-avalon

But got error on make:

Code:

  CC     cgminer-cgminer.o
cgminer.c:15:20: fatal error: curses.h: No such file or directory
compilation terminated.

Sorry, I'm not a linux expert with cross compiling 
please help, thank you!

[kano]

Can devs cooment on mulipool issue i have https://bitcointalk.org/index.php?topic=28402.msg2569165#msg2569165 ?
thanks

Don't use that pool ...

[yantis]

ckolivas / kano - Can you tell me which is a better stat for measuring. Its is MHS or Work Utility?

From your readme: WU:  The Work Utility defined as the number of diff1 shares work / minute (accepted or rejected).

On some units at 375 Mhz overclock I get a higher work utility but lower MHS than I do at 350 Mhz. (and on other units I get a what I feel is good scaling). I am not sure how work utility is calculated or if its just an estimate.
My theory was if Work Utility provided a better stat then I would target that vs MHS. I just have so much variance so was trying to figure it out. Any help appreciated!

Thanks!

[-ck]

ckolivas / kano - Can you tell me which is a better stat for measuring. Its is MHS or Work Utility?

From your readme: WU:  The Work Utility defined as the number of diff1 shares work / minute (accepted or rejected).

On some units at 375 Mhz overclock I get a higher work utility but lower MHS than I do at 350 Mhz. (and on other units I get a what I feel is good scaling). I am not sure how work utility is calculated or if its just an estimate.
My theory was if Work Utility provided a better stat then I would target that vs MHS. I just have so much variance so was trying to figure it out. Any help appreciated!

Thanks!

On avalon:
WU is accepted + rejected + nonce errors.
MHs is accepted + rejected

So you're better off with MHs for that particular hardware and how it measures those values.

[Subw]

Can devs cooment on mulipool issue i have https://bitcointalk.org/index.php?topic=28402.msg2569165#msg2569165 ?
thanks

Don't use that pool ...

Problem is not with that pool, it works fine in signle-pool mode, problem is with cgminer.

[yantis]

ckolivas thanks!!!

[juhakall]

ckolivas / kano - Can you tell me which is a better stat for measuring. Its is MHS or Work Utility?

From your readme: WU:  The Work Utility defined as the number of diff1 shares work / minute (accepted or rejected).

On some units at 375 Mhz overclock I get a higher work utility but lower MHS than I do at 350 Mhz. (and on other units I get a what I feel is good scaling). I am not sure how work utility is calculated or if its just an estimate.
My theory was if Work Utility provided a better stat then I would target that vs MHS. I just have so much variance so was trying to figure it out. Any help appreciated!

Thanks!

On avalon:
WU is accepted + rejected + nonce errors.
MHs is accepted + rejected

So you're better off with MHs for that particular hardware and how it measures those values.

Is it the same for BFL ASICs, or are HW errors included in their hashrate? I thought they were included in the hashrate for all devices, it's quite confusing if they are included for some but not for others.

[-ck]

Is it the same for BFL ASICs, or are HW errors included in their hashrate? I thought they were included in the hashrate for all devices, it's quite confusing if they are included for some but not for others.

You're right, it is confusing and they are different. It has to do with the fact that on one device, BFLSC, I know precisely how many "hashes" were attempted by the device, while on the Avalon, the best I can do is estimate based on the amount of nonces returned due to work being aborted a random proportion through its completion rather than at the end. If I start counting the hw errors as hashes on the avalon, I could get a flood of hw errors in a row, as sometimes happens, that make the hashrate look like it's spiked upwards.

It's painful with every manufacturer doing something different and there being no meaningful way to unite a lot of these into "standards".

[-ck]

New release: version 3.3.1, 26th June 2013

Hotfix release. Last minute bug went into 3.3.0 preventing BFL SC singles from working as planned
Note now there are avalon firmware images in my directory as well, with the latest version.

Human readable changelog:

- Bugfix for BFL SC singles and minirigs which prevented them working.
- Bugfix for the usb wildcards 1:*
- Increased target temperature on Avalons to 50 since 45 was overkill
- Added overheat temperature cutoff to avalons
- Added dynamic automatic overclocking to avalons with --avalon-auto


Full changelog:

- Add an avalon-auto option which enables dynamic overclocking based on hardware
error rate for maximum effective hashrate.
- Add an --avalon-cutoff feature which puts the avalon idle should it reach this
temperature, defaulting to 60, re-enabling it when it gets to target
temperature.
- Change default avalon target temperature to 50 degrees.
- usbutils - incorrect test for * in bus:dev
- Redo +1 fix in bflsc.

[Subw]

ckolivas: please comment on this issue https://bitcointalk.org/index.php?topic=28402.msg2574434#msg2574434

[ebereon]

New release: version 3.3.1, 26th June 2013

Hotfix release. Last minute bug went into 3.3.0 preventing BFL SC singles from working as planned
Note now there are avalon firmware images in my directory as well, with the latest version.

Human readable changelog:

- Bugfix for BFL SC singles and minirigs which prevented them working.
- Bugfix for the usb wildcards 1:*
- Increased target temperature on Avalons to 50 since 45 was overkill
- Added overheat temperature cutoff to avalons
- Added dynamic automatic overclocking to avalons with --avalon-auto


Full changelog:

- Add an avalon-auto option which enables dynamic overclocking based on hardware
error rate for maximum effective hashrate.
- Add an --avalon-cutoff feature which puts the avalon idle should it reach this
temperature, defaulting to 60, re-enabling it when it gets to target
temperature.
- Change default avalon target temperature to 50 degrees.
- usbutils - incorrect test for * in bus:dev
- Redo +1 fix in bflsc.

Nice! But is there a way you can implement 5MH steps from 300 to 375? That would get more on some configs. My avalons run fine on 365.

Tip is on the way  

EDIT: Holyshit!!! it's already in there    Another Tip send!!! Thanks!

[bitdaniel]

New release: version 3.3.1, 26th June 2013

Hotfix release. Last minute bug went into 3.3.0 preventing BFL SC singles from working as planned
Note now there are avalon firmware images in my directory as well, with the latest version.

Human readable changelog:

- Bugfix for BFL SC singles and minirigs which prevented them working.
- Bugfix for the usb wildcards 1:*
- Increased target temperature on Avalons to 50 since 45 was overkill
- Added overheat temperature cutoff to avalons
- Added dynamic automatic overclocking to avalons with --avalon-auto


Full changelog:

- Add an avalon-auto option which enables dynamic overclocking based on hardware
error rate for maximum effective hashrate.
- Add an --avalon-cutoff feature which puts the avalon idle should it reach this
temperature, defaulting to 60, re-enabling it when it gets to target
temperature.
- Change default avalon target temperature to 50 degrees.
- usbutils - incorrect test for * in bus:dev
- Redo +1 fix in bflsc.

This is so awesome!
Getting my new avalon just today when so much new functions are released!
Thank you!

[Kuma]

Thanks a lot Con for avalon-auto option. Is it possible to create something like avalon-limit frequency option?
One of my avalons has freezing controller board at 350 MHz, but during avalon-auto it worked around 330-340 without problems, so I'm currently locked at 325  .

[-ck]

Thanks a lot Con for avalon-auto option. Is it possible to create something like avalon-limit frequency option?
One of my avalons has freezing controller board at 350 MHz, but during avalon-auto it worked around 330-340 without problems, so I'm currently locked at 325  .

Maybe so.