|
2 kernels can ofcourse be executed at the same time but you need to specify seperate stream for both of them.
(if you don't specify a stream they both go to the default stream and are executed serially)
Serial execution: one stream (the default stream)
Paralell execution: two streams.
Make sure that the serialstrem kernel code use async kernel calls like cudaallocasync etc. You also need to make sure that the kernel isn't using all of the resources on the chip. Like threads per block. Running round0 with 32 threads per block or less should be enough...
|
|
|
|
Use double buffer and 2 cudastreams in parallell. do 1.launch round0 buffer1 (thread1) 2.launch round1-round8 buffer2 (thread2) sync swap buffer pointers loop Or permute the rounds so that the round that give the most speed is executed in parallell. Here round3-round8 is Running at the same time as round0: f.ex do launch round1-round2 (thread2) wait for thread2 1.launch round0 buffer1 (thread1) 2.launch round3-round8 buffer2 (thread2) sync swap buffer pointers loop round0 take around 20% of the total time Kernel calls are asynchronous from the point of view of the CPU so if you call 2 kernels in succession the second one will be called without waiting for the first one to finish. It only means that the control returns to the CPU immediately.
On the GPU side, if you haven't specified different streams to execute the kernel they will be executed by the order they were called (if you don't specify a stream they both go to the default stream and are executed serially). Only after the first kernel is finished the second one will execute.
This behavior is valid for devices with compute capability 2.x which support concurrent kernel execution. On the other devices even though kernel calls are still asynchronous the kernel execution is always sequential.
Check the CUDA C programming guide on section 3.2.5 which every CUDA programmer should read.
http://stackoverflow.com/questions/8473617/are-cuda-kernel-calls-synchronous-or-asynchronous |
|
|
|
I will definitely look into further optimizations for Round 0. I think sp_ was talking not about reusing the Blake calculations but executing Round 0 of the next Equihash run in the background during Rounds 1 through 8. I did notice the VALU was being idle quite often during memory transfers but did not know what to do with it until now. I should be able to implement this idea *pretty* soon.
Just running multiple instances of the kernel should help; just don't launch them at exactly the same time. Ideally the 2nd instance should be launched after the first has finished round0. But you want to make sure than round1 starts at exactly the same time as round0. running with multiple threads, sometimes help, and sometimes not. With proper code, you can make sure that this always happens. No need for 5 threads. (nicehash dj-ezo kernel on the gtx 1080) |
|
|
|
|
Spreadminer 10+ sendt to the spreadcoin donators.
-Bether speed on the 1080 and 1080ti.
-removed realtime priority (casued crash and freeze on some rigs)
-added cudart32_75.dll in the archive. :-)
|
|
|
|
Maibe you can do a dual miner , you should focus on Ethash too, give time to ideas cook in you head, them you go back to equihash
Could the blake2s pass be removed completely (round 0)? Dual mined with the memory accesses? I am not talking about 2 threads, but one thread with the round0 merged into the other rounds. The miner will need to do 1 nonce search(round1-round8) and one blake2s (round0) merged into the round1-round8 code per iteration. Since you work on the round0 data from the previos run, the nonce found would be the result of the previous padding data. On NVIDIA round0 take 20% of the time. (The opensource ZEC DJezo kernel) Jeeesus, sometimes I think sp_ is a jerk and sometimes normal...I believe either you have personality disorder or your account is being used by 2 different people... I just pointed the opensource development into the right direction. Time to give team Claymore some opensource competition... |
|
|
|
You've become just another miner dude.
I am a miner. |
|
|
|
Commits doesn't mean it's faster at what it does. Also what is changed after he's modified your code also doesn't mean it's not in your source. Yeah, shit you might actually need to look at what he changed in the code instead of just merging it...
2 ppl have done changes in the same sourcecode that cannot be merged without alot of manual work. The pullrequest's will cause my git to fail to compile. So what is the point.. |
|
|
|
Someone wants to merge some old Klaust commits from back in 2015. No improvements. What's the point of merging the fork's when I have done 1079 commits after I branched from ccminer tvpruvot, and tvpruvot has done 683 commits in the same time..  What's the point of merging the fork's when I have done 682 commits after klaust forked my work. The sourcecode tree is too different.  |
|
|
|
|
I wrote in the other thread:
A possible speedup for equihash
Could the blake2s pass be removed completely (round 0)? Dual mined with the memory accesses? I am not talking about 2 threads, but one thread with the round0 merged into the other rounds.
The miner will need to do 1 nonce search(round1-round8) and one blake2s (round0) merged into the round1-round8 code per iteration. Since you work on the round0 data from the previos run, the nonce found would be the result of the previous padding data.
On NVIDIA round0 take 20% of the time. (The opensource ZEC DJezo kernel)
|
|
|
|
Maibe you can do a dual miner , you should focus on Ethash too, give time to ideas cook in you head, them you go back to equihash
Could the blake2s pass be removed completely (round 0)? Dual mined with the memory accesses? I am not talking about 2 threads, but one thread with the round0 merged into the other rounds. The miner will need to do 1 nonce search(round1-round8) and one blake2s (round0) merged into the round1-round8 code per iteration. Since you work on the round0 data from the previos run, the nonce found would be the result of the previous padding data. On NVIDIA round0 take 20% of the time. (The opensource ZEC DJezo kernel) |
|
|
|
This is intriguing when you run 8 rigs in an apartment (48x GTX 1070) as the outside temp starts to warm up. It's also interesting because at 70-75 TDP I could easily run 3x rigs per 20A circuit.
I run 3x gtx 1070 rigs on 16A without any problems. |
|
|
|
Haven't seen a Pascal card to die because of high overclock. We did destroy one due to water leakage and some stuff was burnt on it, but never due to high memory clock and we are running them 24/7 mining. Just make sure you have adequate cooling, which you already need if you are mining 24/7.
I use oc and reduced TDP and have no 1070 cards RMA'd since september. (6 months running 100% mining) Of the gtx 1060 3gb's I have RMA'd 1% (6 months running 100% mining) |
|
|
|
I TRIED THE "XEVAN" KERNEL--
Perhaps I should go back and try again. However, I pulled my light RX 460 rig off of CryptoNight with Wolf0's SGminer-GM, and ran my compiled SGminer on Xevan. I used a worksize of "64", and an Intensity setting of "12". Not Rawintensity, or Xintensity, just Intensity. I also tried worksizes of "256" and "16". The larger worksize got a hashrate of 450kH/s on one GPU before crashing. The smaller worksize of "16" got hashrates of ~32kH/s on each card., and ran without any accepts, or rejects.
The YIIMP pool reported 7-14kH/s for the miner when 1 or 2 accepts occurred. I never got more than 2 accepts per session. The miner reported 660kH/s for four RX 460 cards at the local console. Pulling my cards off of CryptoNight offset any gains made with BitSend coin during the 2 days I have been mining on YIIMP. I have some old 750ti SC cards I would rather be using to mine Xevan.
The algo does show promise. --scryptr
The bitsend rally continues.. I think we should get a working windows build of sgminer with NVIDIA support. I am busy this week, but perhaps I have some time later in the week. btw; didn't know that you could mine with profit on the rx 460. what hashrates are you getting? |
|
|
|
Volatile markets now. Difficult to select what to mine.
Equihash. There are a lot of ethbabies hoping on and off all the smaller coins which drives the revenue sub Equihash over the last week or two. They can't figure out what sort of impact they have on the network so they'll usually crash the difficulty and everyone ends up earning less. There isn't a single mainstream altcoin that's been earning more then Equihash unless you mined it more then when it got pumped. Library for instance is up, it'll be down in a couple hours when someone crashes the difficulty and mines it for a half a day. Everyone ends up losing, including the person that hops on the coin as their influence is almost immediately adjusted in terms of difficulty. There isn't 'coin hoping' anymore to earn a bunch of money. Xevan algo...
Very profitable for AMD if you have few cards, don't know why nobody is mining it. CPU unless there is a private miner, already looked into that a few months ago. Ah apparently there is a recent AMD miner. Having a niche coin to mine every once in awhile isn't necessarily a bad thing if you guys can get it up and running. There is a AMD sgminer, but it is not compiled..  IT COMPILES OK, BUT DOES NOT GENERATE MANY SHARES-- I was able to compile the source on linux and run the miner on YIIMP's Xevan pool. It did not generate more than a handful of accepted shares. No rejects, the miner ran at 150kH/s per GPU, but generated fewer shares than a CPU running at 1/10th the hash rate. --scryptr Did you try the xevan-mod or just xevan. What intensity? |
|
|
|
|
Anyone tested on the pools. I get a bit faster hashrate poolside with nheqminer than EFBW's miner. Probobly because of the donation code and poolswitching.. I am not using the excavator, but I guess same. somebody should setup a test and compare two identical cards for 24hours...
The excavator is good on the 1070, and not so good on the 1060 3gb...
|
|
|
|
Yes. 0.3.3b almost ready to release. I think tuesday or wednesday, because i need properly test it.
More speed? |
|
|
|
yeah that's the problem, but still this coin is delivering 1btc daily from emission, 12k coins(25 coins per block at 180sec block tiem) per day at 8k satoshi each
even if you compete with yourelf it's a good profit, sp i'm buying this miner if you do it
I think the difficulty will increase when the AMD ppl manage to compile the new gpu miner..  |
|
|
|
there is even a miner for it? i see no bench for nvidia
No. But I can make one.. good , what would be the speed 6-7MH per 1070? With 7MHASH you will earn 80 dollars / day per gtx 1070  xavan is 2 rounds of x17 1024 bit. So at best 1/4th of the speed of x17 but probobly less x17 on the 1080ti does 15MHASH. 3.75 MHASH might be possible on the top card (?) But I need to mod all the 17 algos to 1024 bit. padding byte mess. Alot of work. |
|
|
|
are you really eager to mess with padding on 17 algos? :-D
Not really.. But I could fix the opencl code to run on NVIDIA hardware. I see there is a faster Xevan-mod with wolf0 kernels on github... 9 days old. |
|
|
|
|
Show Posts
