Show Posts
|
Pages: [1] 2 »
|
On my 670 with 1D tex cache I am getting about 175 kHash/s.
A 570 though would be significantly faster (but also run significantly hotter). I am still trying to understand why the Kepler architecture has such a performance disadvantage with my current code. I did try some inline PTX assembly (looks horrid, check it out) __device__ void ROTL7(uint32_t &A0, const uint32_t &A1, const uint32_t &A2, uint32_t &B0, const uint32_t &B1, const uint32_t &B2, uint32_t &C0, const uint32_t &C1, const uint32_t &C2, uint32_t &D0, const uint32_t &D1, const uint32_t &D2) { asm("{\n\t" " .reg .u32 tA1, tA2;\n\t" " .reg .u32 tB1, tB2;\n\t" " .reg .u32 tC1, tC2;\n\t" " .reg .u32 tD1, tD2;\n\t" " add.u32 tA1, %4, %5;\n\t" " add.u32 tB1, %6, %7;\n\t" " add.u32 tC1, %8, %9;\n\t" " add.u32 tD1, %10, %11;\n\t" " shl.b32 tA2, tA1, 7;\n\t" " shl.b32 tB2, tB1, 7;\n\t" " shl.b32 tC2, tC1, 7;\n\t" " shl.b32 tD2, tD1, 7;\n\t" " shr.b32 tA1, tA1, 25;\n\t" " shr.b32 tB1, tB1, 25;\n\t" " shr.b32 tC1, tC1, 25;\n\t" " shr.b32 tD1, tD1, 25;\n\t" " or.b32 tA1, tA1, tA2;\n\t" " or.b32 tB1, tB1, tB2;\n\t" " or.b32 tC1, tC1, tC2;\n\t" " or.b32 tD1, tD1, tD2;\n\t" " xor.b32 %0, %0, tA1;\n\t" " xor.b32 %1, %1, tB1;\n\t" " xor.b32 %2, %2, tC1;\n\t" " xor.b32 %3, %3, tD1;\n\t" "}" : "+r"(A0), "+r"(B0), "+r"(C0), "+r"(D0) : "r" (A1), "r" (A2), "r" (B1), "r" (B2), "r" (C1), "r" (C2), "r" (D1), "r" (D2)); }
as well as added instruction level parallelism by formulating the CUDA code like this: #define ROTL7(A0, A1, A2, B0, B1, B2, C0, C1, C2, D0, D1, D2) \ {\ volatile uint32_t tA1 = A1 + A2, tB1 = B1 + B2, tC1 = C1 + C2, tD1 = D1 + D2;\ volatile uint32_t tA2 = tA1<< 7, tB2 = tB1<< 7, tC2 = tC1<< 7, tD2 = tD1<< 7;\ tA1 = tA1>>25; tB1 = tB1>>25; tC1 = tC1>>25; tD1 = tD1>>25;\ tA2|= tA1 ; tB2|= tB1 ; tC2|= tC1 ; tD2|= tD1 ;\ A0 ^= tA2 ; B0 ^= tB2 ; C0 ^= tC2 ; D0 ^= tD2 ;\ }
but actually I couldn't get performance above what is already achieved. So in case you're wondering why there haven't been any updates. That is because my experiments in getting more speed haven't been fruitful yet. I assume you've seen this Kepler thread? https://bitcointalk.org/index.php?topic=163750.0;topicseen
|
|
|
Getting submit_upstream_work json_rpc_call errors and proxy errors now, rejecting work. US server down?
|
|
|
Thanks. Added my GTX 480 & GTS 450 to the mix.
|
|
|
Just swapped over to this pool, using the mining proxy since I'm using the cudaminer in this forum which doesn't have stratum support.
I'm getting an error frequently from the proxy:
2013-04-14 16:58:03,654 INFO proxy jobs.extranonce2_padding # Extranonce size mismatch. Please report this error to pool operator!
It then goes on to say that it was accepted right after. Thought I would pass that on.
I can't verify that it is working as the stats are down, as you mentioned above, so I guess I'll wait until they are back up to see if my work is being accepted.
I am using the us.wemineltc.com:8332 server.
|
|
|
Mtgox has clearly not had time to respond, and I fear they will claim this is my fault as I have seen in other posts online that they say "report it to the police". They should compensate me 100%. First because their site is not secured against such rudimentary attacks as has been demonstrated today. I'm not the first and certainly not the last so long as they don't deal with this. Second because their security policy should account for such instances, and I did not even have an opportunity to warn them I did not make the withdrawal. Yet most importantly, BECAUSE THEY SHOULD HAVE KNOWN ABOUT THIS OVER 3 DAYS AGO!!! http://www.reddit.com/r/Bitcoin/comments/1bvl4n/beware_when_clicking_any_link_from_chatboxesirc/Yeah, I'm stupid, I should have enabled a Yubikey or other 2nd auth method when bitcoins started exploding in value ... but still, this attack is rather basic and should not be possible on a site at the level of Mt. Gox. I can only imagine how people with larger amounts would feel if clicking on a link emptied their account $10k+... This is a serious loss for me, and unless this is handled correctly this can also badly affect the community. I know they are super busy as they are backlogged with over 10,000 account verifications - I can only hope this gets handled appropriately. Does anyone have any advice how to go about contacting mtgox, they are so busy they don't even realize someone has a specialized phishing operation running to rob their customers! Any advice is very much appreciated. Sorry for your loss, but no, Mt. Gox should not refund you for your losses. You pretty much violated every tenet of online security and got caught in a phishing net in doing so.
|
|
|
@Inaba, I am aware that you may be associated with BFL and you are dismissing my claim easily, so I will submit my invoice and credit notes here as screenshots with personal details omitted. All I am asking is for clarification as to why I have on the refund note a fee charged on the original sum I have paid for. It might be something as stupid as a software error on your billing platform. This is the invoice when I purchased the Jalapeno: This is the refund note with the adjustment fee charge: Inaba = BFL_Josh https://bitcointalk.org/index.php?topic=97269.msg1071218#msg1071218
|
|
|
What hashrate where you getting without cuda?
guiminer poclbm gives me ~137.5 How does your 480 beat a 680? you overclocking at all? Im getting around 122~ give or take with cgminer 800 core, instead of 700. Pretty modest OC. Could probably go higher, but this is my main machine & don't want to risk blowing it up...
|
|
|
What hashrate where you getting without cuda?
guiminer poclbm gives me ~137.5
|
|
|
I've just added the 64-bit build, in a separate branch https://github.com/cdmackie/rpcminer-mod/tree/x64. Grab the whole repo (or just bin) and run it from within bin as before. I don't imagine you'll see much difference, but if anyone could try it out so I can make it the default. Now must sleep... I'm running it now, works as is.
|
|
|
@InqBit: is 137694 khash/s the first shown hash rate? Please run the miner 5 min and than look to the hash rate. The first hash rate is always lower because the first kernel call takes very long. I see you run the code with without -aggression, please add -aggression=8 or 7 to you parameter to get more performance. -gputhreads is not needed because it is ignored and hard set to 256.
theoretic calculation rate for GTX480: 1401*15/(3733/32+1194/16)=109 MHash/s (magic numbers are the count of operations from the binary for this implementation)
Mhh in my theoretic calculation I assumed 109 MHash/s for a GTX480. I think I must check if my operation count for fermi is right. Can someone with a GTX480 run the code under linux without -gpugrid.
I just made the appropriate changes and started a new run. Will let you know in a few how it works out. FWIW, I've been running ~140-145'ish on cgminer, overclocked to 800 core (700 stock). This is my general use machine, so I didn't have aggression set to keep desktop usable, but will run at 7 for testing for you. I just checked my average hashrate on cgwatcher, and it is 140.1. edit: 10 minutes later C:\miners\rpcminer nvopt>rpcminer-mod-cuda.exe -url=api.bitcoin.cz:8332 -user=user -password=pass -gpugrid=512 -gpu=0 -aggression=7 last 5 hashrates 140345 khash/s 140360 khash/s 140052 khash/s 139525 khash/s 140080 khash/s
|
|
|
Here was my output fwiw. GTX 480
C:\miners\rpcminer nvopt>rpcminer-mod-cuda.exe -url=api.bitcoin.cz:8332 -user=user -password=password -gpugrid=512 -gputhreads=480 -gpu=0 Client will start 1 miner threads Work will be refreshed every 4000 ms 2 GPU GUDA device(s) found CUDA initialized Search Configuration for gpu named: GeForce GTX 480 Your device: - 15 streaming multiprocessors (SM) - can run sm version 200 - bitcoin miner is optimized for 3 gpugrids per SM - max value for gpugrid parameter is 65535 max nonce 3FFFFFFF Done allocating CUDA resources for (512,256) iterations on gpu=32 blocks=512 threads=256 Iterations: 255,hashs per iteration 15994212185991544832 Target = 00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffff Found nonce 364CFF6C 2013-04-08 07:11:01 Found Hash! Hashs found: 1 Sending to server: {"method":"getwork","params":["000000029bddf49cc3f72f75bf4552 d589df0fb9ec95184c247082e00000009200000000ffb19deae961efc905812ff5b1fcf69ec34f2 7 c9d0ba4194749c538e3ceb2ca751626d7e1a022fbe6cff4c3600000080000000000000000000000 0 000000000000000000000000000000000000000000000000000000000080020000"],"id":1} Server sent: {"result": true, "id": "1", "error": null} Found nonce AE9CEA4 2013-04-08 07:11:03 Found Hash! Hashs found: 2 Sending to server: {"method":"getwork","params":["000000029bddf49cc3f72f75bf4552 d589df0fb9ec95184c247082e000000092000000000c048fe68ab3317714aaee783c242a630feb0 1 86961ef159df4949318f8688e051626d851a022fbea4cee90a00000080000000000000000000000 0 000000000000000000000000000000000000000000000000000000000080020000"],"id":1} Server sent: {"result": true, "id": "1", "error": null} 137694 khash/s
|
|
|
I did a full repull of the files from charlie's github and it is working now, using only 1 of my 2 gpu's. I did uninstall the CUDA dev prog as well after seeing you did, and pulled the correct file it needed from github.
As of now, not seeing any difference in hash rate on a Fermi card, but I assume that's what was expected.
|
|
|
I sent you my rpcminer.dmp file from most recent attempt.
Trying to set the -gpu flag made no difference. The video driver stops responding if that helps.
|
|
|
Downloaded & installed the x64 CUDA dev software & the .exe is just crashing now. I re-downloaded all the files this morning & was getting an error about the cudart32 file, & that's when I downloaded the CUDA package.
Ok, whilst building a debug version to try and track your issue down, I found out that there is an error in the error handler. So based on the line you had the error, it's that the CUDA device driver didn't initialise properly. Do you have the right and latest drivers? I've fixed the error handler and uploaded a new binary so you should see a more meaningful message. I am 1 version behind on drivers, will download the latest ones. Latest error with newest rpcminer-mod-cuda (1 version behind on drivers fyi) Client will start 1 miner threads Work will be refreshed every 4000 ms 2 GPU GUDA device(s) found <src\cuda\bitcoinminercuda.cpp>:54[CUDA] Error: invalid device ordinal Could not retrieve work from RPC server. CURL return value = 7 edit: Latest drivers, 314.22, same error as above.
|
|
|
@InqBit Just seems like the file is corrupted. Does it match the one on gibhub? Can you try downloading it again? You will need to 32bit CUDA SDK, or at least cudart32_50.dll if that isn't included in the 64bit version. I hadn't built 64bit, as there were 3rd party dependencies, but I might try and them them later.
Downloaded & installed the x64 CUDA dev software & the .exe is just crashing now. I re-downloaded all the files this morning & was getting an error about the cudart32 file, & that's when I downloaded the CUDA package. It begins to start, then crashes after outputting: Client will start 1 miner threads Work will be refreshed every 4000 ms 2 GPU GUDA device(s) found <src\cuda\bitcoinminercuda.cpp>:54 Event log below: Faulting application name: rpcminer-mod-cuda.exe, version: 0.0.0.0, time stamp: 0x5161065f Faulting module name: rpcminer-mod-cuda.exe, version: 0.0.0.0, time stamp: 0x5161065f Exception code: 0x40000015 Fault offset: 0x0002eadc Faulting process id: 0x19ac Faulting application start time: 0x01ce33c69eee3f83 Faulting application path: C:\miners\rpcminer nvopt\rpcminer-mod-cuda.exe Faulting module path: C:\miners\rpcminer nvopt\rpcminer-mod-cuda.exe Report Id: dd0fe4b3-9fb9-11e2-94d6-001fbc083cc7
|
|
|
This version of C:\miners\rpcminer nvopt\rpcminer-mod-cuda.exe is not compatible with the version of Windows you're running.
Er..odd. Nothing changed since last version working from yesterday? Can you download Dependency Walker from http://www.dependencywalker.com/ (the x86 version) and run it and open the rpcminer-mod-cuda.exe file and see if you get any errors. An error is typically a file shown in red in the top left tree. I downloaded the x64 version since that is the OS I have. Output below:
|
|
|
I have updated the Windows build with psychocoder's changes: https://github.com/cdmackie/rpcminer-mod (use the master branch) We'll merge them together shortly. To just run, you only need the bin folder, and run the rpcminer-mod-cuda.exe. There is no need for the ptx files anymore. To build yourself, you need MSVC 2010 and the CUDA SDK 5.x. Please post any errors or successes. This version of C:\miners\rpcminer nvopt\rpcminer-mod-cuda.exe is not compatible with the version of Windows you're running. Ch eck your computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher. Error message when starting from command line. Win 7 x64
|
|
|
Nice work. the 20 file got it going and look at the results, 19Ghash from Nvidia cards! (30 file returned 209 error) It's working but BTC is showing work as dupes. Not surprisingly... GUIMiner ends up reporting as having connection issues fwiw.
|
|
|
|