Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 287. (Read 5805537 times)
June 25, 2013, 11:12:30 AM
ckolivas: please comment on this issue https://bitcointalksearch.org/topic/m.2574434
June 25, 2013, 10:57:56 AM
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.
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.
June 25, 2013, 07:36:22 AM
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".
June 25, 2013, 07:30:11 AM
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: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!
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.
June 25, 2013, 07:28:25 AM
ckolivas thanks!!!
June 25, 2013, 07:25:34 AM
Don't use that pool ...
Problem is not with that pool, it works fine in signle-pool mode, problem is with cgminer. June 25, 2013, 07:23:59 AM
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: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!
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.
June 25, 2013, 07:17:44 AM
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!
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!
June 25, 2013, 04:34:22 AM
Don't use that pool ...
June 25, 2013, 03:46:18 AM
can anyone help me with the flags for cross compiling to avalon openwrt?
I do:
But got error on make:
Sorry, I'm not a linux expert with cross compiling
please help, thank you!
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!
June 25, 2013, 03:30:44 AM
Can devs cooment on mulipool issue i have https://bitcointalksearch.org/topic/m.2569165 ?
thanks
thanks
June 25, 2013, 01:37:14 AM
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?
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 ...)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.).
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.Code:
USB: AMU0 read1 buffering 252 extra bytes
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.
June 25, 2013, 01:16:53 AM
Anyway, are you gonna add in the scrypt OpenCL optimization somebody posted on the Litecoin forums?
Discussed before. It does nothing. June 24, 2013, 09:51:32 PM
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?
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.).
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.Code:
USB: AMU0 read1 buffering 252 extra bytes
June 24, 2013, 09:30:09 PM
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
June 24, 2013, 08:10:06 PM
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.).
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. Code:
USB: AMU0 read1 buffering 252 extra bytes
June 24, 2013, 08:07:48 PM
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
June 24, 2013, 04:53:24 PM
June 24, 2013, 04:50:41 PM
awwww, come on, don't be quick to get rid of the GPU mining ability.
It may not be cost effective, may even lose money, but it is the only way for newbies to get involved and see what mining is all about. Telling future miners that they can't mine without buying special equipment(which most are predicting won't see ROI) isn't exactly great for Bitcoins future. Telling them that the can mine with the GPU in their current computer but will spend more on electricity than the make in Bitcoin will at least see the technical side of mining and decide about buying better equipment.
I'd think that the GPU code is pretty solid by now. Would it be so hard just to leave it in? or, make a separate GPU only build for beginners to use? I've just got one GPU working this week and there is a second in the box that i want to get going. I don't care if they make expensive Bitcoins, I just need the Bitcoins to buy more ASICS, and don't want to go through transferring money through exchanges. For me this is a hobby, not a business. I'm mining because i enjoy it.
Same arguments as CPU. This equation has been done before. I'm talking about a year or more from now, not very soon, but I do like to give plenty of warning. When you're spending $300 a month in energy to earn $0.30 in BTC, you will see things differently, trust me. It may not be cost effective, may even lose money, but it is the only way for newbies to get involved and see what mining is all about. Telling future miners that they can't mine without buying special equipment(which most are predicting won't see ROI) isn't exactly great for Bitcoins future. Telling them that the can mine with the GPU in their current computer but will spend more on electricity than the make in Bitcoin will at least see the technical side of mining and decide about buying better equipment.
I'd think that the GPU code is pretty solid by now. Would it be so hard just to leave it in? or, make a separate GPU only build for beginners to use? I've just got one GPU working this week and there is a second in the box that i want to get going. I don't care if they make expensive Bitcoins, I just need the Bitcoins to buy more ASICS, and don't want to go through transferring money through exchanges. For me this is a hobby, not a business. I'm mining because i enjoy it.
June 24, 2013, 04:02:52 PM
awwww, come on, don't be quick to get rid of the GPU mining ability.
It may not be cost effective, may even lose money, but it is the only way for newbies to get involved and see what mining is all about. Telling future miners that they can't mine without buying special equipment(which most are predicting won't see ROI) isn't exactly great for Bitcoins future. Telling them that the can mine with the GPU in their current computer but will spend more on electricity than the make in Bitcoin will at least see the technical side of mining and decide about buying better equipment.
I'd think that the GPU code is pretty solid by now. Would it be so hard just to leave it in? or, make a separate GPU only build for beginners to use? I've just got one GPU working this week and there is a second in the box that i want to get going. I don't care if they make expensive Bitcoins, I just need the Bitcoins to buy more ASICS, and don't want to go through transferring money through exchanges. For me this is a hobby, not a business. I'm mining because i enjoy it.
It may not be cost effective, may even lose money, but it is the only way for newbies to get involved and see what mining is all about. Telling future miners that they can't mine without buying special equipment(which most are predicting won't see ROI) isn't exactly great for Bitcoins future. Telling them that the can mine with the GPU in their current computer but will spend more on electricity than the make in Bitcoin will at least see the technical side of mining and decide about buying better equipment.
I'd think that the GPU code is pretty solid by now. Would it be so hard just to leave it in? or, make a separate GPU only build for beginners to use? I've just got one GPU working this week and there is a second in the box that i want to get going. I don't care if they make expensive Bitcoins, I just need the Bitcoins to buy more ASICS, and don't want to go through transferring money through exchanges. For me this is a hobby, not a business. I'm mining because i enjoy it.
Jump to: