 Show Posts
|
|
Pages: [1] 2 »
|
OMG WHY?
1. If I cashed out the BTC I made from MAX alone it would nearly cover the loan I received to purchase an S5. It still feels a bit like play money. 2. My career has been taking me further and further away from silicon, so just following your progress on cudaminer is gratifying. 3. You happened to be of assistance (however indirect) along my path to realizing that it is entirely appropriate for me to quit my cushy corporate job and bring my skill set to the world of cryptocurrencies. |
|
|
|
you might want to get the latest tagged release instead.
by the way, compilation on windows seemed to work fine for blake.cu
EDIT: I can repro the problem now under Linux. I think I am going to replace the entire blake implementation anyway, as yesterday's approach with some simple and clean blake256 implementation didn't produce compatible hashes. So it's likely the problem will go away as a result.
Cool beans. I'll look forward to it. I have been using a commit from just a few days ago, but I want to play with blake. Not worth my time to set Windows up. p.s. check your btc wallet. |
|
|
|
I can't seem to compile the latest commit for blake and I'm not familiar with how to handle nvcc errors like the following: nvcc -g -O2 -Xptxas "-abi=no -v" -arch=compute_10 --maxrregcount=64 --ptxas-options=-v -o blake.o -c blake.cu
### Assertion failure at line 1917 of ../../be/cg/cgemit.cxx:
### Compiler Error in file /tmp/tmpxft_000010b1_00000000-9_blake.cpp3.i during Assembly phase:
### operand 0 is not a register
nvopencc INTERNAL ERROR: /usr/lib/nvidia-cuda-toolkit/lib//be returned non-zero status 1 |
|
|
|
would Linux offer a feature to keep rolling logs that are automatically getting trimmed at the top, e.g. to a fixed file size or to a fixed number of lines?
You can define a log rotation job with logrotate and specify a max file size. http://linux.die.net/man/8/logrotateLogrotate is a daily cron, though it can be moved to be performed at other frequencies, hourly for example. If I were going to rotate cuda logs I would probably add my own hourly cron rather than modifying logrotate. I think both solutions would present problems if the process maintains an open file descriptor (like it does for stdout, and using > to redirect just redefines stdout) and never gets restarted. A simple bash script could automatically trim files. Check line count with `wc -l`, if it's above your limit do `tail -n <lines limit>` and redirect that back to the log, but it will currently do funky things if the file is open/being used by cudaminer. Using that method with a bash redirect will fill the file with 0s (or potentially random data) up to the file seek position maintained by the process. Redirecting the tail into a second file and replacing the first with the second is also no good, you'll stop getting output, but the process still has a fd so the system is still keeping track of a file and potentially writing data to disk, just not to any files you can actually see without mucking through /proc. Adding an argument for log outputs would go a long way to fix this, but there are a few ways it could actually be handled. Honestly the easiest method (or my impression of the easiest, which is likely naïve as I'm a computer architecture hacker not a sys admin) would be to implement log rotation into cudaminer. Write a wrapper for the logging function, check the seek position (or file size, but that might be more costly), if it's above the limit do a bit of file manipulation (copy the file and reset seek or rename the file and open a new fd). I'm probably just missing a simpler solution, but I'm a C programmer with a bad habit of reinventing the wheel. |
|
|
|
Yes, with MicroCoin, it that special?
I seem to have a "lucky card", it automagically clocks itself higher than the factory overclock suggests.
I think that's about normal. My Gigabyte 780 gets a little over 500 on MicroCoin. On another note, I just got back from the airport and sat down at the computer my 780 is mining on and noticed that things were behaving a little funky. Turns out the SSD was full and my output log contained 77GB worth of cuda errors. (I've been running cudaminer in a forked bash shell and redirecting stdout to a log). Thank goodness for trim. |
|
|
|
Whats your take on Vertcoin and will you plan on releasing a special version like you did for Max? Big fan of your Miners, they have been giving me 150%+ on my Nvidia Cards.
/Hi-Five,
redrip
Use --algo=scrypt:2048 to mine Vertcoin with any of the 2014 binaries. (You'll have to do another autotune, or cut your kernel parameters in half from what you'd typically use with scrypt) |
|
|
|
|
My 660 and my 640s all have 95% acceptance rate or better, but I've tried a hundred different configs on my 780 and it always settles around 75%.
|
|
|
|
Im mining at maxcoinpool.com, My miner is spinning around giving me 1000 Accepted shares in 4minutes. Yet at the pool it only shows 100valid, Anyone else experiencing this?
They haven't properly modified the pool software to handle maxcoin. It works, it just doesn't represent it properly. I now have an unconfirmed balance, we'll see if it pays out. |
|
|
|
you forgot ./autogen.sh (before you run configure)
yippieh, that was it. Thank you very much. Now I have a cudaminer binary. Wow. Starting it, however, results in this: ./cudaminer
./cudaminer: error while loading shared libraries: libcudart.so.5.5: cannot open shared object file: No such file or directory
and sorted: sudo ldconfig /usr/local/cuda/lib64
./cudaminer
Add something like "export DYLD_LIBRARY_PATH=/Developer/NVIDIA/CUDA-5.5/lib:$DYLD_LIBRARY_PATH" to ~/.bash_profile but change the path to point to your CUDA lib directory. Then run "source ~/.bash_profile" then try running cudaminer. |
|
|
|
so far so good. i could solve a lot of problems, but how to solve this? git clone https://github.com/cbuchner1/CudaMiner
cd CudaMiner
./configure
PATH=/usr/local/cuda-5.5/bin:$PATH make
results in:
cudaminer-cpu-miner.o: In function `miner_thread':
/root/CudaMiner/cpu-miner.c:876: undefined reference to `scanhash_keccak'
collect2: ld returned 1 exit status
make[2]: *** [cudaminer] Error 1
make[2]: Leaving directory `/root/CudaMiner'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/CudaMiner'
make: *** [all] Error 2
you forgot ./autogen.sh (before you run configure) |
|
|
|
|
If you're getting "undefined reference" to SHA256 or something similar, look for cudaminer_LDADD in the Makefile and add -lssl and -lcrypto.
|
|
|
|
|
I forgot to mention, when compiling the SHA patch on Linux I had to manually add -lcrypto to the linker flags in the Makefile. I imagine the configure.ac patch should have taken care of that. In any case it compiled on OS X just fine... configure appears to have added redundant -lssl and -lcrypto flags to LIBCURL.
Also, I've received my first payout, and it looks like more miners are starting to find their way to 1gh, I'm slowly getting bumped down the ranks of the front page.
|
|
|
|
is this the supposed fix? is it working ? I can integrate it if someone confirms it is good.
I got carried away with excitement and forgot about good ole jane. Here's the cpuminer linked at 1gh. Take a look in cpu-miner. https://github.com/1gh/cpuminerHave a look here as well http://max.1gh.com/user?wallet=mU9Q9BCWDRGLGUBM7qqPaKwyVgvoRmb5NuThat's my 780, a 660, and four 640s. The first two shares at the bottom were after the sha patch but before the difficulty patch. The 780 and 660 are on OS X and the others on Linux. I'm getting a lot of boos on the 780 though. I've tried playing with the kernel config to no avail, it doesn't seem to want to get better than ~75% acceptance rate. I should be getting ~350 MH/s. 1gh only reports 230. |
|
|
|
cbuchner1, any idea if you have the time to fix the cudaminer to work with the pools?
If you're compiling yourself, stick that code I posted above in the appropriate place in stratum_gen_work, and apply the sha patch that was posted a few pages ago and you're good to go. I have 61/61 shares accepted on one of my cards in the last 3 minutes. (on 1gh) edit: randomly just got a dozen boos in a row, followed by more yays. A few cards at at 100%, a few mid 90s, but my 780 is at 75% :/ |
|
|
|
this tells me that cudaminer gets the difficulty wrong. So I have to compare the code that translates stratum difficulty into hash target.
if (opt_algo == ALGO_SCRYPT)
diff_to_target(work->target, sctx->job.diff / 65536.0);
else if (opt_algo == ALGO_KECCAK)
diff_to_target(work->target, sctx->job.diff / 256.0);
else
diff_to_target(work->target, sctx->job.diff);
|
|
|
|
Can any mathmagicians out there tell me the chance of getting a block in 24 hours at currently diffuculty with 18mh/s? Or how to work this out. I take it difficulty is around 400 now? (Cant seem to type anything into cmd prompt while cuda is running  ) roughly: you take the net hashrate that you divide by your own hashrate then you multiply that by the time between two blocks That should give you the time for you between two blocks (average time) was unlucky because, it took me 2 to 3 hours to connect the wallet. But so far I have been able to get 2... So this would be 63.029.672.023 / 125.000 * 30 = 15.127.121,28552 seconds or 4.202 hours !! Really ?!? It's 175 days !  actually 63etc... is in hashes/sec and 125000 is in khash/s Odds of finding any particular block 125000000 / 63029672023 = 0.00198319293 The odds that you won't find any particular block. 1 - 0.00198319293 = 0.99801680707 The odds that you won't find a single block out of 2880 blocks. (2880 = 24 * 60 * 60 / 30 i.e. number of blocks per day) 0.99801680707^2880 = 0.00328868748 Odds of finding a block in 24 hours. 1 - 0.00328868748 = 0.99671131252 or 99.67% chance of finding a block in 24 hours. 94% in 12 hours. 76% in 6 hours. 51% in 3 hours, etc. |
|
|
|
@cbuchner1:
May I make a developer suggestion? Could you "branch" in Github, away from the master, the next time you want to experiment and upgrade code? It was quite difficult to find stable scrypt versions during this last endeavor.
I think this is a good idea, but in the mean time, you can scroll through commit history looking for relevant comments or the date of that last known stable release, or click on "releases" on git hub, then click the hash stub of the appropriate release, copy the hash and just checkout that commit locally then checkout -b for your tinkering. Now that I look though, it seems there are no longer any releases or tags for anything prior to 2014-2-2 :/ I guess you probably already know all that. I had to checkout previous commits a few times in the last few weeks and didn't have too much trouble finding the appropriate versions, granted I probably pay too much attention to cbuchner's commits (I read the commit log more often than I do this thread) |
|
|
|
Sorry for question, but can you help to create cudaminer for Microcoin? As I see it must be like for YAC so it won't be difficult, but I never did it before and have no skills  Should be able to mine microcoin with the github version now, although given that its N factor is still low, performance won't be very good (It will be cpu bound by keccak). I believe cbuchner has plans to eventually push keccak to the GPU, but until then you might be better off with a scrypt-jane patched cgminer, although I haven't seen any binaries floating around so you might be stuck compiling that yourself as well. I've just managed to get a personal stratum pool up and running. After several hours of fiddling with node.js implementations that weren't really cutting it I finally just set up MPOS. So now I'm thinking about doing some stratum modifications to include scrypt-jane parameters in the job transmissions, which would require modifying cudaminer to change configs on the fly. It would be nice to have config file where I can specify something like "GTX 780: 13, T12x32, L2 : 14, T12x28, L5" Right now I'm having to write scripts to handle different coins, configs, pools, and gpus. Eventually I'd like to set up a scrypt-jane multipool. Cbuchner why is your 780 doing so poorly? I thought you were getting 3.6 kHs before lookup gaps. It looks like several of us are getting 5+ on Yacoin now. |
|
|
|
I've been playing with the lookup gap. My GTX 780 went from 3.7 kH/s to 5.0 kH/s on Yacoin with -L 5. (-L 4 produces 4.948, -L 3 4.535, and -L 2 was almost no improvement) My GT 640s received no benefit at N Factor 14. At N Factor 15 they produce 0.684 kH/s. If I recall they maxed out at at 0.6 previously. I've been mining an N Factor 13 coin as of late, and my 780 went from 10.7 to 16.0 kH/s with -L 3. Cudaminer does not fair well with NF=13 when I try to autotune with -L 3 if I don't also specify -lT. Masochist:CudaMiner mark$ ./cudaminer --algo=scrypt-jane:13 -d0 -m1 -i0 -L3 --benchmark -D
*** CudaMiner for nVidia GPUs by Christian Buchner ***
This is version 2013-12-18 (beta)
based on pooler-cpuminer 2.3.2 (c) 2010 Jeff Garzik, 2012 pooler
Cuda additions Copyright 2013 Christian Buchner
My donation address: LKS1WDKGED647msBQfLBHV3Ls8sveGncnm
[2014-01-18 22:09:13] 1 miner threads started, using 'scrypt-jane' algorithm.
[2014-01-18 22:09:13] DEBUG: got new work in 1 ms
[2014-01-18 22:09:13] Given scrypt-jane parameters: 13
[2014-01-18 22:09:13] Nfactor is 13 (N=16384)!
[2014-01-18 22:09:20] GPU #0: GeForce GTX 780 with compute capability 3.5
[2014-01-18 22:09:20] GPU #0: interactive: 0, tex-cache: 0 , single-alloc: 1
[2014-01-18 22:09:20] GPU #0: 8 hashes / 5.3 MB per warp.
[2014-01-18 22:09:22] GPU #0: Performing auto-tuning (Patience...)
[2014-01-18 22:09:22] GPU #0: cudaError 2 (out of memory) calling 'cudaMalloc((void **) &d_idata, mem_size)' (salsa_kernel.cu line 499)
[2014-01-18 22:09:22] GPU #0: cudaError 2 (out of memory) calling 'cudaMalloc((void **) &d_odata, mem_size)' (salsa_kernel.cu line 501)
[2014-01-18 22:09:22] GPU #0: cudaError 11 (invalid argument) calling 'cudaMemcpy(d_idata, h_idata, mem_size, cudaMemcpyHostToDevice)' (salsa_kernel.cu line 506)
[2014-01-18 22:09:22] GPU #0: maximum warps: 527
[2014-01-18 22:09:22] GPU #0: cudaError 4 (unspecified launch failure) calling 'cudaDeviceSynchronize()' (salsa_kernel.cu line 534) It proceeds to repeat the last line for each warp in every block. More than a little spammy, though I guess I'm asking with it with the debug flag on, but I'm not really interested in waiting several hours for autotune to complete to find out what my optimal config is, particularly when I'm testing multiple lookup gaps with multiple N factors. It seems to autotune fine with -L3 if I specify -lT. It will not autotune with -L4 in any case, and will fail in the same fashion as above, although if I just give it a config, -L4 seems to work fine. I'm not too worried about it, looking at the -L2 and -L3 charts makes it pretty clear I was experiencing diminishing returns. |
|
|
|
|
