cpuminer-opt now supports hmq1725 on Windows on CPUs with AES_NI or SSE2. Linux works as usual. cpuminer-opt v3.3 is released with support for Windows using mingw_w64 and msys. See README.md for build instructions for Windows including how to install msys and mingw_w64. https://drive.google.com/file/d/0B0lVSGQYLJIZVjdDNVlpb05iUDQ/view?usp=sharing- Windows support added for all algos. - hodl algo for CPUs without AES_NI is not supported on Windows in this release. - New build instructions for Windows requires msys and mingw_W64, see README.md for details. - No prebuilt binaries are available, you must compile yourself. - Cross compiling is not supported, you must compile on the system you mine with. |
|
|
|
cpuminer-opt now supports hodl on Windows for CPUs with AES_NI. Linux works as usual. cpuminer-opt v3.3 is released with support for Windows using mingw_w64 and msys. See README.md for build instructions for Windows including how to install msys and mingw_w64. https://drive.google.com/file/d/0B0lVSGQYLJIZVjdDNVlpb05iUDQ/view?usp=sharing- Windows support added for all algos. - hodl algo for CPUs without AES_NI is not supported in this release. - New build instructions for Windows requires msys and mingw_W64, see README.md for details. - No prebuilt binaries are available, you must compile yourself. - Cross compiling is not supported, you must compile on the system you mine with. |
|
|
|
cpuminer-opt now supports Windows. Lunux works as usual. The same source tarball is used for both. cpuminer-opt v3.3 is released with support for Windows using mingw_w64 and msys. See README.md for build instructions for Windows including how to install msys and mingw_w64. https://drive.google.com/file/d/0B0lVSGQYLJIZVjdDNVlpb05iUDQ/view?usp=sharing- Windows support added for all algos. - hodl algo for CPUs without AES_NI is not supported on Windows in this release. - New build instructions for Windows requires msys and mingw_W64, see README.md for details. - No prebuilt binaries are available, you must compile yourself. - Cross compiling is not supported, you must compile on the system you mine with. |
|
|
|
I'm installing winbuilds now, will report on my results.
Edit; I've looked over your comit and I have a couple of questions. Why no #endif?
Most of the changes are related to the use of asm by changing it to __asm__ for windows.
But in algo/groestl/sse2/grso-asm.c you made the change unconditional. I also find it
peculiar that some of the code with the asm syntax previously compiled on Windows.
Why is this change necessary?
Edit2: I downloaded your code but there are files missing, most noticeably configure. What's up with that?
Edit3: Nevermind, I've got something better going with my own version, only have to disable hold for non AES_NI.
Regarding the #endif. That was a mistake. I compiled without any conditional statements but when putting it up on github I added them and overlooked adding the #endif to the statements. Same thing with grso-asm.c, I just missed adding the statements all together. These issues have now been dealt with on github. Regarding files missing, I cloned hmage's source from github so I have the same files that he put up there. I've made progress but there are still issues.
I found a solution to the makefile issue that does not require a workaround.
I can compile on real HW, however, it requires a small procedure change for windows.
Unfortunately the display issue remains. Not only is the newline missing but the hash units are also missing
from the output. This does not occur in the startup text, only the mining output.
Still working on it.
Good luck on getting it working. I look forward to seeing what you can do with it! Thanks. Your changes were still useful. I used the #if defined(_WIN64)... and added windows.h as you did. I only checked for _WIN64 and __WINDOWS__. I don't care about _WIN32 and don't know what the other one is. |
|
|
|
I'm making good progress with Windows. I've got a VM running Win8.1 with msys and mingw-w64 installed.
cpuminer-opt v3.2.5 compiled with only a few minor changes. It is currently mining hodl with AES_NI.
Non AES_NI hodl code does not compile in Windows. A quick solution is not apparent so I will likely release
with non AES_NI hodl disabled.
A small change is required to makefile.am to remove linker references to boost. A workaround I am considering
is a seperate build.sh file and a different manual build procedure for Windows. I'm getting a sense of deja-vu, there
was a discussion about boost earlier in this thread I'll have to revisit.
The miner runs directly from the msys shell but it does not display newlines so all output is on one long contnuous
line. I don't know if it's something in the code or a problem with msys. It does not run at this time from
a windows shell due to missing packages including C++ Redistributable 2008 and openssl.
Tomorrow I will try it on a physical machine and work out what extra packages I need to get it working from the Windows
shell and document the process.
The test matrix just grew another dimension but I hope to get a nearly fully functional multi platform release in a couple
of days. I will make no attempt to distribute binaries at this time.
I've made progress but there are still issues. I found a solution to the makefile issue that does not require a workaround. I can compile on real HW, however, it requires a small procedure change for windows. Unfortunately the display issue remains. Not only is the newline missing but the hash units are also missing from the output. This does not occur in the startup text, only the mining output. Still working on it. Edit: The hashrate display is fixed. I can run cpuminer from a windows command prompt on my i7 but not on my core2. I can run from an msys shell on both. I might have done something differently on each system. It's just about ready for release. I need to ensure nothing broke on Linux then merge the Windows changes back to the main stream and do a thourough test. |
|
|
|
I might consider it for your own private study, but open?
Private kernals are killing the coins. Publish some optimalizations and keep the wolf magic private... I'm with SP on this one. The code should eventually be open. As a miner the model I prefer is the bounty or donation system where the early adopters get exclusivity for a limited time. Then the code is opened. It attracts the big miners who can pay more and still be relatively cheaper due to scale. Everybody is happy. The dev gets paid, The big miners get a head start with the new code and the small miners don't have worry about ROI taking a year. |
|
|
|
|
I'm making good progress with Windows. I've got a VM running Win8.1 with msys and mingw-w64 installed.
cpuminer-opt v3.2.5 compiled with only a few minor changes. It is currently mining hodl with AES_NI.
Non AES_NI hodl code does not compile in Windows. A quick solution is not apparent so I will likely release
with non AES_NI hodl disabled.
A small change is required to makefile.am to remove linker references to boost. A workaround I am considering
is a seperate build.sh file and a different manual build procedure for Windows. I'm getting a sense of deja-vu, there
was a discussion about boost earlier in this thread I'll have to revisit.
The miner runs directly from the msys shell but it does not display newlines so all output is on one long contnuous
line. I don't know if it's something in the code or a problem with msys. It does not run at this time from
a windows shell due to missing packages including C++ Redistributable 2008 and openssl.
Tomorrow I will try it on a physical machine and work out what extra packages I need to get it working from the Windows
shell and document the process.
The test matrix just grew another dimension but I hope to get a nearly fully functional multi platform release in a couple
of days. I will make no attempt to distribute binaries at this time.
|
|
|
|
Why? You don't need to self-compile - multiple CPU instruction sets can be supported by branching at runtime.
Simple answer I din't know you could and don't know how. Many precompiled cpu miners come with multiple EXEs in the package targetted to different architectures, yours only support AES_NI and cpuminer-multi doesn't use any SSE2 or AES_NI optimizations. It's hard to find an example to copy. Probably so much the better - I wouldn't want any botnet doing that and getting actually good hashrates (at least without cutting me in.) That was my other reason. Even When I do get windows working I haven't decided whether to release binaries. |
|
|
|
I'm installing winbuilds now, will report on my results. Edit; I've looked over your comit and I have a couple of questions. Why no #endif? Most of the changes are related to the use of asm by changing it to __asm__ for windows. But in algo/groestl/sse2/grso-asm.c you made the change unconditional. I also find it peculiar that some of the code with the asm syntax previously compiled on Windows. Why is this change necessary? Edit2: I downloaded your code but there are files missing, most noticeably configure. What's up with that? Edit3: Nevermind, I've got something better going with my own version, only have to disable hold for non AES_NI. |
|
|
|
Why? You don't need to self-compile - multiple CPU instruction sets can be supported by branching at runtime.
Simple answer I din't know you could and don't know how. Many precompiled cpu miners come with multiple EXEs in the package targetted to different architectures, yours only support AES_NI and cpuminer-multi doesn't use any SSE2 or AES_NI optimizations. It's hard to find an example to copy. |
|
|
|
Hi, can someone explain for the algo's with more than 1 coin.. how it works if BTC exchanging is disabled?
Use the address of the coin you want to mine as your user. |
|
|
|
I think so. but not absolute sure about that. BTW! Does anyone get into supranova pool? Been busy for a couple of days and fell behind reading this thread. cpuminer-opt works with 64 bit CPUs with AES_NI and with only SSE2 but you only get the high speed if the CPU has AES_NI. It will tell you at startup what it is using. But this only applies if you compile it yourself for your architecture. Precompiled binaries only support one architecture. A non AES_NI would need to be compiled on CPUs like the core2 or some lower end Celerons. If it compiles on Windows for AES_NI it should also compile for SSE2. I always recommend compiling yourself for best performance. I am thrilled that ctgiant has it working with mingw, no propriatary software required. I fully support ctgiant and his efforts to open up cpuminer-opt to windows users and will follow up with the hodl issue. It appears hodl fails to compile with newer versions of gcc, probaly the reason it didn't work for ctgiant. |
|
|
|
GCC/G++ version 6.1.1?
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4 What Linux version did you use? When I have the time I'll build a VM to reproduce the problem. |
|
|
|
|
Found a problem with ccminer SP_MOD. Ctrl C doesn't work when the miner is in a reconnect loop.
I was mining a pool when the stratum server crashed and the miner when into the 30 second retry
loop. I hit Ctrl C several times but the miner would never exit, just kept looping. I had to close the
shell.
It happened with two different versions of ccminer (1.5.72 7 1.5.78), both on Windows. Linux exitted properly.
|
|
|
|
|
Didn't read all the posts so excuse me if this has been said.
Get the official report from Verizon and forward it to AMD and tell them you want new cards that
don't emit EMI. Don't forget to mention that your GPUs are a source of revenue which you are no
longer making.
|
|
|
|
Those issues have nothing to do with the coin itself, they have to do with this pool, is that what you are referring to as dodgy??
Anything to do with that coin, trading, mining, anything should be done with caution. And it could be the coin itself. I don't know why two branches of a fork were validating the same block numbers but I can think of two possibilities and one of them is not good for the coin. Since you seem to be taking this personally I'm done discussing this issue. Edit: Ijust noticed your sig now. I should have realized eralier that it was a personal matter for you. I also think, if you're british your interpretation of "dodgy" is more nefarious. Didn't mean to offend. No offense, I was asking to see if there was an issue with the coin I could help solve. and wanted to know if it was FUD or not. I can assure you the issue is purely related to this pool. They have not updated to the latest wallet, and have been given notice a few times here to do so. they don't give any other means of contacting them, so until they decide to make the change, they will continue mining on a fork. Check your PM. I hear you about the management of the pool. No one really knows if the admin ever reads the thread he created. People, including coin devs advising of bew wallets, post here assuming someone is reading. Any help is provided by the users. By looking at the web page (before it went down) and all the disabled coins one has to wonder what is going on behind the scenes. |
|
|
|
Those issues have nothing to do with the coin itself, they have to do with this pool, is that what you are referring to as dodgy??
Anything to do with that coin, trading, mining, anything should be done with caution. And it could be the coin itself. I don't know why two branches of a fork were validating the same block numbers but I can think of two possibilities and one of them is not good for the coin. Since you seem to be taking this personally I'm done discussing this issue. Edit: Ijust noticed your sig now. I should have realized eralier that it was a personal matter for you. I also think, if you're british your interpretation of "dodgy" is more nefarious. Didn't mean to offend. |
|
|
|
Your HOdl is broke - on linux, and probably on every platform. You put a WHOLE lot of wasteful C++ garbage in, butchering my HOdl code - also breaking the compile.
What version? That wastefull c++ code is to support non AES_NI. I'm currently using 3.2.3 and I made no changes to hodl in 3.2.4 or 3.2.5. Just compiled and ran 3.2.5, no porblem. I tried the version linked in the OP - and you know, you can do a non-AES-NI version really simply with a lookup table... or a few, for speed. I'l download it and give it a try. Edit: downloaded, compiled and runs ok on hodl. GCC/G++ version 6.1.1? gcc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4 Oh lord that's old. Probably why. The new compoiler should be backward compatible, or have a compatibility switch. If not it's pretty inconsiderate of them to break existing code. There are a lot of implicit function declarations in my code, did you set the option to allow them? I'm still undecided on whether to leave them ro make it easier to add new algos, or require every algo's registration function be defined in algo-gate-api.h. It actually dies in C++ headers somewhere. I was going to fix it, but then I looked at what was causing it and realized that all that inefficient C++ wasn't actually needed at all, so pointed it out. So the problem is not in your code but in the non AES_NI version. Is the error easy to fix, I'll do it if you send me the info. |
|
|
|
Your HOdl is broke - on linux, and probably on every platform. You put a WHOLE lot of wasteful C++ garbage in, butchering my HOdl code - also breaking the compile.
What version? That wastefull c++ code is to support non AES_NI. I'm currently using 3.2.3 and I made no changes to hodl in 3.2.4 or 3.2.5. Just compiled and ran 3.2.5, no porblem. I tried the version linked in the OP - and you know, you can do a non-AES-NI version really simply with a lookup table... or a few, for speed. I'l download it and give it a try. Edit: downloaded, compiled and runs ok on hodl. GCC/G++ version 6.1.1? gcc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4 Oh lord that's old. Probably why. The new compoiler should be backward compatible, or have a compatibility switch. If not it's pretty inconsiderate of them to break existing code. There are a lot of implicit function declarations in my code, did you set the option to allow them? I'm still undecided on whether to leave them ro make it easier to add new algos, or require every algo's registration function be defined in algo-gate-api.h. |
|
|
|
what exactly is Dodgy about DNET, explain
You've been around long enough, are you being deliberately obtuse? Anyway, party's over, HP went down again and I don't expect it to some back with 175 DNET blocksize, if at all. someone likely got stiffed. deliberately obtuse? No, I am asking you to explain why YOU think there is something dodgy about DNET. You made the statement, but I have yet to see any supporting facts as to why you made the statement.. Haven't you read anything I've written, or you have written in the past 2 days? |
|
|
|
|
Show Posts
