|
Something I noticed about the throughput values and it kinda makes sense too: Multiples of SMM count seem to work best for the -x parameter. 5 for 750 Ti, 13 for 970, 16 for 980. Only have 750s and a 970 to test with but 20 or 15 for 750 Ti and 13 or 26 for 970 seem to work well.
|
|
|
|
I have found a bug in the hash. The problem is that tsivs code is missing verfication by the cpu before sending the results. Build 2 comming soon
Care to elaborate on the bug part? Might see if I CBA to fix it in the official release. |
|
|
|
Being friendly seems difficult, but atleast I had an answer. Thanks The same questions being asked over and over again, with the answers being in the opening post gets old at some point. Just a minor venting of built up frustration, my apologies  |
|
|
|
On hefty1 algo all i'm getting are booo's ccminer.exe -a hefty1 -o stratum+tcp://scsy.suprnova.cc:3034 -u -p
try just a conclusion... -a mjollnir did it thx If a coin uses hefty1, why do we need to use -a mjollnir algo to mine it? Why not -a hefty1 ? Because hefty1 is not a supported algorithm in ccminer. If you look closely, you actually end up with the ccminer default algorithm (heavy) when you do something like -a thisthingdoesnotexist. There's only heavy and mjollnir, both of which make use of hefty1 as part of the whole but are definitely not just hefty1. SCSY dev saying the coin algo is hefty1 is like saying X11 is blake. It might be a part of the whole but a horribly inaccurate description of the algorithm as a whole. TL;DR SCSY dev doesn't know what he/she/it is talking about when he/she/it calls the algo hefty1. so it is yet another algorithm ? He is calling the algo hefty1 so i think he maybe confused. actually it is the name of the algo (why 1 ? I don't know) To be fair even the original Heavycoin dev made things a bit confusing with his naming. The heavycoin algo, as I prefer to call it, is a combination of something that's called HEFTY-1 and some more familiar hashes like sha256, blake256 etc. Why the dev would state the coins algo is HEFTY-1 when it's a combination algo is beyond me. Quote from the übermaster aka cbuchner: HeavyCoin is a mix of 5 algorithms, one being newly invented for this coin.
HEFTY-1 is a SHA256 derivative with added fairy dust to make it "GPU resistant" and "ASIC resistant". IMHO neither of these objectives have been met (we implemented the first nVidia GPU miner for it)
The hash algorithm adds SHA256, blake256, groestl512, keccak512 into the mix by hashing 84 bytes block header + the above 32 byte HEFTY1 hash with each algorithm and performing a bitwise interleaving of bits from each resulting hash.
|
|
|
|
On hefty1 algo all i'm getting are booo's ccminer.exe -a hefty1 -o stratum+tcp://scsy.suprnova.cc:3034 -u -p
try just a conclusion... -a mjollnir did it thx If a coin uses hefty1, why do we need to use -a mjollnir algo to mine it? Why not -a hefty1 ? Because hefty1 is not a supported algorithm in ccminer. If you look closely, you actually end up with the ccminer default algorithm (heavy) when you do something like -a thisthingdoesnotexist. There's only heavy and mjollnir, both of which make use of hefty1 as part of the whole but are definitely not just hefty1. SCSY dev saying the coin algo is hefty1 is like saying X11 is blake. It might be a part of the whole but a horribly inaccurate description of the algorithm as a whole. TL;DR SCSY dev doesn't know what he/she/it is talking about when he/she/it calls the algo hefty1. so it is yet another algorithm ? Apparently it's just the mjollnir algo, the dev's just making if confusing by calling it hefty1. |
|
|
|
On hefty1 algo all i'm getting are booo's ccminer.exe -a hefty1 -o stratum+tcp://scsy.suprnova.cc:3034 -u -p
try just a conclusion... -a mjollnir did it thx If a coin uses hefty1, why do we need to use -a mjollnir algo to mine it? Why not -a hefty1 ? Because hefty1 is not a supported algorithm in ccminer. If you look closely, you actually end up with the ccminer default algorithm (heavy) when you do something like -a thisthingdoesnotexist. There's only heavy and mjollnir, both of which make use of hefty1 as part of the whole but are definitely not just hefty1. SCSY dev saying the coin algo is hefty1 is like saying X11 is blake. It might be a part of the whole but a horribly inaccurate description of the algorithm as a whole. TL;DR SCSY dev doesn't know what he/she/it is talking about when he/she/it calls the algo hefty1. |
|
|
|
Current version of KSHAKE320 algorithm requires 64Kb per hash. I could change it to require 128Kb+ on a dime.
But, what limits the speed of the algorithm is not the amount of RAM but, the speed you can store/read data to/from RAM. If in the future, new RAM technology allows for very fast memory that is also affordable then, the KSHAKE320 algorithm may no longer offer an advantage over regular hashing algorithms.
Correct me if I'm wrong, but the 64 kB scratchpad looks unnecessary. OpenCL isn't exactly a native tongue to me, but from what I gather the core is roughly something like this: initState(A);
absorbInput(A);
for( i = 0; i < 546; i++ ) {
keccakPermutation(A);
saveStateToScratchpad(i, A);
}
initState(A);
for( i = 0; i < 546; i++ ) {
absorbFromScratchpad(A, i);
keccakPermutation(A);
}
If that is correct, then you could just have two keccak states instead the current scratchpad implementation? Something like this: initState(A);
initState(B);
absorbInput(A);
for( i = 0; i < 546; i++ ) {
keccakPermutation(A);
absorbFromState(B, A);
keccakPermutation(B);
}
I might be misinterpreting the openCL kernel or overlooking something, seems too obvious of a way to get rid of the scratchpad. The first hash is calculated using 120 bytes of data as an input. The result of this first hash (using Extendable Output Function SHAKE-320) is stored in the 64Kb scratchpad (120 * 546 to be exact). Then, a second hash is calculated using those 64Kb of scratchpad data as an input and the final result is a 40 bytes hash (320bits). And that's exactly what the second code snippet does. Instead of first calculating the full output of the XOF into a scratchpad and then separately hashing the scratchpad contents into the final hash, you can do it block by block. Maintain two keccak states, calculate first 120 bytes of the XOF output using the first state, update the second hash state with those 120 bytes, then calculate the next 120 bytes of the XOF, update the second hash with that. Repeat until finished. |
|
|
|
Current version of KSHAKE320 algorithm requires 64Kb per hash. I could change it to require 128Kb+ on a dime.
But, what limits the speed of the algorithm is not the amount of RAM but, the speed you can store/read data to/from RAM. If in the future, new RAM technology allows for very fast memory that is also affordable then, the KSHAKE320 algorithm may no longer offer an advantage over regular hashing algorithms.
Correct me if I'm wrong, but the 64 kB scratchpad looks unnecessary. OpenCL isn't exactly a native tongue to me, but from what I gather the core is roughly something like this: initState(A);
absorbInput(A);
for( i = 0; i < 546; i++ ) {
keccakPermutation(A);
saveStateToScratchpad(i, A);
}
initState(A);
for( i = 0; i < 546; i++ ) {
absorbFromScratchpad(A, i);
keccakPermutation(A);
}
If that is correct, then you could just have two keccak states instead the current scratchpad implementation? Something like this: initState(A);
initState(B);
absorbInput(A);
for( i = 0; i < 546; i++ ) {
keccakPermutation(A);
absorbFromState(B, A);
keccakPermutation(B);
}
I might be misinterpreting the openCL kernel or overlooking something, seems too obvious of a way to get rid of the scratchpad. |
|
|
|
Trying to compile the nvidia miner, getting this error on make: /bin/bash: nvcc: command not found
make[2]: *** [cuda_util.o] Error 127
I haven't edited the NVCC_GENCODE = -gencode=arch=compute_50,code=\"sm_50,compute_50\" line in Makefile.am as per the readme as I don't know what I should change it to. I have a 720M in my laptop, can anyone help? (I usually mine on AMD cards, never tried with anything nvidia before.) edit: wikipedia suggested my GPU was compute 3.5, so after installing NVIDIA CUDA toolkit and changing the above line to NVCC_GENCODE = -gencode=arch=compute_35,code=\"sm_35,compute_35\" it is continuing to compile, hurrah! edit2: OK, after creating a spreadcoin.conf and adding this: rpcuser=me
rpcpassword=meme
rpcallowip=127.0.0.1
listen=1
server=1
daemon=1
I restarted the QT client and ran the miner: ./spreadminer -o http://127.0.0.1:41677 -u me -p meme
*** Spreadminer 0.1 - a SpreadX11 miner for nVidia GPUs ***
based on ccminer 1.2 Copyright 2014 Christian Buchner, Christian H.
based on pooler-cpuminer 2.3.2 (c) 2010 Jeff Garzik, 2012 pooler
SpreadX11 additions by tsiv
[2014-12-02 14:47:11] 1 miner threads started, using 'spreadx11' algorithm.
[2014-12-02 14:47:11] GPU #0: GeForce GT 720M, 7952 khash/s
[2014-12-02 14:47:11] GPU #0: GeForce GT 720M, 3554812 khash/s
And that's all it outputs. Nvidia settings app reports GPU temp up to a steady 51C and fan is whirring but there's no further console output, is this normal? Good job figuring things out, but either wikipedia lied or you looked at the GT 720 which indeed seems to be compute 3.5 while the GT 720M is 2.1 according to https://developer.nvidia.com/cuda-gpusUnfortunately some of the ccminer X11 kernels need compute 3.0 to work, therefore you're SOL. Short version: no go. |
|
|
|
I'm trying now the NVidia miner, but i can't get it to work correclty. I can find a lot of blocks (running on testnet), but they are never accepted by the wallet: [2014-11-29 11:23:07] Thread 0 found a solution
First nonce : 00000000
Found nonce : 004ccf70
Threadidx : 315248
Threadidx64 : 4925
VTX : 0101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff020101ffffffff01f39eb627000000001614a082af4ce9f81ba9f2be1c16f36ac2a32d9719a3ac00000000
[2014-11-29 11:23:07] Final hash 256 : 742ef17bd2bd4800291d2f5f98e04af5d40a812cdc98338cae3c332562000000
[2014-11-29 11:23:07] Submit data : 02000000f3dc0278624b9b0c0f1796b21dc07115a52a165a23e635577be4625bda56c08078b0002107a0872873359a82bee1f3b46860955e4b23a958afdc2b729916c4d6b6c8795400000000eae57f1d1309000070cf4c00dadacba57842eaacd731ba7e89d748e2594d123f8f703ff84cba9e18ebdac2181c407c1133e8f71338c1e65dde7f1880002621236a944fe2574337e1d692247a87bddf5f3b6427938359df5362e2cd13b9628c6e6ee3f7c4bc954769139cc0728d
[2014-11-29 11:23:07] HashWholeBlock : dadacba57842eaacd731ba7e89d748e2594d123f8f703ff84cba9e18ebdac218
[2014-11-29 11:23:07] MinerSignature : bddf5f3b6427938359df5362e2cd13b9628c6e6ee3f7c4bc954769139cc0728d
[2014-11-29 11:23:07] GPU #0: GeForce GTX 750 Ti, 1148 khash/s
[2014-11-29 11:23:07] accepted: 0/11 (0.00%), 1148 khash/s (booooo)
Anyone knows how to fix it? (running on ubuntu 14.04 64bits, GeForce GTX 750 Ti). Doesn't seem to work on testnet and CBA to try figure out why, just go live |
|
|
|
rpcallowip=*
will disable any filter on ip.
And disable your firewall in the wallet PC to be sure that INCOMING connection will be allowed.
I did this, 2 rigs on linux mining on my laptop windows wallet
Just be damn sure your local network isn't accessible from the outside if you allow connections from any IP. Shouldn't need to mess with the firewall, since he's getting a 403 reply from the wallet there shouldn't be any connectivity problems, just authentication. |
|
|
|
I get this from other computer http request failed error 403 forbidden json_rpc_call failed
I dont get it..I have sent my hash from other coins to pools why cant i send my hash to my other computer that has the wallet.
Seems like there are two possibilities. Incorrect username/password (unlikely but check anyway) or incorrectly configured rpcallowip in the wallet conf and the wallet is denying connections from the other computer. Are you sure you've got the right network or IP address in the conf? |
|
|
|
thank you And how would i send my hash to the same wallet from my 2nd computer through the internet ? Here is how: Also you can mine to a specific address (this is useful if you are mining on several computers). To do so: 1. Use existing or better generate a new address. 2. Open debug console (Tools -> Debug Console) and enter: dumpprivkey SYourSpreadCoinAddress 3. You will get your private key. Then open spreadcoin.conf or create it if it doesn't exist (D:\Users\<username>\AppData\Roaming\SpreadCoin\spreadcoin.conf on Windows) and add the following line: miningprivkey=YourPrivateKey 4. Restart your wallet if it was running. In the Mining tab you will now see notification that all mined coins will go to this address. Of course you need to generate address and get privkey on one computer and edit spreadcoin.conf on the other. What is the difference between mining in one wallet with privatekey with several computers and mining with a more wallets especially? the wallet uses electricity = $ This part confuses me - I need to open my wallet on the second computer in order to solo mine. If I don't open the wallet I get json errors. Does the wallet have to be open on both rigs in order to solo mine? And at this point aren't I still burning electricity? You only need one wallet running. On the computer running the wallet you point your miner to 127.0.0.1 and on the other computer you point it to the computer that's running the wallet. Computer 1, with wallet: miner.exe -o 127.0.0.1:41677 Computer 2: miner.exe -o ip.of.wallet.computer:41677 Don't put gen=1 into the conf, that makes the wallet run the internal CPU miner and that's a waste of electricity at these network hash rates. Something like this would do the trick, add the miningprivkey parameter if you want, personally I don't use it. server=1
rpcallowip=127.0.0.1
rpcallowip=192.168.1.*
rpcuser=yourrpcusername
rpcpassword=yourrpcpassword
The first rpcallowip allows RPC connections from the same computer that is running the wallet. The second rpcallowip is needed to allow connections from the other computer, change the IP to whatever your local network is. Or you can run the wallet on both computer, as long as you don't use gen=1 it doesn't really hurt but you'll have to deal with having two separate wallets and moving coins from them separately. |
|
|
|
... All I can say is that I'm out of ideas how to push it any further It's very nice as is, stable as hell and I'm finding blocks pretty regularly. It's been months since I made any money with my GPUs So thanks again! Enjoy it while it lasts, it should indeed be (just barely) profitable with Maxwell at current prices and network hash rate. Looks like there's a slight upward trend in the price too. The coin could very well end up getting picked up on C-CEX next week, god knows how that's going to play out. |
|
|
|
Not much unless somebody (don't look at me) comes up with a significantly faster way to calculate sha256 hashes.
...blahblahblah...
Is it specific to spreadcoin ? not sure I understand about which sha256 you are talking about... but yes your table is seriously fucked up  If it is the sha256 of the merkleroot, it is performed only on accepted hash so it couldn't be parallelized. If it is something specific to spreadcoin, you may want to look at sha256 implementation in xcn (m7) it performs some sha256 calculation on very long hash... however yours should be faster because you know the length of the hash... Spreadcoin specific, described in http://spreadcoin.net/files/SpreadCoin-WhitePaper.pdf on page 2 starting at "hashWholeBlock is a SHA-256 hash of the block data arranged as follows." I think the sha256 implementation from your M7 was my first attempt at it, after spending a couple of days trying to figure out where the problem was I found out the sha256 code was giving incorrect results with the sha256 test vectors so I yanked one from ... Catia's version of the M7 miner. I do believe it's very strongly based on the same sha256 code (might even be your code originally, god knows) but I did get correct results from it so I went with it Just to set the scale right, you describe the roughly 300 bytes that you need to process with sha256 to get the final hash as "very long hash" and with spreadcoin it is four hundred THOUSAND bytes, meaning 6250 calls to the transformation function "sha2_round_body" ... and one more for the padding. Which should explain why it's slow it is very long compared to the usual hash... The implementation is rather specific to the algo, to get it work you would have to update the part which runs on the last round. (however the routine used to calculate one round should work...). All in all I can't say the sha256 code is exactly slow though. The run times in my "table" (lol) are for 1048576 nonces, which means 1048576 / 64 = 16384 sha256 hashes of 400000 bytes each. And 16384*400000 bytes in 246 milliseconds is 24.8 gigabytes/second processed, unless I have a brainfart in my math. Sounds like a very nice number compared to http://www.extremetech.com/gaming/176785-nvidias-new-maxwell-powered-gtx-750-ti-is-hyper-efficient-quiet-a-serious-threat-to-amd/3 which quotes 15.16 GB/s for 750 Ti. It's just that the amount of data to process is huge compared to the usual "ok, now we hash this 512-bit value from the previous hash" scenario. All I can say is that I'm out of ideas how to push it any further edit: may-be one way to increase a bit (not a lot though) would be to change the way the hashes are packed (the xcn way gives some slight speed improvement over the standard way) especially as you are working on very long hashes
I assume you're referring to the coalesced reads of the input. Won't work here, the block data is the same for every thread with the exception of the first two blocks that contain the changing part (nonce + minersignature) so it's just stored as a single 200000 byte block (that gets hashed over twice for a total of 400000 bytes processed) and the changing parts are are replaced by the sha256 kernel for the two first blocks. |
|
|
|
Not much unless somebody (don't look at me) comes up with a significantly faster way to calculate sha256 hashes.
...blahblahblah...
Is it specific to spreadcoin ? not sure I understand about which sha256 you are talking about... but yes your table is seriously fucked up If it is the sha256 of the merkleroot, it is performed only on accepted hash so it couldn't be parallelized. If it is something specific to spreadcoin, you may want to look at sha256 implementation in xcn (m7) it performs some sha256 calculation on very long hash... however yours should be faster because you know the length of the hash... Spreadcoin specific, described in http://spreadcoin.net/files/SpreadCoin-WhitePaper.pdf on page 2 starting at "hashWholeBlock is a SHA-256 hash of the block data arranged as follows." I think the sha256 implementation from your M7 was my first attempt at it, after spending a couple of days trying to figure out where the problem was I found out the sha256 code was giving incorrect results with the sha256 test vectors so I yanked one from ... Catia's version of the M7 miner. I do believe it's very strongly based on the same sha256 code (might even be your code originally, god knows) but I did get correct results from it so I went with it Just to set the scale right, you describe the roughly 300 bytes that you need to process with sha256 to get the final hash as "very long hash" and with spreadcoin it is four hundred THOUSAND bytes, meaning 6250 calls to the transformation function "sha2_round_body" ... and one more for the padding. Which should explain why it's slow |
|
|
|
... Don't go crazy now, donating everything you mine with the diff going up  Yeah, difficulty is really rising Hope they can get on decent exchange soon. Btw, anyway you can get some more hash out of your miner? I saw that they now get 2,1M out of 290x. Well, we still win both by watt/price, but wanted ask Not much unless somebody (don't look at me) comes up with a significantly faster way to calculate sha256 hashes. There's probably some kH/s to gain by taking a look at the X11 core parts that sp_ & crew have been improving, but as long as the huge honking whole block sha256 calculation is there at its current state, improving the core X11 part doesn't do much in the grand scheme of things. There are basically three things that slow it down compared to regular X11. First is calculating the miner signature and that part already works effectively in the gigahashes/second range so making it faster wouldn't have much of an effect. Second is calculating the whole block hash, in essence sha256 over 400000 bytes of data for every 64 nonces being tested and that is where it gets slow, effectively around 4-5 MH/s. And the third and last slowdown is having to run the Blake compression function over two blocks where a single block is enough for regular X11, so Blake runs at roughly half of its usual 100+ MH/s speed in regular X11. Removing the the whole block hash calculation gets you 2.8 MH/s, compared to about 2.9 MH/s that is the X11 part only. It's pretty easy to see that less than absolutely stellar improvements in the other parts won't make much difference in the total hash rate unless the whole block hash gets faster.. Edit: Tables are fun, gotta have tables. Timings for the separate parts that make up the SpreadX11 hash: | Part of hash | time (ms) | | sha256 for signature | 0.35 | | signature | 1.09 | | sha256 whole block | 246.11 | | blake | 20.57 | | bmw | 11.57 | | groestl | 68.84 | | skein | 9.84 | | jh | 19.72 | | keccak | 6.74 | | luffa | 17.83 | | cubehash | 26.00 | | shavite | 43.72 | | simd | 66.74 | | echo | 78.91 |
Edit 2: Goddddamn that's one seriously fucked up way to render a simple table... |
|
|
|
http://pastebin.com/sV7C2TWRTry that for Hamsi. It sure is not pretty but it's a whole lot faster than the one I originally left X13 with. My notes say +59% on the 750 Ti
|
|
|
|
Collective "thanks m8s" post for the SPR donations, cheers Don't go crazy now, donating everything you mine with the diff going up |
|
|
|
|
Show Posts
