If we don't set GPU intensity does it default to 100%? or should be set GPU intensity to 1.0?
Intensity is only used to reduce the GPU load. You don't need to set anything if you want it to go full speed.
Topic: [ANN] dstm's ZCash / Equihash Nvidia Miner v0.6.2 (Linux / Windows) - page 34. (Read 224961 times)
February 20, 2018, 07:47:13 AM
Intensity is only used to reduce the GPU load. You don't need to set anything if you want it to go full speed.
February 20, 2018, 07:45:43 AM
@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.
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.
February 20, 2018, 07:44:47 AM
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 ?
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.
February 20, 2018, 07:44:04 AM
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.
February 20, 2018, 07:43:31 AM
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.
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.
February 20, 2018, 07:42:47 AM
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.
Otherwise the hashrate is the same, I guess 800Sol/s is wishful thinking.
ZM doesn't support colorized output on Windows 7 terminals.
February 20, 2018, 07:41:36 AM
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:
ewbf seems to work, would really like to switch to dstm though.
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
# 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.
February 20, 2018, 07:40:08 AM
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
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.
February 20, 2018, 07:39:27 AM
Just crashed again, this time:
right before the crash.
I'm not sure why this is happening all of the sudden as it's been really stable for awhile.
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.
February 20, 2018, 07:38:19 AM
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 ...
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.
February 20, 2018, 07:37:30 AM
whats the dev fee for dstm? . Is their a way to change the fee?
The fee is exactly 2%, it can't be changed.
February 20, 2018, 07:36:55 AM
Interesting miner.
We would be interested in a chat if you are interested in working privately also.
#crysx
We would be interested in a chat if you are interested in working privately also.
#crysx
Sry, but I'm not releasing private versions.
February 20, 2018, 07:35:56 AM
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) ?
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.
February 20, 2018, 07:34:05 AM
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.
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.
February 20, 2018, 07:33:37 AM
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
# 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.
February 20, 2018, 07:32:30 AM
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.
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.
February 20, 2018, 04:36:05 AM
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.
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.
February 20, 2018, 02:35:03 AM
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.
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.
February 20, 2018, 01:02:11 AM
Hi.
Sorry for this Noob Question
but do this miner works on MPH to mine Classic too?
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
February 19, 2018, 10:59:17 PM
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.
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.
Jump to: