Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 789. (Read 5805728 times)
September 02, 2011, 02:48:26 PM
I'm having some issues with the Windows release of 1.6.2. It will not activate 2/3 of my GPU's it fails to lock the thread on the GPU's. If I go back to 1.6.0 everything is fine. What sort of output do I need to provide for this issue to be troubleshooted? Screenshot or some sort of log?
September 02, 2011, 10:11:35 AM
keep up the good work 
love the app
love the app 
September 02, 2011, 05:35:51 AM
Yay! It compiles with curl from RHEL5 again! CPU-only RPMs are ready: http://rpm.zaytsev.net/test/cgminer/ . I will edit the RPM post later.
Yes I figured out what I had broken from the old curl at last. Please note that the old curl does not have support for sockoptions that make longpoll reliable. So while it is compiling with older libcurls, it may not be as reliable with longpoll on some servers. 
September 02, 2011, 05:19:12 AM
If anyone is interested, thought this might be helpful to some.
If you run Cgminer on Windows 7 (should work on other versions) this startup .cmd will launch Cgminer using only one CPU core and outputs log info to a log file that has the date and time in the filename.
Open notepad.exe and put the following in (changing username and password and your servers of course):
This will use core number 4.
1st core = 1
2nd core = 2
3rd core = 4
4th core = 8
5th core = 10 ( hexadecimal 16 )
6th core = 20 ( hexadecimal 32 )
now if you want something to run on just one core, you pick the right number like this, just multiply by 2 until you get to the core you want.
if you want something to run on two cores, you ADD their values:
1st and 2nd core = 1 + 2 = 3
1st and 3rd core = 1 + 4 = 5
2nd and 3rd core = 2 + 4 = 6
2nd and 4th core = 2 + 8 = A
Same thing if you want more than two cores, just add each core numerical value up and use the sum as the /affinity parameter
If you run Cgminer on Windows 7 (should work on other versions) this startup .cmd will launch Cgminer using only one CPU core and outputs log info to a log file that has the date and time in the filename.
Open notepad.exe and put the following in (changing username and password and your servers of course):
Code:
rem del /F /Q *.bin
start /B /affinity 8 cgminer -o http://yourprimaryserver:port -u yourworkername -p your password -o http://yourbackupserver:port -u yourworkername -p yourpassword -I 9 2>"%date:~4,2%-%date:~7,2%-%date:~12,2%%time:~0,2%-%time:~3,2%-%time:~6,2%.log"
pause
This will use core number 4.
1st core = 1
2nd core = 2
3rd core = 4
4th core = 8
5th core = 10 ( hexadecimal 16 )
6th core = 20 ( hexadecimal 32 )
now if you want something to run on just one core, you pick the right number like this, just multiply by 2 until you get to the core you want.
if you want something to run on two cores, you ADD their values:
1st and 2nd core = 1 + 2 = 3
1st and 3rd core = 1 + 4 = 5
2nd and 3rd core = 2 + 4 = 6
2nd and 4th core = 2 + 8 = A
Same thing if you want more than two cores, just add each core numerical value up and use the sum as the /affinity parameter
September 02, 2011, 04:52:39 AM
Yay! It compiles with curl from RHEL5 again! CPU-only RPMs are ready: http://rpm.zaytsev.net/test/cgminer/ . I will edit the RPM post later.
September 02, 2011, 04:49:36 AM
[..]
Compiling 1.6.1 is a different story though. I notice the configure script checks for curl_easy_init and after that does the pkg-config check for libcurl. Since it doesn't know where to look for curl yet, the former check obviously fails. Also, you use LIBCURL_CPPFLAGS, but on FreeBSD (and possibly other systems), pkg-config only returns LIBCURL_CFLAGS. Since they should be the same, could you change it to make use of CFLAGS instead of CPPFLAGS ?
libcurl.m4 defines LIBCURL_CPPFLAGS and CFLAGS would be something completely different as far as I understand it, so you're missing the m4 file from some package.Compiling 1.6.1 is a different story though. I notice the configure script checks for curl_easy_init and after that does the pkg-config check for libcurl. Since it doesn't know where to look for curl yet, the former check obviously fails. Also, you use LIBCURL_CPPFLAGS, but on FreeBSD (and possibly other systems), pkg-config only returns LIBCURL_CFLAGS. Since they should be the same, could you change it to make use of CFLAGS instead of CPPFLAGS ?
The configure script from the tarball (1.6.2) contains the following:
Code:
pkg_cv_LIBCURL_CFLAGS=`$PKG_CONFIG --cflags "libcurl >= 7.15.6" 2>/dev/null`
It doesn't set LIBCURL_CPPFLAGS anywhere (which makes pkg-config detection obsolete IMO). Also, in the Makefile.am it should be changed to LIBCURL_CFLAGS instead of LIBCURL_CPPFLAGS.
September 02, 2011, 03:11:42 AM
which sounds a lot like problems with older curl to me...
Yes, yours are the problems that I mentioned above. I am preparing an RPM that you can rebuild with rpmbuild if you need GPU mining or use it as is if you only need CPU mining this evening, which features a static build against curl, so which version is in the base system repos would be irrelevant.
September 02, 2011, 02:07:38 AM
working on one PC, but will not run on others
tried 2 different pools, internet is working, pools up
i get a message saying no servers were found
it just exits straight away
vista 32bit fresh install :/
tried 2 different pools, internet is working, pools up
i get a message saying no servers were found
it just exits straight away
vista 32bit fresh install :/
What GPU does include the PCs, and what driver/SDK version are installed?
September 02, 2011, 12:51:47 AM
working on one PC, but will not run on others
tried 2 different pools, internet is working, pools up
i get a message saying no servers were found
it just exits straight away
vista 32bit fresh install :/
tried 2 different pools, internet is working, pools up
i get a message saying no servers were found
it just exits straight away
vista 32bit fresh install :/
September 01, 2011, 09:59:17 PM
New version: 1.6.2
Executive summary:
New --failover-only feature for those who complain too much work goes to the backup pool even without the primary pool failing. NOTE that you may get more idle periods with this enabled (which is why it leaked work to the backup pool in the first place).
New scheduling features to specify a start and stop time.
Various fixes and more verbose pebkac warnings.
Full changelog:
- Add --failover-only option to not leak work to backup pools when the primary
pool is lagging.
- Change recommendation to intensity 9 for dedicated miners.
- Fix the bouncing short term value by allowing it to change dynamically when
the latest value is very different from the rolling value, but damp the change
when it gets close.
- Use the curses_lock to protect the curses_active variable and test it under
lock.
- Go back to requesting work 2/3 of the way through the current scantime with
CPU mining as reports of mining threads running out of work have occurred with
only 5 seconds to retrieve work.
- Add start and stop time scheduling for regular time of day running or once off
start/stop options.
- Print summary on quit modes.
- Put some sanity checks on the times that can be input.
- Give a verbose message when no active pools are found and pause before
exiting.
- Add verbose message when a GPU fails to initialise, and disable the correct
GPU.
- Cryptopp asm32 was not correctly updated to the incremental nonce code so the
hash counter was bogus.
- Get rid of poorly executed curl check.
- If curl does not have sockopts, do not try to compile the
json_rpc_call_sockopt_cb function, making it possible to build against older
curl libraries.
- Most people expect /usr/local when an unspecified prefix is used so change to
that.
- Rename localgen occasions to getwork fail occasions since localgen is
unrelated now.
Links in top post.
Executive summary:
New --failover-only feature for those who complain too much work goes to the backup pool even without the primary pool failing. NOTE that you may get more idle periods with this enabled (which is why it leaked work to the backup pool in the first place).
New scheduling features to specify a start and stop time.
Various fixes and more verbose pebkac warnings.
Full changelog:
- Add --failover-only option to not leak work to backup pools when the primary
pool is lagging.
- Change recommendation to intensity 9 for dedicated miners.
- Fix the bouncing short term value by allowing it to change dynamically when
the latest value is very different from the rolling value, but damp the change
when it gets close.
- Use the curses_lock to protect the curses_active variable and test it under
lock.
- Go back to requesting work 2/3 of the way through the current scantime with
CPU mining as reports of mining threads running out of work have occurred with
only 5 seconds to retrieve work.
- Add start and stop time scheduling for regular time of day running or once off
start/stop options.
- Print summary on quit modes.
- Put some sanity checks on the times that can be input.
- Give a verbose message when no active pools are found and pause before
exiting.
- Add verbose message when a GPU fails to initialise, and disable the correct
GPU.
- Cryptopp asm32 was not correctly updated to the incremental nonce code so the
hash counter was bogus.
- Get rid of poorly executed curl check.
- If curl does not have sockopts, do not try to compile the
json_rpc_call_sockopt_cb function, making it possible to build against older
curl libraries.
- Most people expect /usr/local when an unspecified prefix is used so change to
that.
- Rename localgen occasions to getwork fail occasions since localgen is
unrelated now.
Links in top post.
September 01, 2011, 07:21:51 PM
Hi ckolivas,
I can confirm the high number of rejects (100% on my boxes) with CPU mining has been fixed. The only algo that wouldn't generate rejects for me was the sse2_64. So great work.
Compiling 1.6.1 is a different story though. I notice the configure script checks for curl_easy_init and after that does the pkg-config check for libcurl. Since it doesn't know where to look for curl yet, the former check obviously fails. Also, you use LIBCURL_CPPFLAGS, but on FreeBSD (and possibly other systems), pkg-config only returns LIBCURL_CFLAGS. Since they should be the same, could you change it to make use of CFLAGS instead of CPPFLAGS ?
Thanks in advance.
libcurl.m4 defines LIBCURL_CPPFLAGS and CFLAGS would be something completely different as far as I understand it, so you're missing the m4 file from some package. I can confirm the high number of rejects (100% on my boxes) with CPU mining has been fixed. The only algo that wouldn't generate rejects for me was the sse2_64. So great work.
Compiling 1.6.1 is a different story though. I notice the configure script checks for curl_easy_init and after that does the pkg-config check for libcurl. Since it doesn't know where to look for curl yet, the former check obviously fails. Also, you use LIBCURL_CPPFLAGS, but on FreeBSD (and possibly other systems), pkg-config only returns LIBCURL_CFLAGS. Since they should be the same, could you change it to make use of CFLAGS instead of CPPFLAGS ?
Thanks in advance.
September 01, 2011, 06:48:06 PM
A typical mining rig isn't your production-class server running old stable userland.
Given the single purpose of the mining rig, the smaller, the more stripped, the more stable, the better.. that does not match, sadly, the goals of most new distros. I've been running on Fedora14/15 and am actually trying to move backwards to Centos5 for the greater stability... currently being stopped short compiling 1.6.1 with:
Quote
if gcc -DHAVE_CONFIG_H -I. -I. -I. -pthread -fno-strict-aliasing -I./compat/jansson -I./lib -I./lib -O3 -Wall -msse2 -I/usr/src/AMD-APP-SDK-v2.4-lnx32/include -g -MT cgminer-main.o -MD -MP -MF ".deps/cgminer-main.Tpo" -c -o cgminer-main.o `test -f 'main.c' || echo './'`main.c; \
then mv -f ".deps/cgminer-main.Tpo" ".deps/cgminer-main.Po"; else rm -f ".deps/cgminer-main.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I. -pthread -fno-strict-aliasing -I./compat/jansson -I./lib -I./lib -O3 -Wall -msse2 -I/usr/src/AMD-APP-SDK-v2.4-lnx32/include -g -MT cgminer-util.o -MD -MP -MF ".deps/cgminer-util.Tpo" -c -o cgminer-util.o `test -f 'util.c' || echo './'`util.c; \
then mv -f ".deps/cgminer-util.Tpo" ".deps/cgminer-util.Po"; else rm -f ".deps/cgminer-util.Tpo"; exit 1; fi
util.c:227: error: expected declaration specifiers or ‘...’ before ‘curlsocktype’
then mv -f ".deps/cgminer-main.Tpo" ".deps/cgminer-main.Po"; else rm -f ".deps/cgminer-main.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I. -pthread -fno-strict-aliasing -I./compat/jansson -I./lib -I./lib -O3 -Wall -msse2 -I/usr/src/AMD-APP-SDK-v2.4-lnx32/include -g -MT cgminer-util.o -MD -MP -MF ".deps/cgminer-util.Tpo" -c -o cgminer-util.o `test -f 'util.c' || echo './'`util.c; \
then mv -f ".deps/cgminer-util.Tpo" ".deps/cgminer-util.Po"; else rm -f ".deps/cgminer-util.Tpo"; exit 1; fi
util.c:227: error: expected declaration specifiers or ‘...’ before ‘curlsocktype’
which sounds a lot like problems with older curl to me..
.
September 01, 2011, 09:52:31 AM
Obviously, I need it. It's not because I care so much about other people that might need it that I am asking for it. Having to do it myself is a logical answer though.
September 01, 2011, 09:45:09 AM
A typical mining rig isn't your production-class server running old stable userland. I don't see any point putting developer time in working on older curl compatibility. It probably won't be used by many, if anyone at all.
just my 2c.
just my 2c.
September 01, 2011, 08:55:25 AM
Ok, got it, I'll try to make you some working patch tomorrow as I'll have to spend the time on train... The problem is as always the lack of time, so I'm hoping till the very end that someone else will do it for me :-)
P.S. I've checked on the CPU mining memleak and it's still leaking albeit slower. Like 200 mb per day or so.
P.S. I've checked on the CPU mining memleak and it's still leaking albeit slower. Like 200 mb per day or so.
September 01, 2011, 08:45:59 AM
Ok, configure scripts are witchcraft to me.
I'm having trouble finding any interest in supporting older distributions and libraries in light of that knowledge limitation of mine. If you have patches, I'd be more than happy to accept them
I'm having trouble finding any interest in supporting older distributions and libraries in light of that knowledge limitation of mine. If you have patches, I'd be more than happy to accept them
September 01, 2011, 08:40:57 AM
Also, it is not clear to me what is the purpose of the following check in configure.ac:
it comes *before* PKGCONFIG detection, so unless curl is installed in a standard location it just can't succeed. Also, LIBCURL_CPPFLAGS / LIBCURL_LIBS are substituted after the pkgconfig check, and if the check fails, then configure fails. So they don't make much sense, because if pkgconfig is non-existant or doesn't find the lib, it will AC_MSG_ERROR.
My suggestions:
1) Only pkgconfig if LIBCURL_CPPFLAGS / LIBCURL_LIBS are NOT set
2) Move AC_CHECK_LIB *after* pkgconfig
3) Add LIBCURL_CPPFLAGS / LIBCURL_LIBS to CPPFLAGS / LDFLAGS before AC_CHECK_LIB and restore afterwards
Right now I basically can't compile cgminer against a statically linked libcurl.a
Quote
AC_CHECK_LIB(curl, curl_easy_init, ,
<------>AC_MSG_ERROR([Could not find curl library - please install libcurl-dev]))
<------>AC_MSG_ERROR([Could not find curl library - please install libcurl-dev]))
it comes *before* PKGCONFIG detection, so unless curl is installed in a standard location it just can't succeed. Also, LIBCURL_CPPFLAGS / LIBCURL_LIBS are substituted after the pkgconfig check, and if the check fails, then configure fails. So they don't make much sense, because if pkgconfig is non-existant or doesn't find the lib, it will AC_MSG_ERROR.
Quote
LIBCURL_CFLAGS
C compiler flags for LIBCURL, overriding pkg-config
LIBCURL_LIBS
linker flags for LIBCURL, overriding pkg-config
C compiler flags for LIBCURL, overriding pkg-config
LIBCURL_LIBS
linker flags for LIBCURL, overriding pkg-config
My suggestions:
1) Only pkgconfig if LIBCURL_CPPFLAGS / LIBCURL_LIBS are NOT set
2) Move AC_CHECK_LIB *after* pkgconfig
3) Add LIBCURL_CPPFLAGS / LIBCURL_LIBS to CPPFLAGS / LDFLAGS before AC_CHECK_LIB and restore afterwards
Right now I basically can't compile cgminer against a statically linked libcurl.a
August 31, 2011, 04:01:23 PM
Sorry for being a PITA, but the ncurses bug is still there. The memleak seems to be gone in 1.6.1 though, it's been an hour already and the process is at 370M. Let's see if it leaks overnight or not. Also, it still doesn't build with older curl (at least make it fail at configure stage :-( ):
Thanks!
Quote
util.c:249: error: expected declaration specifiers or '...' before 'curlsocktype'
make[2]: *** [cgminer-util.o] Error 1
make[2]: *** [cgminer-util.o] Error 1
Thanks!
August 31, 2011, 12:12:42 PM
ok, I've been beating my head on this for 24 hours, figured I'd ask.
How do I get cgminer to log ONLY summary data, like "[(60s):1076.3 (avg):1070.2 Mh/s] [Q:146 A:115 R:3 HW:0 E:79% U:14.70/m] " to the syslog, and leave out the rest of the messages?
I'm remote-syslogging all my miners to a central syslog.. Even "Quiet" mode gives a lot more information than I want/need, at far more often than the configured interval. Example:
It would be nifty to have a "log-level" like syslogs levels for OUTPUT MODE:
0 Emergency: system is unusable
1 Alert: action must be taken immediately
2 Critical: critical conditions
3 Error: error conditions
4 Warning: warning conditions
5 Notice: normal but significant condition
6 Informational: informational messages
7 Debug: debug-level messages
Things like "DEAD GPU" would be 1 or 2, accepted could be 6, rejected could be 5, etc.
(while I'm asking, it would be nice to be able to pass "Facility" as a command-line option to the "--syslog" option... local3 for example)
Thanks again for a great program, hope there's an easy way to do what I'm asking..
How do I get cgminer to log ONLY summary data, like "[(60s):1076.3 (avg):1070.2 Mh/s] [Q:146 A:115 R:3 HW:0 E:79% U:14.70/m] " to the syslog, and leave out the rest of the messages?
I'm remote-syslogging all my miners to a central syslog.. Even "Quiet" mode gives a lot more information than I want/need, at far more often than the configured interval. Example:
Quote
Aug 31 10:08:41 miner9 cgminer[2681]: GPU 2 Q:29 A:20 R:1 HW:0 E:69% U:7.10/m
Aug 31 10:08:42 miner9 cgminer[2681]: GPU 0 Q:27 A:22 R:1 HW:0 E:81% U:7.81/m
Aug 31 10:08:47 miner9 cgminer[2681]: GPU 2 Q:29 A:21 R:1 HW:0 E:72% U:7.46/m
Aug 31 10:08:47 miner9 cgminer[2681]: GPU 0 Q:27 A:23 R:1 HW:0 E:85% U:8.17/m
Aug 31 10:08:53 miner9 cgminer[2681]: [(60s):1074.0 (avg):1065.9 Mh/s] [Q:74 A:61 R:3 HW:0 E:82% U:15.98/m]
Aug 31 10:08:53 miner9 cgminer[2681]: GPU 0 Q:27 A:24 R:1 HW:0 E:89% U:6.29/m
Aug 31 10:08:56 miner9 cgminer[2681]: GPU 1 Q:11 A:18 R:1 HW:0 E:164% U:4.72/m
Aug 31 10:09:11 miner9 cgminer[2681]: GPU 0 Q:27 A:25 R:1 HW:0 E:93% U:6.55/m
Aug 31 10:09:15 miner9 cgminer[2681]: GPU 0 Q:27 A:26 R:1 HW:0 E:96% U:6.81/m
Aug 31 10:09:25 miner9 cgminer[2681]: GPU 0 Q:27 A:27 R:1 HW:0 E:100% U:7.07/m
Aug 31 10:09:26 miner9 cgminer[2681]: GPU 2 Q:38 A:22 R:1 HW:0 E:58% U:5.76/m
Aug 31 10:09:28 miner9 cgminer[2681]: GPU 0 Q:27 A:28 R:1 HW:0 E:104% U:7.34/m
Aug 31 10:09:36 miner9 cgminer[2681]: GPU 1 Q:20 A:19 R:1 HW:0 E:95% U:4.98/m
Aug 31 10:09:50 miner9 cgminer[2681]: GPU 1 Q:20 A:20 R:1 HW:0 E:100% U:5.24/m
Aug 31 10:09:52 miner9 cgminer[2681]: GPU 1 Q:20 A:21 R:1 HW:0 E:105% U:5.50/m
Aug 31 10:09:53 miner9 cgminer[2681]: [(60s):1072.4 (avg):1067.0 Mh/s] [Q:92 A:71 R:3 HW:0 E:77% U:14.73/m]
Aug 31 10:09:53 miner9 cgminer[2681]: GPU 2 Q:38 A:23 R:1 HW:0 E:61% U:4.77/m
Aug 31 10:09:56 miner9 cgminer[2681]: GPU 0 Q:27 A:29 R:1 HW:0 E:107% U:6.02/m
Aug 31 10:08:42 miner9 cgminer[2681]: GPU 0 Q:27 A:22 R:1 HW:0 E:81% U:7.81/m
Aug 31 10:08:47 miner9 cgminer[2681]: GPU 2 Q:29 A:21 R:1 HW:0 E:72% U:7.46/m
Aug 31 10:08:47 miner9 cgminer[2681]: GPU 0 Q:27 A:23 R:1 HW:0 E:85% U:8.17/m
Aug 31 10:08:53 miner9 cgminer[2681]: [(60s):1074.0 (avg):1065.9 Mh/s] [Q:74 A:61 R:3 HW:0 E:82% U:15.98/m]
Aug 31 10:08:53 miner9 cgminer[2681]: GPU 0 Q:27 A:24 R:1 HW:0 E:89% U:6.29/m
Aug 31 10:08:56 miner9 cgminer[2681]: GPU 1 Q:11 A:18 R:1 HW:0 E:164% U:4.72/m
Aug 31 10:09:11 miner9 cgminer[2681]: GPU 0 Q:27 A:25 R:1 HW:0 E:93% U:6.55/m
Aug 31 10:09:15 miner9 cgminer[2681]: GPU 0 Q:27 A:26 R:1 HW:0 E:96% U:6.81/m
Aug 31 10:09:25 miner9 cgminer[2681]: GPU 0 Q:27 A:27 R:1 HW:0 E:100% U:7.07/m
Aug 31 10:09:26 miner9 cgminer[2681]: GPU 2 Q:38 A:22 R:1 HW:0 E:58% U:5.76/m
Aug 31 10:09:28 miner9 cgminer[2681]: GPU 0 Q:27 A:28 R:1 HW:0 E:104% U:7.34/m
Aug 31 10:09:36 miner9 cgminer[2681]: GPU 1 Q:20 A:19 R:1 HW:0 E:95% U:4.98/m
Aug 31 10:09:50 miner9 cgminer[2681]: GPU 1 Q:20 A:20 R:1 HW:0 E:100% U:5.24/m
Aug 31 10:09:52 miner9 cgminer[2681]: GPU 1 Q:20 A:21 R:1 HW:0 E:105% U:5.50/m
Aug 31 10:09:53 miner9 cgminer[2681]: [(60s):1072.4 (avg):1067.0 Mh/s] [Q:92 A:71 R:3 HW:0 E:77% U:14.73/m]
Aug 31 10:09:53 miner9 cgminer[2681]: GPU 2 Q:38 A:23 R:1 HW:0 E:61% U:4.77/m
Aug 31 10:09:56 miner9 cgminer[2681]: GPU 0 Q:27 A:29 R:1 HW:0 E:107% U:6.02/m
It would be nifty to have a "log-level" like syslogs levels for OUTPUT MODE:
0 Emergency: system is unusable
1 Alert: action must be taken immediately
2 Critical: critical conditions
3 Error: error conditions
4 Warning: warning conditions
5 Notice: normal but significant condition
6 Informational: informational messages
7 Debug: debug-level messages
Things like "DEAD GPU" would be 1 or 2, accepted could be 6, rejected could be 5, etc.
(while I'm asking, it would be nice to be able to pass "Facility" as a command-line option to the "--syslog" option... local3 for example)
Thanks again for a great program, hope there's an easy way to do what I'm asking..
August 31, 2011, 11:58:11 AM
This has probably already been answered but honestly.... some people have better things to do than re-read 60 pages of a thread.
When I use cryptopp_asm32 mode for the CPU miner, I get ridiculously wrong values for the hash rate - things like 150 MH/s, wildly fluctuating up and down and the 5 sec average frequently displaying Nan. Is there a bug in the rate calculation for that algorithm?
I'd say the cryptopp_asm32 on windows is likely broken.When I use cryptopp_asm32 mode for the CPU miner, I get ridiculously wrong values for the hash rate - things like 150 MH/s, wildly fluctuating up and down and the 5 sec average frequently displaying Nan. Is there a bug in the rate calculation for that algorithm?
I'm seeing the same wildly inaccurate hash rate reporting on Linux with cryptopp_asm32 as well. it looks like this is just the reporting though as the pool is reporting normal values from my miner.
Agreed, it seems to be fine from the pool side but the reporting is way off.
ckolivas, any idea what needs to be done to fix this? I'm happy to take a look and submit a pull request if I can fix the problem.
Jump to: