Pages:
Author

Topic: [ANN] dstm's ZCash / Equihash Nvidia Miner v0.6.2 (Linux / Windows) - page 12. (Read 225062 times)

newbie
Activity: 29
Merit: 0
very buggy release. i am using hiveos. dstm 0.6.1.

1. gtx1080ti has hashrate around 200 sols
2. ping problem (already reported here before)

Same problem here... With gtx 1060, dstm 0.6.0 i get ~300 sol/s. Now with dstm 0.6.1 i get around 200 sol/s .
Whats wrong?
https://i.imgur.com/UKFqQvW.png

yes i can confirm that.

are those AMD machines ? i have the same effect on 2 other of these cheap AMD machines, but on the modern intel machine with gigabyte D3A H110 it has no issues and the 0.6.1 performs slightly better.

this is with 0.6 (and its even warm).
Code:
GPU1 56C Sol/s: 491.0 Sol/W: 4.33 Avg: 487.8 I/s: 261.2 Sh: 0.39 0.99 116
GPU0 60C Sol/s: 710.1 Sol/W: 3.58 Avg: 715.4 I/s: 383.2 Sh: 0.58 1.00 112
GPU3 60C Sol/s: 489.1 Sol/W: 4.33 Avg: 487.8 I/s: 261.2 Sh: 0.40 1.00 113
GPU2 52C Sol/s: 493.4 Sol/W: 4.36 Avg: 490.8 I/s: 262.8 Sh: 0.43 0.99 112
GPU4 61C Sol/s: 740.6 Sol/W: 3.68 Avg: 732.8 I/s: 392.4 Sh: 0.63 0.99 112
========== Sol/s: 2924.2 Sol/W: 4.06 Avg: 2914.7 I/s: 1560.8 Sh: 2.41 0.99 113

this is with 0.6.1 just started (so would get lower in a bit)
Code:
_ GPU0 58C 80% | 678.2 Sol/s 678.2 Avg 364.9 I/s | 3.44 S/W 202 W | 0.00 . .
_ GPU1 55C 80% | 474.4 Sol/s 474.4 Avg 254.7 I/s | 4.22 S/W 117 W | 0.00 . .
_ GPU2 50C 80% | 476.2 Sol/s 476.2 Avg 253.9 I/s | 4.31 S/W 104 W | 0.00 . .
_ GPU3 58C 80% | 462.7 Sol/s 462.7 Avg 249.3 I/s | 4.15 S/W 110 W | 0.00 . .
_ GPU4 58C 80% | 747.1 Sol/s 747.1 Avg 402.5 I/s | 3.78 S/W 179 W | 2.99 100 113
============== | 2838.7 Sol/s 2838.7 Avg 1525.3 I/s | 3.98 S/W 713 W | 2.99 100 113


hwinfo:  (its obviously one of my low ROI machines where i use an older downclocked energy save cpu, mb + mem in combination with a 1to4 pci extender. works flawlessly though. its 2x 1080ti 3x1070ti config. OS is SmOS.

Code:
Linux simpleminer 4.11.12-041112-generic #201707210350 SMP Fri Jul 21 07:53:15 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Code:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             AuthenticAMD
CPU family:            21
Model:                 48
Model name:            AMD A8-7600 Radeon R7, 10 Compute Cores 4C+6G
Stepping:              1
CPU MHz:               1400.000
CPU max MHz:           2800.0000
CPU min MHz:           1400.0000
BogoMIPS:              4990.45
Virtualization:        AMD-V
L1d cache:             16K
L1i cache:             96K
L2 cache:              2048K
NUMA node0 CPU(s):     0-3

cheers
jpl
member
Activity: 154
Merit: 11
New Version 0.6.1

I'm releasing 0.6.1 (an update of the 0.6 branch) instead of the planned 0.7 (based on new architecture) - mainly because 0.7's development takes more time than expected and due the recent events. It contains some bug fixes and improvements you have asked for. 0.6.1 improves the performance on linux-system by about 2% - unfortunately it's not possible to take advantage of this particular improvement on windows-systems. I've slightly changed the terminal-ui so if you're parsing it be aware of it. There is a second incompatibility: the cmd-line parameter '--temp-target' supports now the configuration of individual GPUs, it's syntax has changed because of this.

0.6.1
- fix failover-pool not switching back on ssl errors
- fix failover-pool not switching back on some servers
- add support for stratum's client.reconnect rpc
- support configuration of 'temp-target', 'intensity', 'pool' via cmd-line parameters
- report current difficulty and target on term-ui
- sort output by gpu_id on term-ui
- colorize temperature above 70°C on term-ui
- report intended fan speed on term-ui, web-ui, json-rpc
- report power consumption on term-ui
- improve performance on linux systems by ~2%

Thx!!

Question,. I'm getting one card color as dark orange sometimes on the end.. almost red.. says 605?    .. what is this?



It's network latency.

Thanks  Running great now for almost 24hrs 
newbie
Activity: 39
Merit: 0
So i get a strange thing happening in 6.1.  I have two 1080ti's on my comp and when i run my second card by itself the output shows only the first line of hash info and then stops displaying any info except for difficulty changes.  The card is hashing and is reporting on the pool but the output display just shows the difficulty changes. If i run my first card by itself and if i run the two cards together they output fine just how they are suppose to.. Must be a little glitch with running dev 1 only i guess. Anyone else running into this?   Great miner by the way..  https://imgur.com/a/BP5ulKB
newbie
Activity: 44
Merit: 0
very buggy release. i am using hiveos. dstm 0.6.1.

1. gtx1080ti has hashrate around 200 sols
2. ping problem (already reported here before)

Same problem here... With gtx 1060, dstm 0.6.0 i get ~300 sol/s. Now with dstm 0.6.1 i get around 200 sol/s .
Whats wrong?
https://i.imgur.com/UKFqQvW.png
newbie
Activity: 9
Merit: 0
@dstm
team-viewer issue fixed at 0.6.1. It's great, big thnks. no problem with latency time on win 10, and now in console all cards stats shown at same time not line by line (it's not a problem i think).
full member
Activity: 350
Merit: 126
very buggy release. i am using hiveos. dstm 0.6.1.

1. gtx1080ti has hashrate around 200 sols
2. ping problem (already reported here before)

Could you pls provide your configuration and terminal output?
The terminal-ui has changed in 0.6.1 - so if hiveos is parsing it you might get wrong values reported.
jr. member
Activity: 95
Merit: 2
yes you def need to turn power back up, i can tell those are 1070 ti, and also reading 50 less than it should be, and then about 100 less than on full tilt, power should be never below 84%, pretty much never above 92% unless catching up or something, currently my 1070 ti's are set to kernel mode, extended msi setting, 94% TPD, +176/+604 (lots of wiggle room with the 1070 ti's, once u go under about 88% the 1070z suffer really hard, keep that in mind when finding a lower efficiency setting.) hopefully a dstm update for windows comes out soon, as we have been waiting a while, 0.7 can be released now and 0.7.1 released in few weeks, we dont have much time so the dev needs to understand we need the miner up to date asap before asics hit and we have to switch coins to mine q=]  PS: 4 sols per watt is possible, but who is going to want nor need to turn a 1070 ti down to 58% TPD lol

Incorrect, they are 1070s not 1070TIs. I have, however, optimized their power consumption down to keep fan noise/speed and room temperature low. They are mining at respectable 1070 rates.

They have also been mining steady for weeks without crashing, until recently.
full member
Activity: 226
Merit: 100
Yeah, latency problems for me also.
newbie
Activity: 2
Merit: 0
New Version 0.6.1

I'm releasing 0.6.1
How can I choose some devices? the mode "dev = 0,1,3" does not work for 0.6.1. At 0.6.0, everything worked.
newbie
Activity: 21
Merit: 0
Hi @dstm,

when I use version 0.6.1, miner shows big network latency time.
In version 0.6.0 everything works normally.

http://i63.tinypic.com/x3cvop.jpg


Best regards

Is this really reproducible?

@dstm


Yes it is. Every time I run vesion 0.6.1 I have this problem.
Average latency in 0.6.0 is 60-80ms.
Also, I noticed that now miner shows all five cards at once. In version 0.6.0 there was a delay between each line 0.5 - 5s.

Best regards
newbie
Activity: 1
Merit: 0
Hey. Brilliant piece of software DSTM! But I've started to se errors while trying to connect to my pools now and I can't for the world figure out how to resolve this.

Could not setup ssl_ctx
ssl timeout r:2.

ZM 0.6.1 (and with 0.6 aswell). The client is now an Ubuntu R18 with openssl v1.1.0g – and I believe this might be the culprit. Clients are connected over vpn aswell.
Anyone sitting on knowledge regarding this?

later,
j.
full member
Activity: 350
Merit: 126
Hi, i have a problem, zm_0.6.1.tar.gz SHA1 not match.

Cheers W_M


Quote
Linux x64:
executable sha1 7a6f0eb858d8da18116b115a9b46f21187741f8a
https://drive.google.com/file/d/1JKeBTJshILqYpHiu7qRhjvcRhaa4NC5W
https://mega.nz/#!rXpjAC7D!1BLUk0PVwI9BMKLzk0HHUQLx4UBMEZL_1IXh1sJa6uU

The checksum is taken against the executable - this is because the archive is sometimes repackaged e.g. by pools.
full member
Activity: 350
Merit: 126
DSTM

