I built the win64 version of the AMD gpu miner.
done, i built mine with mingw-w64 linux but i needed to add ws2_32 lib else it fails test on win7 x64, latest 15.7.1 catalyst On start there are some errors : ".\groestl256.cl", line xxx : warning: integer conversion resulted in a change
of sign
C64e(0x2a86ef4343692aef), C64e(0xf193a6c4c435f1a6),
^ Where xxx could be up to 303 and down to at least 225 (I can get the full output if needed). idem Also, this : "C:\Users\Richard\AppData\Local\Temp\OCL5F33.tmp.cl", line 228: warning: argument of
type "uchar *" is incompatible with parameter of type "uint *"
AESExpandKey256(ExpandedKey1);
not seen but not sure, i perhaps miss it And finally the results with the following config are 410H/s for a 7950 : {
"Algorithms":
[
{
"name": "AEON",
"devices":
[
{
"index": 0,
"corefreq": 925,
"memfreq": 1250,
"fanspeed": 65,
"powertune": 20,
"threads": 1,
"rawintensity": 1024,
"worksize": 16
}
],
}
]
}
Same conf, 475H/s It seems going above 1024 makes the system unstable. Also I don't know what is the worksize param.
Anyone willing to share results ?
EDIT: It also crashes after some time with those parameters. The AMD driver crashes and miner stops.
on the first attempt, one minute of accepted then no crash but all rejected and ban... second attempt, shares accepted but a few minutes later, shares found aren't sent to the pool. no new job received (job id didn't change) no crash but no communication between miner and pool. like BoscoMurray complain Anyone else have an issue with the new AMD miner in that it does start hashing, confirmed by hashrate on the pool, but after a while seems to stop finding/submitting shares?
The miner appear to be hashing, but the pool hashrate drops to zero. Is there some way to turn on logging?
Cheers
Bosco
proof of concept is ok but not usable for now |
|
|
|
I built the win64 version of the AMD gpu miner.
i've tried a cross-compilation from linux (x86_64-w64-mingw32-gcc 4.9) but it fails log.c: In function ‘Log’:
log.c:19:3: warning: implicit declaration of function ‘time’ [-Wimplicit-function-declaration]
time(&rawtime);
^
log.c:20:3: warning: implicit declaration of function ‘localtime’ [-Wimplicit-function-declaration]
curtime = localtime(&rawtime);
^
log.c:20:11: warning: assignment makes pointer from integer without a cast
curtime = localtime(&rawtime);
^
log.c:21:3: warning: implicit declaration of function ‘strftime’ [-Wimplicit-function-declaration]
strftime(timebuf, 128, "[%H:%M:%S] ", curtime);
^
log.c:21:3: warning: incompatible implicit declaration of built-in function ‘strftime’
net.c: In function ‘ConnectToPool’:
net.c:53:3: warning: overflow in implicit constant conversion [-Woverflow]
return(INVALID_SOCKET);
^
net.c:61:3: warning: overflow in implicit constant conversion [-Woverflow]
return(INVALID_SOCKET);
^
net.c:77:3: warning: overflow in implicit constant conversion [-Woverflow]
return(INVALID_SOCKET);
^
then net.o: dans la fonction « NetworkingInit »:
/wolf-aeon-miner/net.c:26: référence indéfinie vers « __imp_WSAStartup »
net.o: dans la fonction « NetworkingShutdown »:
/wolf-aeon-miner/net.c:33: référence indéfinie vers « __imp_WSACleanup »
net.o: dans la fonction « ConnectToPool »:
/wolf-aeon-miner/net.c:48: référence indéfinie vers « __imp_getaddrinfo »
/wolf-aeon-miner/net.c:56: référence indéfinie vers « __imp_socket »
/wolf-aeon-miner/net.c:60: référence indéfinie vers « __imp_freeaddrinfo »
/wolf-aeon-miner/net.c:66: référence indéfinie vers « __imp_connect »
/wolf-aeon-miner/net.c:76: référence indéfinie vers « __imp_freeaddrinfo »
/wolf-aeon-miner/net.c:80: référence indéfinie vers « __imp_freeaddrinfo »
net.o: dans la fonction « SetNonBlockingSocket »:
/wolf-aeon-miner/net.c:96: référence indéfinie vers « __imp_ioctlsocket »
main.o: dans la fonction « PoolBroadcastThreadProc »:
/wolf-aeon-miner/main.c:189: référence indéfinie vers « __imp_send »
main.o: dans la fonction « StratumThreadProc »:
/wolf-aeon-miner/main.c:998: référence indéfinie vers « __imp_send »
/wolf-aeon-miner/main.c:1024: référence indéfinie vers « __imp_select »
/wolf-aeon-miner/main.c:1026: référence indéfinie vers « __WSAFDIsSet »
/wolf-aeon-miner/main.c:1033: référence indéfinie vers « __imp_recv »
/wolf-aeon-miner/main.c:1056: référence indéfinie vers « __imp_closesocket »
/wolf-aeon-miner/main.c:1160: référence indéfinie vers « __imp_closesocket »
main.o: dans la fonction « main »:
/wolf-aeon-miner/main.c:1875: référence indéfinie vers « __imp_closesocket »
collect2: error: ld returned 1 exit status
Makefile:8: recipe for target 'all' failed
make: *** [all] Error 1
i give up i will try windows native compilation later |
|
|
|
|
@BoscoMurray: thanks for feedback and good test. i edit my previous instructions
|
|
|
|
I'm on Mint 17.2. I've installed GCC 4.9 and followed your instructions, but get this after running make: ...../wolf-aeon-miner/main.c:735: undefined reference to `clCreateCommandQueueWithProperties'
collect2: error: ld returned 1 exit status Hi There, I had the same thing. I think this points to having an older openCL sdk installed than is required. It is possible to build it using by changing the function names to that used in the older openCL releases, and it does link and build. But then the actual opencl code give errors during execution. Probably best to upgrade to latest SDK (note - I haven't because it was such a pain to do it on my headless rig, and it's nice and stable mining other currencies at the moment). Cheers Dave just a guess, it seems that gcc takes libOpenCL directly at /usr/lib/fglrx/libOpenCL.so (from fglrx package) instead of ./lib/x86_64/libOpenCL.so (from AMDAPPSDK-3.0 extraction) i compiled from a system without fglrx and i didn't have this error. try to force using ./lib/x86_64/libOpenCL.so with -Wl,./lib/x86_64/libOpenCL.so to LIBS in the makefile. CC = gcc
LD = gcc
CFLAGS = -D_POSIX_SOURCE -D_GNU_SOURCE -O0 -ggdb3 -std=c11 -pthread -c -I./include/
LDFLAGS = -pthread -O0 -ggdb3
LIBS = -ljansson -Wl,./lib/x86_64/libOpenCL.so -ldl you can also try to use libOpenCL.so1 instead of libOpenCL.so but i don't think it will be necessary. |
|
|
|
i was able to compile it but i can't test (no amd gpu available on linux at the moment, my last ring is performing windows tests) what i did: (Ubuntu 15.04 64-bit, gcc 4.9.2) clone wolf's repository git clone https://github.com/wolf9466/wolf-aeon-miner.git donwload AMD APP SDK 3.0 for 64-bit Linux here : http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/untar it tar -jxvf AMD-APP-SDKInstaller-v3.0.124.132-GA-linux64.tar.bz2 and execute the shell script AMD-APP-SDK-v3.0.124.132-GA-linux64.sh ./AMD-APP-SDK-v3.0.124.132-GA-linux64.sh you now have a folder AMDAPPSDK-3.0 copy AMDAPPSDK-3.0/include and AMDAPPSDK-3.0/lib into wolf-aeon-miner folder  in the makefile add -I./include/ to CFLAGS and -L./lib/x86_64/ to LIBS
CC = gcc
LD = gcc
CFLAGS = -D_POSIX_SOURCE -D_GNU_SOURCE -O0 -ggdb3 -std=c11 -pthread -c -I./include/
LDFLAGS = -pthread -O0 -ggdb3
LIBS = -ljansson -L./lib/x86_64/ -lOpenCL -ldl
[EDIT] force use of libOpenCL.so from AMDAPPSDK-3.0 with -Wl,./lib/x86_64/libOpenCL.so ) instead of -L./lib/x86_64/ in the makefile add -I./include/ to CFLAGS and -Wl,./lib/x86_64/libOpenCL.so to LIBS (or -Wl,./lib/x86_64/sdk/libOpenCL.so according to your paths) to LIBS, -lOpenCL can be deleted CC = gcc
LD = gcc
CFLAGS = -D_POSIX_SOURCE -D_GNU_SOURCE -O0 -ggdb3 -std=c11 -pthread -c -I./include/
LDFLAGS = -pthread -O0 -ggdb3
LIBS = -ljansson -Wl,./lib/x86_64/libOpenCL.so -ldl or LIBS = -ljansson -Wl,./lib/x86_64/sdk/libOpenCL.so -ldl run and it must be OK. in aeon.conf, change url pool an user then launch with feedback appreciated, i can't test myself. |
|
|
|
i added : "fixedDiff": {
"enabled": true,
"separator": "."
},in my config file (i deleted the comma just after "separator": "." to prevent syntax error) i tried "fixedDiff": {
"enabled": true,
"minDiff": 100,
"separator": "."
},without success |
|
|
|
patch applied (and max diff increased at 500k BTW) but unfortunately fixed diff (with address.diff as login) are not accepted by the pool  "Stratum authentication failed" something is missing. i investigate, for now the pool is still running as usual with var diff only. |
|
|
|
sad to hear this... binaries from untrusted source are a calamity |
|
|
|
Arux, it appears that your pool may be limiting the difficulty to 20000. It may be beneficial to turn that off - or dramatically increase it (500k?). I know one of my Xeon machines can sustain about 200k.
few weeks ago i lowered max difficulty from 100k to 20k because someone had trouble when difficulty spike to 100k (loss of hashrate) i will look if i can patch the pool to authorize fixed difficulty on miner client. that way, each miner will be able to choose a difficulty matching to his hashrate (or let the pool manage it) |
|
|
|
I updated the OP with a reformat from myagui. Thanks for the help!
To me it looks a lot better, but feedback is welcome. Also I didn't double check the content of the edits so if there are any errors, please let me know and I'll fix them.
Thanks myagui, clean job, OP nice to read. |
|
|
|
|
Chainradar is on the correct chain. I notice it only now.
Someone knows since how many times are they ?
|
|
|
|
I'm not sure how Arux is compiling the non-AES cpuminer for Windows, but it's mentioned that mooo's source tree was used: https://github.com/moneromooo/cpuminer-multiI would think it should work with both AES-NI and non-AES systems, although I have never tested w/o AES-NI. That is the one that only has only a README file in it.... you will have to forgive me my linux is rusty but it's coming back, I have and do quite a bit of mining using linux but I'm struggling on this for some reason. Any help is appreciated. btw I ran the following : wget https://github.com/Arux-BTT/CPUMiner-Multi-cryptonight-light/archive/04082015.tar.gztar zxvf 04082015.tar.gz Then shows only as README.md under ls command.....I imagine I'm just forgetting something, but I did compile the one for AES-NI just fine, however it was a .git file and not a .tar file ...  for wolf's version, i used https://github.com/moneromooo/cpuminer-multi. cross-compiled from linux for win64. AES-NI was configured as usual (aka nothing particular), non AES-NI was configured with --disable-aes-ni if you use non AES miner on AES cpu, you will lose AES optimisations! (not tested but it will be very slower) if you use AES miner on non AES cpu, it fails. for lucasjones version, i used https://github.com/iamsmooth/cpuminer-multicross-compiled from linux for win64 too. |
|
|
|
|
52.8.47.33:8080 not affected, daemon is still 0.9.1.1
|
|
|
|
@smooth: I used Boost 1.59 for the aeon-light test binaries. Should we expect trouble anytime we switch between binaries that were compiled on different Boost versions?  If that's the case, I'd appreciate some official direction as to what version to use, so that I'd always use the same as anyone that will produce official binaries, thus preventing similar complications in the future. Thanks! I'm not sure, as I was only vaguely aware of this issue, and the boost documentation is rather poor. Looking in the release notes, I see nothing about version incompatibility since 1.45, which is quite old (none of the AEON builds would have used something older than that right?): http://www.boost.org/doc/libs/1_59_0/libs/serialization/doc/release.htmlSo I don't see a good reason for the "unsupported version" failure to occur at all. Maybe there is another explanation. Still, let's get Arux to report on the boost version being used for the official Windows builds and people can try to use the same version for unofficial builds as well. Official 0.9.1.1 windows binaries were compiled with boost 1.58 static i don't have more explanations than smooth |
|
|
|
|
There is a bug in the payment module of my pool. One miner is affected now. He's not paid since several days now. I'm aware of the problem and i will investigate ASAP
The coin are safe (but in the wallet pool, not in his personal wallet) His pending balance show correct information (the pool must paid to him this balance). My apologies for the delay.
[edit] 01/09/15, solved. there's no more pending balance above 0.5 . Payment module is Ok.
|
|
|
|
Can somebody give me a brief summary of what I need to do to set up a pool. I've done it a few times before (for XMR) but I'm not really up on which versions of the code to use for AEON, any patches needed, etc.
Post if you feel it is of general interest, otherwise PM.
Thanks!
An important point: node v0.12 don't work. You must use node v0.10 else the compil fails. With node v0.10 compiling and running the pool is ok. (Type node -v to check your node version) |
|
|
|
Hi! I'm back at home. Today i will be busy with my day job (to explain my vacation at my office colleagues  ) but shortly i could active here. |
|
|
|
Arux's pool appears to be down. If you are using it you will want to switch somewhere
Front-end was down but core was always running. No shares were lost. Payments are OK. Cheers. (Internet onnections are quite impossible here  ) |
|
|
|
time for vacation  i will be AFK until september because mountain biking   i'm keeping an eye on http://52.8.47.33:8080. where i go there's no computer and access to internet is sometimes unpredictable but with smartphone and cellular network i will be able to connect server, monitor the pool and relaunch process if needed. see you soon! |
|
|
|
thanks for your report. i will look closer why it's not working as expected. |
|
|
|
|
Show Posts
