Dstm’s Zcash Cuda miner

Writing autorestart in normal language is impossible and I can explain why.

Many people’s think that somewho wants to trick them, so they will not run any .exe or etc compiled files. They need simple opensource files with possibility to edit by self.

I think that CMD is the best one. Simple read, simple change, simple to understand. Eat not so much resources like .exe. Working without any c++ libraries or another extra soft.

1 Like

True. Contacted with Dev. He will create what I need to start work. All is good. Now I’m finishing Claymore (finally!!!). Then I think ~1 week and I will rewrite my autorun to dstm.

4 Likes

i know thats why i write that i need to wait for it. i can do a simple bat file for cmd but doing it in C++ is something what i cant do never learned the higher programming languages only the simple ones (assembler, pascal/delphi) but that has been years ago.

Am I the only one not seeing any improve to the EWBF miner?

1 Like

No you’re not. I have a rig with some 1080Ti GPUs, and they don’t show any increase in hashrate compared to the EWBF miner. I’m going to check whether my CPU is bottlenecking, but it seems that the 1080-line, at least, don’t experience any significant gain (yet). What GPUs are you running?

Hopefully, dstm can optimize the miner for the most high-end Nvidia GPUs.

For the time being, I stick to the EWBF miner as it has a compatible and working watchdog script.

I tried with the rig in office which has one 1070.

how could the cpu be the bottleneck?

I can’t find the exact post, but I read that this miner uses more CPU power than EWBF. If the CPU is very low-end, there might be a possibility that the CPU bottlenecks the mining. Don’t know if that is a realistic problem, but I’d check the CPU usage when mining just to make sure.

Both my CPU frequency and utilization is higher with this miner compared to EWBF. I run 4x 1080Ti on an Intel Pentium G4400:

ewbfdstm

Version 0.5.3
cpu: reduce cpu load
con: fix recon loop
con: network latency measurement
ui: add accepted/rejected shares ratio
ui: add network latency
ui: add information about selected devices

Linux x64:
sha1 0583d59930a6160f80db612eae089c84712b5f44
https://drive.google.com/file/d/0B5QcL4Z6nYEPcHRuZk5LV3NXOUE

Win x64:
sha1 d20670a2f41834dfc0828946e187197c1c260992
https://drive.google.com/file/d/0B5QcL4Z6nYEPSm9yTmhDV1gwZ3c

4 Likes

Tested the miner for a whole night on all my rigs, apart from a connection problem at the start on one of them, works great, can’t wait for updates.

I like what you have done I wanted to say that upfront and first!
I liked that there is a message when a GPU fails that the user probably over clocked to much… Bravo for pointing it out!!!

I personally like testing all scenarios, and there is still a slight issue when the network connected drops, from what I can see / test.

To end on a positive note, I can tell you have so much more you can improve. I know this because I can O/c (far above EWBF) the heck of my hydro 1080 TI, get a stable average of 791 H/s with (a new personal best) STABLE max rate of 803.8 H/s
(second card is a 784 H/s Avg with a 797 H/s Stable max)(Stable = 120 minutes or more run time)

and looking forward to additional enhancements!

Edit**
You show Solutions and you show Sol / w , but you don’t show the wattage itself. It looks like you are more energy efficient and if this is the case this could help bring a few more people over while you are continuing to enhance your software. Is this or could this be in your next release?

It doesn’t seem as stable for me so far but when it’s running it is performing better than EWBF.

I have the Hydro too, curious what OC settings you are using?

Could be just me but interestingly the sols/w don’t seem to vary as much with variation of hashrate when compared to EWBF. My Sol/W always stays at 4.06 and 4.05 even though Sols is fluctuating.

As mentioned it would be good to have the wattage itself.


vs

I am currently running 150+ Core Clock, Power limit 67

I just want to say that I’m happy there is active development going on.

That said, with 12x 1080 ti systems I’m seeing very poor results for this miner. Here are two screenshots, one from Dstm’s latest and one from ewbf.

Same rig, taken within 30 seconds of stopping the Dstm process and starting the ewbf process.

These are water-cooled 1080ti cards that are only slightly overclocked at +80 +160 pl max 250w.

Running top showed each x server uses around 6-8% cpu for about 70% constant CPU load compared with 3-5% for ewbf.

Most of my rigs are 12x rigs that aren’t expecting high CPU usage.

Further, I do see higher numbers on an 8x gpu rig (also water cooled), but the problem is - and this is a huge problem - after subtracting out what the dev fee is from these numbers it ends up being that Dstm is no better than ewbf. That means that we’re all increasing the difficulty by using Dstm miner versus using ewbf where performance after dev fee is even.

The author of the miner mentioned on bitcointalk that the dev fee was calculated as one round every 50 rounds (100 rounds = 2% fee). For 1080ti cards with 775 Sol/s that means you’re mining 15.5 Sol/s for the dev, leaving you with 759.5 Sol/s. You can get that with ewbf.

Work still needs to be done on this to make it worthwhile for my rigs: lower CPU usage, lower dev fee (1%?) to make the difficulty increase worth it and 12x+ card stable support.

I will continue to actively test this and I’ll see if a faster processor/more ram
has a difference on a 12x system.

Off-topic comment, but I am just plain curious. Can you elaborate a bit, @root, regarding your 12x Ti water-cooled setup. Is this a custom pump/tubing combo?

These are all-in-one water-cooled cards. No custom water cooling. The environment these are running in is very cool though.

I’ve done more testing and have had another non-water cooled rig actually do better with the 12x setup. It might be due to CPU/ram amounts, I’m not sure yet. Still testing…

What is odd is that running ewbf produces a steady 250w usage per card. Running the Dstm miner on this one rig fluxuates the power significantly. I’m not sure why this is happening and I have another rig that it’s not happening at all. Is anyone else seeing odd power issues? This is my query to check the power:

nvidia-smi --query-gpu=index,temperature.gpu,power.draw,clocks.sm,clocks.mem,clocks.gr --format=csv,noheader

If there is at least 10% hashrate increase in later versions for a 1080ti, I think it will be worth it to upgrade to a multicore processor

1 Like

Hmm, on my “non-miner” pc that I use for work and gaming, I have a founders edition 1080ti, watercooled.

I mine with it overnight and actually got an avg of 798 sol/s, finally saw over 800 sol/s in some instances.

linda on the forum is saying that she thinks that the program is saying more sol/s that it really is.
does somebody else noticed something like it?

This is what she said:

1 Like

Isn’t it showing more sols on the mining rig because of the dev fee?

That’s how I understood it as well. However I have to say, my experience has been the opposite from @Linda’s. I’ve definitely noticed an increase in Sol/s on the pool side moving from EWBF to dstm’s miner. I’m running 2 rigs on dstm and 2 on Claymore (AMD cards) and there’s roughly 80-100 Sol/s increase on the pool when using dstm’s miner on the 2 machines.

1 Like