The web interface still shows average card performance values. This is very inconvenient, because the current values are important. The cards sometimes falls a hashrate and your averaged values in the WEB and the interface do not allow this to be seen. You have to constantly monitor the log file to see the current actual data, and they are important. You can at least make this parameter functional; the average values make it difficult to quickly see the state of the hashrate right now. At the moment, I'm fine with everything your miner, but the average values interfere with normal monitoring of current performance. Here is a typical example, web monitoring shows a large hash, but the farm really needs to be rebooted urgently, because I saw the log file on time. Please make a display in the web monitor of the CURRENT hashrate.








Json-rpc contains the current solution rate.
However I see your point, I'll collect feedback during this week - afterwards I'll release an update - it will contain the current solution rate on the web-ui.
full member
Activity: 350
Merit: 126
New Version 0.6.1
...
- improve performance on linux systems by ~2%

You apply 2 queue per GPU, right? Make please option for switch between old/new modes for selected card. For example - like "dev=0,1,2" for old mode and "dev=0,0,1,2,2" for new mode (card 0 and 2 - 2 thread/GPU, card 1 - 1 thread/GPU)

Also, with v6.1:
gtx750 - SM5.0 - same performance, +1..2 sols/sec
gtx950 - SM5.2 - yes, +2% faster
gtx1050ti - SM6.1 - 1-2% SLOWER  Shocked

Rollback to v6.0  Sad

Thx for reporting performance measurements.

+1-2 Sol/s on an gtx750 are about +2%.

gtx1050ti / sm6.1: There is nothing special about sm6.1 in respect to this optimization. That's not what I'm getting.

Could you pls provide the log files of your tests?
A run of 5min (for 0.6/0.6.1) should be enough on a previously cooled down system.
full member
Activity: 350
Merit: 126
I was wondering what might be the reason for low amount of "+" for a gpu . Its seems like I do not get very many submitted shares. I have a 6 gpu rig running smooth about 690 sols per card  , no overclock ....any thoughts?

The amount of found shares depends on the difficulty which is set by the server.
full member
Activity: 350
Merit: 126
New Version 0.6.1

I'm releasing 0.6.1 (an update of the 0.6 branch) instead of the planned 0.7 (based on new architecture) - mainly because 0.7's development takes more time than expected and due the recent events. It contains some bug fixes and improvements you have asked for. 0.6.1 improves the performance on linux-system by about 2% - unfortunately it's not possible to take advantage of this particular improvement on windows-systems. I've slightly changed the terminal-ui so if you're parsing it be aware of it. There is a second incompatibility: the cmd-line parameter '--temp-target' supports now the configuration of individual GPUs, it's syntax has changed because of this.

0.6.1
- fix failover-pool not switching back on ssl errors
- fix failover-pool not switching back on some servers
- add support for stratum's client.reconnect rpc
- support configuration of 'temp-target', 'intensity', 'pool' via cmd-line parameters
- report current difficulty and target on term-ui
- sort output by gpu_id on term-ui
- colorize temperature above 70°C on term-ui
- report intended fan speed on term-ui, web-ui, json-rpc
- report power consumption on term-ui
- improve performance on linux systems by ~2%

Thx!!

Question,. I'm getting one card color as dark orange sometimes on the end.. almost red.. says 605?    .. what is this?



It's network latency.
full member
Activity: 350
Merit: 126
Hi @dstm,

when I use version 0.6.1, miner shows big network latency time.
In version 0.6.0 everything works normally.




Best regards

Is this really reproducible?
full member
Activity: 350
Merit: 126
Where can I find detailed info on all the config file options? Specifically how does one add failover pools in a config file?

This is described in the sample configuration file 'zm.cfg' which is inside the archive.
legendary
Activity: 1018
Merit: 1001
Hi, i have a problem, zm_0.6.1.tar.gz SHA1 not match.

Cheers W_M


Quote
Linux x64:
executable sha1 7a6f0eb858d8da18116b115a9b46f21187741f8a
https://drive.google.com/file/d/1JKeBTJshILqYpHiu7qRhjvcRhaa4NC5W
https://mega.nz/#!rXpjAC7D!1BLUk0PVwI9BMKLzk0HHUQLx4UBMEZL_1IXh1sJa6uU
newbie
Activity: 7
Merit: 0
DSTM

The web interface still shows average card performance values. This is very inconvenient, because the current values are important. The cards sometimes falls a hashrate and your averaged values in the WEB and the interface do not allow this to be seen. You have to constantly monitor the log file to see the current actual data, and they are important. You can at least make this parameter functional; the average values make it difficult to quickly see the state of the hashrate right now. At the moment, I'm fine with everything your miner, but the average values interfere with normal monitoring of current performance. Here is a typical example, web monitoring shows a large hash, but the farm really needs to be rebooted urgently, because I saw the log file on time. Please make a display in the web monitor of the CURRENT hashrate.

https://imageshost.ru/images/2018/05/14/web1.jpg
https://imageshost.ru/images/2018/05/14/web2.jpg



Pages:
Jump to: