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

[Seb83]

Any improvement, been a while since a good upgrade?

No need to hurry when making 300k a month.

Good one

[1714529468]

1714529468

[1714529468]

1714529468

[Kaostechno]

Congrats @dstm
You are about to be included in NiceHash Miner thats 100K + users.
https://github.com/nicehash/NiceHashMinerLegacy/commits/master

Keep up the good work!

[NoOneLt]

lul thats stupid man.
ewbf = 3049
dstm = 3099 - 2% = 3037

Why use DSTM if earning less ? Makes no sense. And yes, --fee 0 works in EWBF.

Lul, guys here were right you are pretty stupid. Not stupid but actually dumb 3099 is actual numbers from pool. But of course brain dead people does not read or actually try something, they just whine all around

[Seb83]

lul thats stupid man.
ewbf = 3049
dstm = 3099 - 2% = 3037

Why use DSTM if earning less ? Makes no sense. And yes, --fee 0 works in EWBF.

Lul, guys here were right you are pretty stupid. Not stupid but actually dumb 3099 is actual numbers from pool. But of course brain dead people does not read or actually try something, they just whine all around

You cannot compare hashrate reported by the pool so precisely.
It is calculated with the actual shares that you send.

Therefore, it vary depending on the day you mine, the difficulty, the number of miners, the pool hashrate,  network congestion, the latency, luck factor, and so on...
Too many parameters for a 50sols difference over 3000sols.

Just rerun your tests and you'll see that you wont get the exact same numbers.

[NoOneLt]

You cannot compare hashrate reported by the pool so precisely.
It is calculated with the actual shares that you send.

Therefore, it vary depending on the day you mine, the difficulty, the number of miners, the pool hashrate,  network congestion, the latency, luck factor, and so on...

Better run your own tests... Lots of smart words put in one sentence but have no meaning all together.

[Seb83]

You cannot compare hashrate reported by the pool so precisely.
It is calculated with the actual shares that you send.

Therefore, it vary depending on the day you mine, the difficulty, the number of miners, the pool hashrate,  network congestion, the latency, luck factor, and so on...

Better run your own tests... Lots of smart words put in one sentence but have no meaning all together.

Hashrate reported by the pool is calculated with the shares you send -> not precise.
Hashrate reported by the miner -> real hashrate (if you trust the dev)

There... less smart words. Do you understand?

[fecker]

You cannot compare hashrate reported by the pool so precisely.
It is calculated with the actual shares that you send.

Therefore, it vary depending on the day you mine, the difficulty, the number of miners, the pool hashrate,  network congestion, the latency, luck factor, and so on...

Better run your own tests... Lots of smart words put in one sentence but have no meaning all together.

lol u cant use pools numbers to compare. once ur up and once down.

[minebomb]

Hi

Does the --target-temp feature work in simplemining?
It seems smos is overriding that miner option.

 I receive 'ssl want write' error when using an ssl connection. It happens on two separate pools. It happens intermittently.

How can I set miner to reload when internet connection fails? sometimes if internet connectivity is unstable then the miner does not recover and begin working properly again. It kind of times out.
 
Please advise.

[dstm]

Have you figured out the weird case where hashrate of a card dropping to about half of it after hours of completely stable running?
The rig has to be restarted in order to restore the appropriate hashrate.

https://bitcointalk.org/index.php?topic=2021765.msg29004024#msg29004024

[dstm]

========== Sol/s: 1882.1 Sol/W: 3.31  Avg: 1864.7 I/s: 1005.4 Sh: 6.80   0.99 100
2018-01-23 19:52:16|   GPU2  61C  Sol/s: 301.5  Sol/W: 3.33  Avg: 300.9  I/s: 163.1  Sh: 1.07   0.99 94  
2018-01-23 19:52:16|   GPU3  59C  Sol/s: 321.4  Sol/W: 3.51  Avg: 309.2  I/s: 168.6  Sh: 1.16   0.99 78  
2018-01-23 19:52:16|   GPU0  63C  Sol/s: 327.6  Sol/W: 3.04  Avg: 328.6  I/s: 176.5  Sh: 1.17   0.99 183
2018-01-23 19:52:28|cudaMemcpy 2 failed
This is an overclocking problem, I think? But what GPU? The numeration is similar to 0123?

and what about cudaMemcpy 2 failed.
And the numder, is this a 3rd videocard?

Yes, that's the result of unstable hardware.
I'll improve the error message in this particular case such that zm reports the affected GPU.

[dstm]

Having this issue & yes, on SMOS. Would just replace SMOS with Ubuntu if I could but only have remote access to rigs. Might need to mod SMOS source to fix :/

Recently i rolled update which limited number or running nvidia-settings processes which caused big load which caused most probably speed degradation mostly on motherboard H110.

Thank you tytanick.

[dstm]

Any improvement, been a while since a good upgrade?

ZM needs some additional work I was previously not focusing on - this delays the release of 0.6 unfortunately.

[dstm]

I actually advocated EWBF earlyer, but sticking with DSTM now Test ended with average 3049 EWBF vs 3099 DSTM. 50 free hashes? Sounds good for me... --fee 0 didn't helped EWBF. And at least in my case i still see 2% less shares then reported by miner. And even some say they see 1% reduce it still does not save EFBW.

And this is GDDR5X cards witch presumably should have worked better on EFBW.

P.S. I am not related to DSTM or EFBW in any way, long time used both but recent discussion in DSTM thread pushed me to do a test myself. Believe me or not, this was exactly same machiene of 6x1080 (non ti) not tweaked in any way for one or another miner, and it was not even restarted during test period.

https://imageking.eu/images/dstmcompar.png large image



So for us miners it is actually bad, DSTM does not have competition and would get out even with 3% fee....

I won't increase it.

[bluepr0]

Any chance to add pool failover support @dstm?. With EWFB I can setup several pools in case one of the fails

[dstm]

The demand on memory performance degrades with lower difficulty tests.
I would not trust anything running for short amount of time. EWBF for me died when he cannot even provide a binary over Google Drive (Trojan detection.)
DTSM became the miner of my choice thanks to a benchmark posted on http://www.zcashbenchmarks.info/

Thanks for the points - suggestions are welcome ofc.

I still stand with my first assessment that the main downfall of this client is the ability to communicate and state things clearly...

 - Difficulty is not a float, but hex

do you mean difficulty should be mapped to a smaller range such that it's easier to read? Float is a datatype representing real numbers it's not related to the radix/base that's used for representation.

- Log is just an extension of the command line output
 - Command line output is just a status message

I'm not sure why you have them impression it's 'just a status message' - it's actually much simpler to print events on a separate line - simply at the time they happen. Currently zm collects all the performance data and events for each GPU separately during a period of time. It calculates averages etc. and presents it in a compact structured way - otherwise you'll end up with a lot of unstructured spam on your ui.

- Telemetry replaces command line output (Good thing)
 - Current log makes little sense without further tools. (I would appreciate more details)

What details are you missing? And how is it related to tools you would not need otherwise?

I think the log should contain:
 - TCP communication details (Hostname, IP, Port)

It does.

- Share details (More than just + or *)

What per share details are useful and what's the use case for it? This would require to print each share on a separate line. If it's useful - I'll restructure the logfile format ofc.

- no performance ticks (Could be replaced by TXT file for benchmarking.)

It's in the logs such that you're able to check if something was affecting the performance on your rig in the past which helps debugging performance issues.

Anyway I am looking forward to new versions, but I am sticking with 0.5.7. Performance on 0.5.8 is worse for me CPU wise.

Now that's is a very useful information. If there are any regressions between the versions - pls report them - I can't fix them otherwise and they might appear in later versions too. How much did the cpu load increase for you?

[CarlOrff]

You are talking of the new 0.6 DSTM version since a lot of time.
You told that 0.5.8 version to be a temporary version.
When do you think releasing 0.6 version and what will be new with it ?
Thank you.

[dstm]

Hi, just switched 9 rigs to DSTM 0.5.8, using ethos 1.2.9.  I have a question regarding CPU Usage and was wondering if anyone has found and solution for this, here's the details

Rigs 6/7/8/9- Biostar TB250-BTCPRO/i3 7100 3.9ghz/120GB SSD/8GB RAM/12GPUs x Gigabyte 1070 Windforce OC
Rigs 10/11/12/13- ASROCK H110 Pro BTC/i3 7100 3.9ghz/120GB SSD/8GB RAM/13GPUs x Palit 1070 Super Jetstream
Rigs 14- Biostar TB250-BTCPRO/i3 7100 3.9ghz/120GB SSD/8GB RAM/12GPUs X Palit 1070ti Super Jetstream

DSTM miner program CPU load
Rigs 6/8/9 - 60% to 70%
Rig 7 - 30% to 35%
Rigs 10/11/12/13 - 65% to 75%
Rig 14 - 60% to 70%

All of the run of similar OC's and Power settings, I have been trying to figure out why the CPU usage Load on all these rigs are high except for Rig 7.  Has anyone have similar issues?

This might be the effect of CPU frequency scaling - especially since rigs 6/7/8/9 have same hardware. It's optimal (optimal with respect to power cosumption) for the cpu to reduce it's clocks as much as possible. You'll see a higher cpu utilization ofc if the cpu is running on low clocks. Try to disable CPU frequency scaling / set it to performance mode to get reliable data.

[dstm]

Hi

Does the --target-temp feature work in simplemining?
It seems smos is overriding that miner option.

I suggest you to ask this on the SMOS forum.

I receive 'ssl want write' error when using an ssl connection. It happens on two separate pools. It happens intermittently.

This is not an error. It's there to make debugging easier in case something goes wrong with ssl connections.

How can I set miner to reload when internet connection fails? sometimes if internet connectivity is unstable then the miner does not recover and begin working properly again. It kind of times out.
 
Please advise.

What version are you on? Previous zm versions had a reconnect timeout - current version doesn't.

[dstm]

Any chance to add pool failover support @dstm?. With EWFB I can setup several pools in case one of the fails

0.6 has it. It's priority based, zm switches to the pool with the highest priority after it gets reachable again.

[Andrey09]

In the new version 0.6.0, do not expect an increase in performance?