|
latest driver and LBRY sp-mod #5?
|
|
|
|
|
What is the most you can squeeze out of a r9 390 ?
|
|
|
|
Time for a new coin then.. Litecoin-classic  |
|
|
|
sp_ ,are you planning to create equihash mod?
I have already made one. Not for the public. I run it on some of my rigs. I am curious : what hashrate do you obtain with a GTX 1080/1070? Regards I get 275 on the gtx 1060 3gb with low power.. |
|
|
|
so no bitsend mod sp? i'm waiting for it the diff look still affordable
Tonight.. |
|
|
|
sp_ ,are you planning to create equihash mod?
I have already made one. Not for the public. I run it on some of my rigs. |
|
|
|
|
You need to profile each round and check the total time used. I believe round 7 and 8 are the fastest rounds. So then you need to add less blake2s instructions here.
|
|
|
|
Hello all! I need some expert advice... I have a 4 x 1070 (evga sc) rig, mining lbc, set to 49% power limit, doing about 230mhs per card, PULLING 860W FROM THE WALL! If I set PL to 60 or 70 or 80% the MHS/WATT is even worse. What is wrong here? I'm using a h81 pro btc, celeron 1820, 1x8gb ddr3, windows 10 64, last nvidia driver, I have done de bios update for mb and vgas, and I am using usb power risers. (using kill a watt to measure) Do you have a card wich use alot of power. With more than 1 8pin power adapter? The lbry mod is not compiled with compute 61, so the driver will compile a new kernel runtime. You can try to install an earlier driver like 376.xx. There are some reports that the latest driver is not so good for mining. Another thing you could try is to reduce the intensity. Run with -i 23 or -i 24 or less |
|
|
|
Spreadminer 10 Hangs the system..
Did you test the fixed_3 version? |
|
|
|
@Sp - would you please send me the fixed Spreadminer 10. I am running the original one you sent which is a little buggy. Hopefully this stops the crashes. Thanks - pokeytex
Sendt. Is this build more stable? |
|
|
|
Spreadcoin by itself is not attractive because of non delivery of promises. But there is a proposed "ecomony split" of 1 SPR to 1 HLM (Helium Coin) in the near future. HLM is very attractive as it will deliver what the community wanted all these while, Masternodes and Servicenodes and applications run on Servicenodes. SPR was 1.5k sat before the announcement. Mining SPR is betting that the economy split will happen.
Helium is developed by a former member of the DASH core development team... Could be interesting.. Movement in the Spreadcoin price after the news. (bittrex)  |
|
|
|
|
But you probobly lazy.
Try to run round0 with 1/5 of the intensity on all the threads<32 at the same time as round1. you also need to increase the total threads in the kernel by 32. and fix the indexing. you might need to remove 75% of the blake2s instructions as well to emulate the effect.(but keep the reads and writes to memory in round0)
How much slower is round1?
|
|
|
|
The only way to get 2 kernels to run in parallel is that if each kernels use only 50% of gpu usage. So in most case it isn't practical
Round0 is only using 20% of the time, so you can run the round0 thread at 25% speed and it still will complete the task before the other thread. Round 1-8 is spending most of its time on waiting for memory. so you can reduce the gpu load here as well) I just tried with software work (odd blockthreads doing round1, even blocks doing round0) and the results are worse, lower speed. Some more could be tweaked with proper parameters etc, but not much more, like I said, because of high amount of shared memory needed, there are only few blockthreads being run on a SM which lowers occupancy. And let's not forget that even round0 does what is the slowest thing of everything -> doing random memory writes which are hard to coalesce so there are many memory transactions. Round1 is not slow enough, so by dividing the load 50%. Round1 will run at round0 speed. (Slower) Try with 2 buffers and 2 streams let round0 run with very few threads emulate 25% gpu load) I've already outlined the pseudocode. |
|
|
|
lol why is that discussion happening on amd thread ? lol
parallelizing too ?
Because dual mining works on NVIDIA hardware and AMD hardware. Claymore have already done it... |
|
|
|
The only way to get 2 kernels to run in parallel is that if each kernels use only 50% of gpu usage. So in most case it isn't practical
Round0 is only using 20% of the time, so you can run the round0 thread at 25% speed and it still will complete the task before the other thread. Round 1-8 is spending most of its time on waiting for memory. so you can reduce the gpu load here as well) |
|
|
|
Is the spreadcoin worth it over the current price of zcash?
Yes. |
|
|
|
|
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. :-)
|
|
|
|
|
Show Posts
