if the maturation block reaches before 365 days will the hodls will be un-hodled(matured)  I would assume yes since the date is only an estimate. |
|
|
|
There are no command line parameters to worry about except the number of threads. 300 KH/s seems low for an 8 core @ 4 GHz, I get 575 on my i7-6700K. Your CPU supports both AES and AVX so if the miner is properly compiled it should use the optimized hasher. Just to confirm, did you download cpuminer-opt from here? http://cryptomining-blog.com/7930-windows-binaries-for-the-cpuminer-opt-3-3-5-cpu-miner/Also what was displayed on start up regarding CPU capabilities and optimization? Post the output if you can. Yes, I downloaded it from that source, lol here is what it looks like right now while working... i'm using 7 cores instead of 8  As you can see it is really sluggish but I have a wallet syncing in the background. Here is the start screen https://ctrlv.cz/Q9iLStartup looks good. Wallet synching can slow it down. Wait till that's done then close the wallet. Check your CPU usage to make sure nothing else is taking time. |
|
|
|
Wolf0 if you are not interested to optimize miner, what is the reason for your famous person to post in this thread? Investments, free time for spending or ? I don't want to be rude, just curiosity.  Because I came to the thread and looked over the SGMiner to think about it. Decided not to at this time. will you optimize the cpuminer？ I already optimized the cpuminer, doubled the speed. What is the optimum commandline parameter in the batch for an FX 8350? I'm using cpuminer-amd.exe -t 7 -s 3 ..... Is there anything i'm missing because i'm only getting 300KH/s, is this the optimum speed? There are no command line parameters to worry about except the number of threads. 300 KH/s seems low for an 8 core @ 4 GHz, I get 575 on my i7-6700K. Your CPU supports both AES and AVX so if the miner is properly compiled it should use the optimized hasher. Just to confirm, did you download cpuminer-opt from here? http://cryptomining-blog.com/7930-windows-binaries-for-the-cpuminer-opt-3-3-5-cpu-miner/Also what was displayed on start up regarding CPU capabilities and optimization? Post the output if you can. |
|
|
|
|
More cryptonight progress.
If I can't make the stack bigger use less.
I made the definition of ctx global instead of local and it doesn't crash. Just testing on a live pool
to confirm.
If all goes well I should have it fixed by the end of the day.
Edit: My optimism was premature. Although the AES version doesn't crash it produces only rejects.
And a non-AES compile still crashes.
|
|
|
|
3. Mining functions for CPU + GPU now built into the client, they are not up to par where we'd like them but they function and due to this update already being HORRIBLY delayed we will be launching it with the limitations. (no drop down select for GPU model yet).
(...)
Today I'm personally stuck at my day job for most of the day, afterwords we will run some final tests (not releasing anything buggy) and then we will finally release this long overdue client.
(...)
From now on we will be settings dates of completion and striving to meet them. You can expect a 2 week wait for 0.8.0.6 after the 0.8.0.5 is released soon.
in those two weeks we will polish everything up from the 0.8.0.5 stepping stone and finally be where we want to be.
Seriously guys, I am very thankful for your high ambitions but you have to understand what this means. There is always a trade-off between meeting the schedule, code quality and features. See https://en.wikipedia.org/wiki/Project_management_triangleWe all know that developing good software is hard. Also we are not your clients, we are just investors. This is your project. Please top apologizing for not meeting your own schedule all the time, or for not being able to work on it 24/7. We (at least I do) want you to make a high quality piece of software that kicks ass, and to take whatever time you need for that. Schedule is nice-to-have, but the project itself is way more important. If you see that you are not meeting the schedule, just update it. Get a bit more agile. It really just has informational purposes for the rest of us. I'll take your post to heart. I personally like treating this like a serious venture. Hence the annoyance at delays. In the future we'll be more agile as you say The old content, quality, schedule triangle, one of them always has to give. I choose schedule always and never apologogize for it. |
|
|
|
Wolf0 if you are not interested to optimize miner, what is the reason for your famous person to post in this thread? Investments, free time for spending or ? I don't want to be rude, just curiosity. Because I came to the thread and looked over the SGMiner to think about it. Decided not to at this time. will you optimize the cpuminer？ I already optimized the cpuminer, doubled the speed. |
|
|
|
But the problem is only on Windows, oh well.
msys comes with gdb, it should be able to catch the segfault, then you can inspect the registers, stack and variables. Compiling with "-O0 -g3" instead of "-O3" should help gdb give you more info. Tried that. Compile fails in another algo with -O0 asm has impossible constraints. Use -ggdb3 and step through it. Progress. If ___chkstk_ms is checking for stackoverflow then I know what the problem is. Looking for solutions, looks like a Makefile.am edit. Edit: doubling the stacksize spec in Makefile.am didn't work. if HAVE_WINDOWS #cpuminer_CFLAGS += -Wl,--stack,10485760 cpuminer_CFLAGS += -Wl,--stack,20971520 endif Edit2: I couldn't find any documentation for --stack so I don't know what makefile is doing. I found -fno-stack-limit but it still crashes at the same place. I know it's crashing in ___chkstak_ms and I assume that means a stack overflow. A corrupt stack pointer should not occur in compiled code. From my experience the stack limit is fixed when the process is created, I'm not aware of any way to increase that after process creation so there must be some overriding limit beyond the scope of the compiler. Most of the info I found deals with limiting the stack, not growing it. It seems infinite recursion is a bigger issue than legitimate large stack use. |
|
|
|
Crackfoo doing a test run with blakecoin algo.... pool showing 1.7 gh/s I'm mining at 11.7 gh/s. Is the readout wrong?
EDIT:To many pool problems ...I'm taking it out of my conf until pool is set better.
One is the blake algo readouts should be like other coins. Damn.
Myr-gr isn't showing on MC api..... just .0000000
*** values in mBTC/Mh/day (mBTC/Gh/day for sha256 and blake algos) |
|
|
|
|
Why?
Just get another Nvidia card.
|
|
|
|
interesting algo ...
any gpu miner around? ... namely for nvidia ( ccminer ) ...
#crysx
Not that anyone can confirm, possibly a canine is working on an AMD version, but no cuda AFAIK. There's already an AMD one out (not from me) - I'm pretty sure. And I thought mine was the fastest. Wait, you did an AMD one? No, the presence of an AMD miner meant my CPU miner was no longer the fastest. |
|
|
|
But the problem is only on Windows, oh well.
msys comes with gdb, it should be able to catch the segfault, then you can inspect the registers, stack and variables. Compiling with "-O0 -g3" instead of "-O3" should help gdb give you more info. Tried that. Compile fails in another algo with -O0 asm has impossible constraints. |
|
|
|
cpuminer-cpu-miner.o:cpu-miner.c:(.text+0x695a): undefined reference to `__stack_chk_fail'
cpuminer-cpu-miner.o:cpu-miner.c:(.text+0x6a8c): undefined reference to `__stack_chk_guard'
cpuminer-cpu-miner.o:cpu-miner.c:(.text+0x6c78): undefined reference to `__stack_chk_guard'
cpuminer-cpu-miner.o:cpu-miner.c:(.text+0x6d61): undefined reference to `__stack_chk_fail'
c:/msys/opt/windows_64/bin/../lib64/gcc/x86_64-w64-mingw32/4.8.3/../../../../x86_64-w64-mingw32/bin/ld.exe: cpuminer-cpu-miner.o: bad reloc address 0x0 in section `.pdata'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [cpuminer.exe] Error 1
I don't know what this means but it does mention pdata, an argument to the function that is failing. Cryptonight is coded the same as every other algo and every algo hash function references pdata the same way. It means that your build of gcc doesn't have stack protection support library (functions __stack_chk_fail() and __stack_chk_guard()). It builds fine on debian linux though. But the problem is only on Windows, oh well. |
|
|
|
You can enable gcc's stack protection.
-fstack-protector
Interesting, compile failed. cpuminer-cpu-miner.o:cpu-miner.c:(.text+0x695a): undefined reference to `__stack_chk_fail'
cpuminer-cpu-miner.o:cpu-miner.c:(.text+0x6a8c): undefined reference to `__stack_chk_guard'
cpuminer-cpu-miner.o:cpu-miner.c:(.text+0x6c78): undefined reference to `__stack_chk_guard'
cpuminer-cpu-miner.o:cpu-miner.c:(.text+0x6d61): undefined reference to `__stack_chk_fail'
c:/msys/opt/windows_64/bin/../lib64/gcc/x86_64-w64-mingw32/4.8.3/../../../../x86_64-w64-mingw32/bin/ld.exe: cpuminer-cpu-miner.o: bad reloc address 0x0 in section `.pdata'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [cpuminer.exe] Error 1
I don't know what this means but it does mention pdata, an argument to the function that is failing. Cryptonight is coded the same as every other algo and every algo hash function references pdata the same way. |
|
|
|
Cryptonight update.
As previously mentioned cryptonight is broken on Windows from v3.3 to present. Prior to that Windows was
not supported. Linux is not affected.
I have localized the problem to a simple function call that goes bad and crashes the miner. The line before
the call is executed but the first line of the called function is never reached.
This is a simple call to a constant function, nothing fancy, no algo-gate function pointers, just a basic call to the hash
function. It is the exact same code that runs fine on Linux. There are no OS hooks anywhere to be found.
It was first discovered in the CMB prebuilt binaries but I can easilly reproduce it with a different compiler version.
It's difficult to wrap my head around this kind of problem, especially when it's OS specific. The crash suggests the
function address was invalid. It seems either the compiler messed up linking the function address or it got overwritten
after compilation. c/c++ always scares me with the lack of built in buffer overflow protection. I'm not used to working
without a net. But even if there is a buffer overflow corrupting a function why only on Windows?
I'll review all the data defined in that file for anything suspicious but after that I'll be pretty stuck.
I LOVE that about C/C++. I've had religious debates with c/c++ proponents. My key argument is just to look at all the buffer overflow exploits that have existed over the years and continue to exist. Never would have happened with array bounds checking and no mixing of a[] and a*. |
|
|
|
I'm volunteering for testing.  Can test on AMD (SSE2, no AVX) both Windows and Linux, aswell on Core i7-4790K (AVX) on Linux and AMD FX-7600P (AVX) on Windows. Thanks, check your PM. Reports from four machines send via PM. Awesome report. It had everything I needed. Everything looks good from the CPU capabilities check. I saw no inconsistencies. The only issue I found was the mapping of -march=native on non-AES AMD CPUs. As a long known issue it is already documented in README.md. I'll review your data in more detail and may update the documented workaround based on the info you provided. I think this gives me enough confidence about the CPU capabilities check to release it, but I'll wait a while to give me a chance to look deeper into the cryptonight problem. |
|
|
|
Great job Joblo,
v.3.3.5 working like charm on Gainestown Xeon's with cpuminer-sse2.exe build.
Checking CPU capatibility...
Intel(R) Xeon(R) CPU E5540 @ 2.53GHz
CPU features: SSE2 AVX AVX2
SW built on Jun 5 2016 with GCC 5.3.0
Build features: SSE2
Algo features: SSE2 AES
AES not available, starting mining with SSE2 optimizations...
Thanks for testing. The erroneous display of AVX and AVX2 support for the CPU should be fixed in the next release. It's being tested now. Everything else looks good. |
|
|
|
|
Cryptonight update.
As previously mentioned cryptonight is broken on Windows from v3.3 to present. Prior to that Windows was
not supported. Linux is not affected.
I have localized the problem to a simple function call that goes bad and crashes the miner. The line before
the call is executed but the first line of the called function is never reached.
This is a simple call to a constant function, nothing fancy, no algo-gate function pointers, just a basic call to the hash
function. It is the exact same code that runs fine on Linux. There are no OS hooks anywhere to be found.
It was first discovered in the CMB prebuilt binaries but I can easilly reproduce it with a different compiler version.
It's difficult to wrap my head around this kind of problem, especially when it's OS specific. The crash suggests the
function address was invalid. It seems either the compiler messed up linking the function address or it got overwritten
after compilation. c/c++ always scares me with the lack of built in buffer overflow protection. I'm not used to working
without a net. But even if there is a buffer overflow corrupting a function why only on Windows?
I'll review all the data defined in that file for anything suspicious but after that I'll be pretty stuck.
|
|
|
|
I'm volunteering for testing. Can test on AMD (SSE2, no AVX) both Windows and Linux, aswell on Core i7-4790K (AVX) on Linux and AMD FX-7600P (AVX) on Windows. Thanks, check your PM. |
|
|
|
Thanks Barney. Thanks Joblo for making this cpuminer. Just a little reminder that CMB doesn't build any binaries for CPUs without AES. This includes core2 and nehalem and whatever the equivalent is for AMD. If you attempt to mine an AES optimized algo with one of these builds on a CPU without AES the miner will crash. However, cpuminer-opt does support these CPUs but you will need to compile cpuminer-opt yourself. Instructions for Windows and Linux are in README.md for those interested and help is always available the cpuminer-opt thread. Correction: CMB does now build a SSE2 binary that should work on Core2 and Nehalem CPUs. |
|
|
|
|
Show Posts
