cmake -DBUNDLE=cudaminer -DCOMPUTE=30 -DCUDA_HOST_COMPILER=/usr/bin/gcc-4.9 ..
worked on my testbench on 15.10 the server is still down need to try it there to.
i did a try on 16.04 but got som errors. used the same cmake a on 15.10
[ 11%] Built target ethash
[ 51%] Built target devcore
[ 57%] Built target ethstratum
[ 59%] Building NVCC (Device) object libethash-cuda/CMakeFiles/ethash-cuda.dir/ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o
[ 66%] Built target ethash-cl
nvcc fatal : redefinition of argument 'std'
CMake Error at ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o.cmake:207 (message):
Error generating
/home/mattias/cpp-ethereum/build2/libethash-cuda/CMakeFiles/ethash-cuda.dir//./ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o
libethash-cuda/CMakeFiles/ethash-cuda.dir/build.make:63: recipe for target 'libethash-cuda/CMakeFiles/ethash-cuda.dir/ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o' failed
make[2]: *** [libethash-cuda/CMakeFiles/ethash-cuda.dir/ethash-cuda_generated_ethash_cuda_miner_kernel.cu.o] Error 1
CMakeFiles/Makefile2:350: recipe for target 'libethash-cuda/CMakeFiles/ethash-cuda.dir/all' failed
make[1]: *** [libethash-cuda/CMakeFiles/ethash-cuda.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 66%] Built target BuildInfo.h
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2
Topic: ethminer-0.9.41-genoil-1.1 - page 68. (Read 397360 times)
But... The usual way will be generate DAG, verify (somehow), generate CRC, then write to disk
We don't have access to Claymore's code so no point assuming he's doing it the wrong way - after all he's in this crypto-miner business since... 3 years ago at least
We don't have access to Claymore's code so no point assuming he's doing it the wrong way - after all he's in this crypto-miner business since... 3 years ago at least
I'm not assuming he's doing it the wrong way. I was just trying to figure out an easy way to do something similar with the lowest amount of effort involved
. But on second thought you are right. CRC is very useful. The problem with my suggestion is that it would only validate DAG integrity upon finding a solution. It would not see that a solution was not found because of a corrupted DAG
But... The usual way will be generate DAG, verify (somehow), generate CRC, then write to disk
We don't have access to Claymore's code so no point assuming he's doing it the wrong way - after all he's in this crypto-miner business since... 3 years ago at least
We don't have access to Claymore's code so no point assuming he's doing it the wrong way - after all he's in this crypto-miner business since... 3 years ago at least
So the point in time where the chances of corrupting the file are highest is completely ignored? That doesn't sound very useful to me. It would be way more useful if the DAG CRC could be sent along with a solution to a node or pool and checked there against the CRC of the resident DAG file. Solution verification kind of already does that of course, but it can validate on nonce a while nonce b is borked.
When is the chance of corruption the highest?!IMO, CRC check on start is cheap & useful :/
So the point in time where the chances of corrupting the file are highest is completely ignored? That doesn't sound very useful to me. It would be way more useful if the DAG CRC could be sent along with a solution to a node or pool and checked there against the CRC of the resident DAG file. Solution verification kind of already does that of course, but it can validate on nonce a while nonce b is borked.
When is the chance of corruption the highest?!IMO, CRC check on start is cheap & useful :/
Donkeypool.com is looking for beta miners.
A new pool, donkeypool.com, needs a few miners for initial testing and we're also soliciting feedback for improvements.
Beta miners will mine for free until June 15th, 2016.
After launch, miners will pay a modest 0.5% fee (includes network fee) for pool costs, etc.
We will hopefully have the stratum protocol implemented by June 1.
So far, we've found 9 blocks and payouts are working as expected.
We'll be verifying EVERY PAYOUT to make sure it's fair and accurate.
We're not looking to get rich by hosting a pool, we just want fair trustworthy place to mine.
Genoil, you will mine for free for the life of the pool, just send me your address:)
The pool is built and managed by software engineers and network professionals with advanced firewall protection and redundancy.
Payouts run at noon everyday, with low payout (1 ETH) requirements, so there won't be a lot of ETH in the wallet to make it a target.
We will also be increasing the frequency of payouts as block-times decrease.
Here is the run-line for ethminer:
ethminer.exe --farm-recheck 500 -U -F http://donkeypool.com/coinbase_address/worker_name/hashrate_MH
AMD cards change the line to:
ethminer.exe --farm-recheck 500 -G -F http://donkeypool.com/coinbase_address/worker_name/hashrate_MH
A new pool, donkeypool.com, needs a few miners for initial testing and we're also soliciting feedback for improvements.
Beta miners will mine for free until June 15th, 2016.
After launch, miners will pay a modest 0.5% fee (includes network fee) for pool costs, etc.
We will hopefully have the stratum protocol implemented by June 1.
So far, we've found 9 blocks and payouts are working as expected.
We'll be verifying EVERY PAYOUT to make sure it's fair and accurate.
We're not looking to get rich by hosting a pool, we just want fair trustworthy place to mine.
Genoil, you will mine for free for the life of the pool, just send me your address:)
The pool is built and managed by software engineers and network professionals with advanced firewall protection and redundancy.
Payouts run at noon everyday, with low payout (1 ETH) requirements, so there won't be a lot of ETH in the wallet to make it a target.
We will also be increasing the frequency of payouts as block-times decrease.
Here is the run-line for ethminer:
ethminer.exe --farm-recheck 500 -U -F http://donkeypool.com/coinbase_address/worker_name/hashrate_MH
AMD cards change the line to:
ethminer.exe --farm-recheck 500 -G -F http://donkeypool.com/coinbase_address/worker_name/hashrate_MH
"Note that the DAG does not need to be generated for verifying the PoW essentially allowing for verification with both low CPU and small memory."
http://ethdocs.org/en/latest/mining.html
You are right, I forgot about that. Well actually you are making a very useful remark. Normally (in ethminer) the CPU validation of a result is done using the system RAM copy of the full DAG, because it was put there anyway to copy to the GPU. If it is corrupt, the CPU will still validate the solution, because it uses the same borked DAG. However, by changing 1 line of code, you can change the validation to use the 'light' model, circumventing the potentially corrupted DAG. This should be a much more elegant solution than using CRC.
You will need a second check.
Correct. The fastest way would be to first do the CPU validation against the full DAG and only do the light validation if that fails. If the last one passes, the DAG is corrupt.
"Note that the DAG does not need to be generated for verifying the PoW essentially allowing for verification with both low CPU and small memory."
http://ethdocs.org/en/latest/mining.html
You are right, I forgot about that. Well actually you are making a very useful remark. Normally (in ethminer) the CPU validation of a result is done using the system RAM copy of the full DAG, because it was put there anyway to copy to the GPU. If it is corrupt, the CPU will still validate the solution, because it uses the same borked DAG. However, by changing 1 line of code, you can change the validation to use the 'light' model, circumventing the potentially corrupted DAG. This should be a much more elegant solution than using CRC.
You will need a second check.
So the point in time where the chances of corrupting the file are highest is completely ignored? That doesn't sound very useful to me. It would be way more useful if the DAG CRC could be sent along with a solution to a node or pool and checked there against the CRC of the resident DAG file. Solution verification kind of already does that of course, but it can validate on nonce a while nonce b is borked.
Pool or node doesn't have to maintain DAG for current epoch. It is only for mining if I got it right.
Maybe your idea to make a "model" CRC numbers for future 100 DAG is not bad, but then we will need them for past DAG files too for etherium forks.
I really don't like current Claymore's implementation. Now his 3.3 version has its own DAG-file format incompatible with ethminer as it were before.
A pool or node also keeps a DAG file to validate shares. How else would it be able to reject solutions?
"Note that the DAG does not need to be generated for verifying the PoW essentially allowing for verification with both low CPU and small memory."
http://ethdocs.org/en/latest/mining.html
You are right, I forgot about that. Well actually you are making a very useful remark. Normally (in ethminer) the CPU validation of a result is done using the system RAM copy of the full DAG, because it was put there anyway to copy to the GPU. If it is corrupt, the CPU will still validate the solution, because it uses the same borked DAG. However, by changing 1 line of code, you can change the validation to use the 'light' model, circumventing the potentially corrupted DAG. This should be a much more elegant solution than using CRC.
So the point in time where the chances of corrupting the file are highest is completely ignored? That doesn't sound very useful to me. It would be way more useful if the DAG CRC could be sent along with a solution to a node or pool and checked there against the CRC of the resident DAG file. Solution verification kind of already does that of course, but it can validate on nonce a while nonce b is borked.
Pool or node doesn't have to maintain DAG for current epoch. It is only for mining if I got it right.
Maybe your idea to make a "model" CRC numbers for future 100 DAG is not bad, but then we will need them for past DAG files too for etherium forks.
I really don't like current Claymore's implementation. Now his 3.3 version has its own DAG-file format incompatible with ethminer as it were before.
A pool or node also keeps a DAG file to validate shares. How else would it be able to reject solutions?
"Note that the DAG does not need to be generated for verifying the PoW essentially allowing for verification with both low CPU and small memory."
http://ethdocs.org/en/latest/mining.html
Can somebody supply me with a list of valid CRC checksums for the next err...100 DAG files? Or am I missing something somewhere?
As far as I understand he computes CRC after fresh DAG generation and adds CRC to DAG file. Then miner checks on restart the CRC number stored in DAG file and calculated CRC.
So the point in time where the chances of corrupting the file are highest is completely ignored? That doesn't sound very useful to me. It would be way more useful if the DAG CRC could be sent along with a solution to a node or pool and checked there against the CRC of the resident DAG file. Solution verification kind of already does that of course, but it can validate on nonce a while nonce b is borked.
Pool or node doesn't have to maintain DAG for current epoch. It is only for mining if I got it right.
Maybe your idea to make a "model" CRC numbers for future 100 DAG is not bad, but then we will need them for past DAG files too for etherium forks.
I really don't like current Claymore's implementation. Now his 3.3 version has its own DAG-file format incompatible with ethminer as it were before.
A pool or node also keeps a DAG file to validate shares. How else would it be able to reject solutions?
Can somebody supply me with a list of valid CRC checksums for the next err...100 DAG files? Or am I missing something somewhere?
As far as I understand he computes CRC after fresh DAG generation and adds CRC to DAG file. Then miner checks on restart the CRC number stored in DAG file and calculated CRC.
So the point in time where the chances of corrupting the file are highest is completely ignored? That doesn't sound very useful to me. It would be way more useful if the DAG CRC could be sent along with a solution to a node or pool and checked there against the CRC of the resident DAG file. Solution verification kind of already does that of course, but it can validate on nonce a while nonce b is borked.
Pool or node doesn't have to maintain DAG for current epoch. It is only for mining if I got it right.
Maybe your idea to make a "model" CRC numbers for future 100 DAG is not bad, but then we will need them for past DAG files too for etherium forks.
I really don't like current Claymore's implementation. Now his 3.3 version has its own DAG-file format incompatible with ethminer as it were before.
Can somebody supply me with a list of valid CRC checksums for the next err...100 DAG files? Or am I missing something somewhere?
As far as I understand he computes CRC after fresh DAG generation and adds CRC to DAG file. Then miner checks on restart the CRC number stored in DAG file and calculated CRC.
So the point in time where the chances of corrupting the file are highest is completely ignored? That doesn't sound very useful to me. It would be way more useful if the DAG CRC could be sent along with a solution to a node or pool and checked there against the CRC of the resident DAG file. Solution verification kind of already does that of course, but it can validate on nonce a while nonce b is borked.
Can somebody supply me with a list of valid CRC checksums for the next err...100 DAG files? Or am I missing something somewhere?
As far as I understand he computes CRC after fresh DAG generation and adds CRC to DAG file. Then miner checks on restart the CRC number stored in DAG file and calculated CRC.
Claymore just added this to his 3.3 version:
- added CRC check for DAG files. Now if DAG file is corrupted, miner will detect it and re-create DAG.
Would be great if you can add it to your branch as well.
This feature is rather buggy in his 3.3 release ... will wait for more robust one - added CRC check for DAG files. Now if DAG file is corrupted, miner will detect it and re-create DAG.
Would be great if you can add it to your branch as well.
Claymore just added this to his 3.3 version:
- added CRC check for DAG files. Now if DAG file is corrupted, miner will detect it and re-create DAG.
Would be great if you can add it to your branch as well.
- added CRC check for DAG files. Now if DAG file is corrupted, miner will detect it and re-create DAG.
Would be great if you can add it to your branch as well.
Can somebody supply me with a list of valid CRC checksums for the next err...100 DAG files? Or am I missing something somewhere?
Claymore just added this to his 3.3 version:
- added CRC check for DAG files. Now if DAG file is corrupted, miner will detect it and re-create DAG.
Would be great if you can add it to your branch as well.
- added CRC check for DAG files. Now if DAG file is corrupted, miner will detect it and re-create DAG.
Would be great if you can add it to your branch as well.
how do i fix this ? running win7 with Microsoft Visual Studio 2015
D:\_Build\cpp-ethereum\build>cmake -DBUNDLE=miner ..
-- FindWindowsSDK: Detected Visual Studio 2012 or newer, not using the _xp tools
et variant: including SDK versions that drop XP support in search!
- WindowsSDK dirs: C:/Program Files (x86)/Windows Kits/8.1;C:/Program Files (x8
6)/Microsoft SDKs/Windows/v8.0A;C:/Program Files (x86)/Microsoft SDKs/Windows/v8
.1A;C:/Program Files (x86)/Microsoft SDKs/Windows/v7.1A
-- ctest path: E:/Program Files (x86)/CMake/bin/ctest.exe
CMake Error at cmake/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find CryptoPP (missing: CRYPTOPP_INCLUDE_DIR CRYPTOPP_LIBRARY)
(Required is at least version "5.6.2")
Call Stack (most recent call first):
cmake/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE)
cmake/FindCryptoPP.cmake:107 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
cmake/EthDependencies.cmake:44 (find_package)
CMakeLists.txt:246 (include)
D:\_Build\cpp-ethereum\build>cmake -DBUNDLE=miner ..
-- FindWindowsSDK: Detected Visual Studio 2012 or newer, not using the _xp tools
et variant: including SDK versions that drop XP support in search!
- WindowsSDK dirs: C:/Program Files (x86)/Windows Kits/8.1;C:/Program Files (x8
6)/Microsoft SDKs/Windows/v8.0A;C:/Program Files (x86)/Microsoft SDKs/Windows/v8
.1A;C:/Program Files (x86)/Microsoft SDKs/Windows/v7.1A
-- ctest path: E:/Program Files (x86)/CMake/bin/ctest.exe
CMake Error at cmake/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find CryptoPP (missing: CRYPTOPP_INCLUDE_DIR CRYPTOPP_LIBRARY)
(Required is at least version "5.6.2")
Call Stack (most recent call first):
cmake/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE)
cmake/FindCryptoPP.cmake:107 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
cmake/EthDependencies.cmake:44 (find_package)
CMakeLists.txt:246 (include)
this will try to make a 32-bit project. You'll ahve to specify something like cmake -DBUNDLE=miner -G "Visual Studio 14 2015 Win64" ..
that helped thx alot.
but got compiler error i use: msbuild ethereum.sln /p:Configuration=Release
but dont matter that much because you release for windows very fast
what error? let me guess something with pthread?
10 Warning(s)
104 Error(s)
dont know how to log to fil with msbuild. tried some but didnt help
how do i fix this ? running win7 with Microsoft Visual Studio 2015
D:\_Build\cpp-ethereum\build>cmake -DBUNDLE=miner ..
-- FindWindowsSDK: Detected Visual Studio 2012 or newer, not using the _xp tools
et variant: including SDK versions that drop XP support in search!
- WindowsSDK dirs: C:/Program Files (x86)/Windows Kits/8.1;C:/Program Files (x8
6)/Microsoft SDKs/Windows/v8.0A;C:/Program Files (x86)/Microsoft SDKs/Windows/v8
.1A;C:/Program Files (x86)/Microsoft SDKs/Windows/v7.1A
-- ctest path: E:/Program Files (x86)/CMake/bin/ctest.exe
CMake Error at cmake/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find CryptoPP (missing: CRYPTOPP_INCLUDE_DIR CRYPTOPP_LIBRARY)
(Required is at least version "5.6.2")
Call Stack (most recent call first):
cmake/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE)
cmake/FindCryptoPP.cmake:107 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
cmake/EthDependencies.cmake:44 (find_package)
CMakeLists.txt:246 (include)
D:\_Build\cpp-ethereum\build>cmake -DBUNDLE=miner ..
-- FindWindowsSDK: Detected Visual Studio 2012 or newer, not using the _xp tools
et variant: including SDK versions that drop XP support in search!
- WindowsSDK dirs: C:/Program Files (x86)/Windows Kits/8.1;C:/Program Files (x8
6)/Microsoft SDKs/Windows/v8.0A;C:/Program Files (x86)/Microsoft SDKs/Windows/v8
.1A;C:/Program Files (x86)/Microsoft SDKs/Windows/v7.1A
-- ctest path: E:/Program Files (x86)/CMake/bin/ctest.exe
CMake Error at cmake/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find CryptoPP (missing: CRYPTOPP_INCLUDE_DIR CRYPTOPP_LIBRARY)
(Required is at least version "5.6.2")
Call Stack (most recent call first):
cmake/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE)
cmake/FindCryptoPP.cmake:107 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
cmake/EthDependencies.cmake:44 (find_package)
CMakeLists.txt:246 (include)
this will try to make a 32-bit project. You'll ahve to specify something like cmake -DBUNDLE=miner -G "Visual Studio 14 2015 Win64" ..
that helped thx alot.
but got compiler error i use: msbuild ethereum.sln /p:Configuration=Release
but dont matter that much because you release for windows very fast
what error? let me guess something with pthread?
how do i fix this ? running win7 with Microsoft Visual Studio 2015
D:\_Build\cpp-ethereum\build>cmake -DBUNDLE=miner ..
-- FindWindowsSDK: Detected Visual Studio 2012 or newer, not using the _xp tools
et variant: including SDK versions that drop XP support in search!
- WindowsSDK dirs: C:/Program Files (x86)/Windows Kits/8.1;C:/Program Files (x8
6)/Microsoft SDKs/Windows/v8.0A;C:/Program Files (x86)/Microsoft SDKs/Windows/v8
.1A;C:/Program Files (x86)/Microsoft SDKs/Windows/v7.1A
-- ctest path: E:/Program Files (x86)/CMake/bin/ctest.exe
CMake Error at cmake/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find CryptoPP (missing: CRYPTOPP_INCLUDE_DIR CRYPTOPP_LIBRARY)
(Required is at least version "5.6.2")
Call Stack (most recent call first):
cmake/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE)
cmake/FindCryptoPP.cmake:107 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
cmake/EthDependencies.cmake:44 (find_package)
CMakeLists.txt:246 (include)
D:\_Build\cpp-ethereum\build>cmake -DBUNDLE=miner ..
-- FindWindowsSDK: Detected Visual Studio 2012 or newer, not using the _xp tools
et variant: including SDK versions that drop XP support in search!
- WindowsSDK dirs: C:/Program Files (x86)/Windows Kits/8.1;C:/Program Files (x8
6)/Microsoft SDKs/Windows/v8.0A;C:/Program Files (x86)/Microsoft SDKs/Windows/v8
.1A;C:/Program Files (x86)/Microsoft SDKs/Windows/v7.1A
-- ctest path: E:/Program Files (x86)/CMake/bin/ctest.exe
CMake Error at cmake/FindPackageHandleStandardArgs.cmake:138 (message):
Could NOT find CryptoPP (missing: CRYPTOPP_INCLUDE_DIR CRYPTOPP_LIBRARY)
(Required is at least version "5.6.2")
Call Stack (most recent call first):
cmake/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE)
cmake/FindCryptoPP.cmake:107 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
cmake/EthDependencies.cmake:44 (find_package)
CMakeLists.txt:246 (include)
this will try to make a 32-bit project. You'll ahve to specify something like cmake -DBUNDLE=miner -G "Visual Studio 14 2015 Win64" ..
that helped thx alot.
but got compiler error i use: msbuild ethereum.sln /p:Configuration=Release
but dont matter that much because you release for windows very fast
Jump to: