[ANN] dstm's ZCash / Equihash Nvidia Miner v0.6.2 (Linux / Windows)

[Biggen1]

Over 60° the cards start to throttle. Only 1-5 %. At 70° they throttle even more. Keep below 60° to get Full Power. Thats my experience with 3 setups with 1060 3/6GB, 1070TI and 1080TI.
And thats why your hashrate goes down after a while, cause VRMs/GPU and MEM is hot and the card slowy begin to throttle.

My setup after hours of mining:

ID   DEVICE NAME          °C   ∅ Sol/s   ∅ Sol/W   ∅ Watt
0   GeForce GTX 1080 Ti    50   652.34   4.11   158.67
1   GeForce GTX 1060 3G   50   277.33   3.86   71.92   
2   GeForce GTX 1070 Ti    52   491.61   4.58   107.23
3   GeForce GTX 1060 3G   49   274.56   3.83   71.74   
4   GeForce GTX 1060 3G   54   274.18   3.82   71.71   
5   GeForce GTX 1070 Ti    46   492.15   4.58   107.49
6   GeForce GTX 1060 3G   54   277.34   3.87   71.68   
Total   -                              2739.51   4.09   660.44   

The ambient temperature is 12° (thx winter)

Im using Win7 and the cards have these settings:

GTX 1060 3GB hynix: GPU +240 MEM +400 PL 60%
GTX 1070 TI : GPU +180 MEM +600 PL 60%
GTX 1080 TI : GPU +160 MEM -100 PL 60%

Theres a little room for stability. 1080 Ti runs since 1 year 24/7 with these settings without hassle. I prefer a rock stable system.
In a downtime you are losing money. So a little lower performance is okay for me.

The cards don't throttle at 60C.  I've never experienced anything of the sort.  They are designed to work at higher temps than that with no ill effects.

[jpl]

Where is the log file located?  I'm getting a crash 'cuda memory out of resources and fan's blowing like crazy all the sudden.  I just switched to 6.0,. then back to 5.8
All 6 1070's worked fine before.

Thanks in advance.

If you have not specified it will be in program directory" zm.log.
Running out of memory with ZM is really bad - equihash should not take more than 600MB on a card.

Ah.. i see...  readme.....  append --logfile
Now I just need to make it crash again. 

[powermickel]

Hi.
Sorry for this Noob Question   but do this miner works on MPH to mine Classic too?

Classic what? zclassic?  then yes.  This is a equihash miner so it will mine any coin based on the equihash algorithm no matter what pool its on in general..

Hi anotherwave! Thanks, yes I ment Zclassic but it was autofill who wrote Classic  LOL

[vision4u]

Hi there, since version zm_0.58_win i'm getting the following error while starting the miner even without ssl:// option...


2018-02-16 08:47:45|#  connected to: eu1-zcash.flypool.org:3333 [1/1]
2018-02-16 08:47:46|SSL_connect failed r:2 error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2018-02-16 08:47:49|#  connected to: eu1-zcash.flypool.org:3333 [1/1]
2018-02-16 08:47:50|SSL_connect failed r:2 error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2018-02-16 08:47:52|#  connected to: eu1-zcash.flypool.org:3333 [1/1]
2018-02-16 08:47:54|SSL_connect failed r:2 error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2018-02-16 08:47:56|#  connected to: eu1-zcash.flypool.org:3333 [1/1]
2018-02-16 08:47:57|SSL_connect failed r:2 error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

I'm running the miner zm_0.6_win under the latest version of W10 and W7 on 2 seperate PC's an getting the same error on both systems.

Is there any way to fix this?
Warm regards, Robert.

[OlimpFil]

to DSTM
The switch to the next pool does not work if the connection is lost. I tested it by blocking the address of the pool on the router, just everything was hanging without errors. Time in the log stopped and that's all.

[dstm]

I'm also seeing some sort of failure or disconnection recently on both of my rigs. I've been using this miner for a couple of months now and never had this issue but over the last week it's happened 3 times where the miner just disconnects and closes. I tried running it through Awesomeminer as well and it looks like Awesomeminer will try multiple times to restart it but each time it will fail to connect and then close/crash. If I wait a minute and try again manually it will work as normal. I didn't have logging enabled (but I do now) so I can't say much more than that, but this is the first time this has been happening to me.

When it happens, it happens on both of my nvidia rigs running DSTM. My AMD rig running claymore shows a disconnect, but it recovers. So it's definitely a connection issue with the pool or network connection since claymore shows it too, but DSTM doesn't recover for whatever reason. I've seen DSTM work fine after a pool error or disconnect before though, so I'm not sure what changed.

I've improved this code path in 0.6. Pls report if you hit this on 0.6 again.

[dstm]

Getting this with a Titan V:

#  zm 0.5.6
#  GPU0 + TITAN V                  MB: 12288 PCI: 1:0

#  GPU0  connected to: eu1-zcash.flypool.org:3333
#  GPU0  server set difficulty to: 0004189374bc6a7ef9db22d0...
gpu_id 0 0 0 invalid argument
gpu 0 unresponsive - check overclocking
cudaMemcpy 1 failed
#  recv failed: 10038
#  reconnecting

Me too.  EWBF works for Titan V but DSTM does not.  bminer does not work either.

I'll add support for Titan V in future versions.

[dstm]

Hello dstm,

Thank you for your great work. I have been using your software to mine for a while.
I would like to ask, if it possible to make your software "restart" after a cuda memory fail on a gpu.
I have several rigs running and I am not always checking on them, it`s not nice to see that I had one rig not working for a entire night or day because there was a error.
This happens more in rigs where I have 6 different gpu`s from nvidia, it`s not easy to find the best OC. So if, a error happens, it should be logged and the mining should restart. That way I would check for the logs and know that I should reduce a OC on a gpu but i wouldn`t lost several hours of mining.

Thank you very much and keep the good work.

Sorry about my poor english.

I've already done some tests with respect to this. This can't be done reliable from the context of zm. If an unstable/overclocked GPU crashes it stops responding to driver calls most of the time such that it's impossible to restart the GPUs from zm's context. You need something external - like a simple script - which restarts zm on GPU crashes. However this won't work reliable too - sometimes you have to restart your whole system after a GPU crash. If possible zm reports the affected GPU but even this is not always possible on unstable hardware.

[dstm]

Is DSTM 0.5.8. compatible with CUDA 9.0 and CUDA 9.1 ?

If it is, what are the expecting hashrate improvments with these two CUDA news versions compared to CUDA 8.0 version ?
It is for a use with GTX 750, 960, 1050Ti, 1070 and 1080Ti.

Or any benchmark link (not found with a quick search in Google) ?

ZM performs about 2% slower when compiled against CUDA 9.0/9.1.

[dstm]

Interesting miner.

We would be interested in a chat if you are interested in working privately also.

#crysx

Sry, but I'm not releasing private versions.

[dstm]

whats the dev fee for dstm? .  Is their a way to change the fee?

The fee is exactly 2%, it can't be changed.

[dstm]

Hey guys

Anyone have issue with SHA-1 on this file ?

It seems last version available dont have correct SHA-1 as result.

Is what i get for zm 5.8 as SHA-1 with QuickHash 42F586F88866FA6D41E3E1CB91614C6E638B0905

Be careful ...

You hashed the zip/gz file, but you must hash the ...ehh...whatever it is called on Linux, in Windows it is .exe (executable) file

A common usage is to verify hash of archive not file it self

Thanks for reply

Everything look legit 

ZM is often repackaged e.g. by pools, this is why the checksum is done against the executable.

[dstm]

Just crashed again, this time:

Code:

protocol version 01000030 not supported

right before the crash.

I'm not sure why this is happening all of the sudden as it's been really stable for awhile.

Based on the above, I'd guess that '01000030' is the stratum protocol "mining.notify" method job version for whatever pool you're connecting to - it seems that 0.5.8 added support for '01000020', but now '01000030' is also required. Meaning, pools are updating their software, but miners need to catch up. Is this on nicehash or suprnova (based on your previous posts)?

dstm, if I'm on the right track here, have you investigated whether dropping any job version checks is feasible?

Yes, that's right. Dropping version checks might lead to all kind of errors - since the assumptions about the structure of data might be wrong.

[dstm]

Code:

2036-02-07 07:51:45 AM|# connected to: eu1-zcash.flypool.org:3333
2036-02-07 07:51:46 AM|SSL_connect failed r:2 error:1416F086:SSL routines:tls_process_server_certificate:certificate verify fail
ed

Other rigs are connected, one refuse and I had to reboot rig.

The date is wrong on this system.

[dstm]

Thank you for version 0.6.0!

Still no stratum "client.reconnect" support? You mentioned it is in the works in November :/
From the Stratum mining protocol info: client.reconnect("hostname", port, waittime). The client should disconnect, wait waittime seconds (if provided), then connect to the given host/port (which defaults to the current server).


When trying to connect to miningrigrentals.com, it just loops through this failure:

Code:

unknown method client.reconnect
#  recv failed: 10054

ewbf seems to work, would really like to switch to dstm though.

Yes, you're right, this was requested by multiple people some time ago - sry but there was no time for it - I'll add support for it most likely in the next version.

[dstm]

Anyone else getting "Color mode not supported" in Windows 7 64-Bit? My Win10 64 has color.

Otherwise the hashrate is the same, I guess 800Sol/s is wishful thinking.

ZM doesn't support colorized output on Windows 7 terminals.

[dstm]

DSTM, could you make as option --white or --black web Ui? I guess white was better, All colors which we need in miner windows it's only GPU temps and total hashrate.

Gpu temps colors:

0-70 C - green color
70-80 C - ellow color
80-100 C - red color

We don't need all text as colored right now, just GPU temps and total information about speed, and may be Uptime in console window.

Tnx you.

The web-ui uses dark colors because it's easier on eyes especially in low light conditions - this was requested multiple times.

I can't do it simply this way, because thermal specification differ depending on your GPU generation and implementation - 70C green might be very misleading for some GPUs. One solution is to make this configurable.

[dstm]

i can't seem to get the intensity setting to work right.  i Have a 1080ti win7-64. It seems that when i use a setting of  .9 my hashrate will go from 700sol/s to 120sol/s.. lol which is a bit to low for %90 intensity.. Then if i use .1 which is %10 intensity i get 65sol/s. Is anyone getting this to work properly on their cards?

ZM uses performance data to normalize intensity values such that an intensity of 0.5 will reduce the load by roughly 50%. This is why it takes some time till intensity gets applied. However normalizing is difficult if your GPU is used by another programs during performance measurements - I'm taking care of this - however if it doesn't work reliable I'll switch the implementation to unnormalized values - this will be more difficult to configure but it will work reliable in all situations.

[dstm]

DSTM GPU miner version 0.6 is here, thank you DSTM :-).
A lot of new features, geat.
But no improvment about he hashrate.
Are we at the maximum of the possible hashrate with the Equihash algo or is there some possible improvment in the future ?

This is not easy to predict - zm is pretty well optimized - however I'll look into ways to improve the performance.

[dstm]

@DTSM

Bug found: Linux
When zm.cfg is present command line option to switch configs is ignored.
You cannot use 2 configs without isolating the entire directory.

I'm not sure if I'm understanding this correctly but having multiple configuration files in the same directory works fine for me.