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

[jmayniac]

ZM is reporting 2.6K Sol/s, but Flypool is only showing 2.4K Sol/s.  EWBF reports 2.5K Sol/s and Flypool shows 2.5K Sol/s.  ZM seems to be a little over on it's reporting.

How long did you run the test?
2.6 local vs. 2.4 pool , that's a difference of 8.3%, this is huge. There must be something wrong.
Flypool had performance issues today.
                                                                                                                              
My reported values are exact. I'm even rounding them down.
People reported me exactly the opposite, after they have done the comparison.
Did some one else made this kind of measurements? Any comments?

I've been running EWBF on Flypool for a few days and the average is 2.5K Sol/s.  I ran ZM for a few hours and the average dropped down to 2.3K Sol/s.  I'll run it overnight and see what it's like tomorrow.

[dstm]

difficulty was raised this morning btw.

from the flypool website:

In order to provide a more efficient mining experience we have increased the default share difficult on the #Zcash pool to 16000

Well that's one way to describe that your servers couldn't handle the amount of incoming shares and that you had to raise the difficulty to reduce them. However this is a good opportunity to test/improve  zm's networking.

@dtsmdstm: Found out that using a diff of 8000 with zm has a different effect than using it on (the) other miner(s). Currently mining Bitcoinz (BTCz) on suprnova and @ diff=8000 almost no shares are sent. Can you confirm that using your miner i.c.w. a multi GPU RIG has an effect on Diff. It looks like you need set/select a suitable Diff per GPU and not for the size of the total RIG.

It seems there is some misunderstanding about the difficulty. The miner does not set the difficulty by itself. The server sends messages and tells the miner what difficulty it should use. So if the server honors your diff=8000 setting it creates appropriate difficulty messages for the miner. I'll run some longer test the next days to check if there are any bugs and how the local solution rate compares to the pool side.

Edit:
The amount of shares the miner is finding is subjected to probability. It's a property of the problem we're solving. It might happen that you don't find any (or almost no) shares for a longer period of time. Pools are trying to infer the actual solution rate by the amount of shares they are receiving from you - since the amount of shares is subjected to probability the reported solution rate by the pool is pretty jumpy. You have really to run this for a longer period of time (something like a day) to make a robust statement.

[NameTaken]

Decided to try distributing my rigs out to various pools but with suprnova I'm getting disconnects and SSL_ERROR_WANT_WRITE.

http://termbin.com/41kn

[dstm]

Decided to try distributing my rigs out to various pools but with suprnova I'm getting disconnects and SSL_ERROR_WANT_WRITE.

http://termbin.com/41kn

Thx, wrong handling of SSL_ERROR_WANT_WRITE is fixed in the dev branch. I'll upload a new version most likely tomorrow.

[dstm]

I've done a 10h test on flypool: local 79.7 - pool 78.1  79.7/78.1=1.0204. I'll do some more test on different pools with a 10GPU system this week.

Edit:
1-(78.1/79.7) = 0.020075

[Gaglam]

Windows Version would be really great

[andi_21]

I've done a 10h test on flypool: local 79.7 - pool 78.1  79.7/78.1=1.0204. I'll do some more test on different pools with a 10GPU system this week.

Edit:
1-(78.1/79.7) = 0.020075

6x1070 System - local 2632 Sols
flypool: 2540 (24 hours average)
(1-(2540/2632) = 0.03495

Previously i had ~5% difference before flypool changed default diffictulty. Not sure what could be the reason of the remaining 1.495% difference ( 3,495%-2%) but for me low enough to "accept" it without further investigation.

- Is the miner already fully optimized or do you think there is even chance for further optimizations and few more sols/s ?
- miner is stable for me except that outage yesterday as flypool changed default difficulty. (manual restart of miner was necessary)
- could you also put timestamp for each line to console output? i created script to parse output and import data into grafana and timestamp would be usefull. as soon as API is available i wouldnt need it anymore ;-)
- thx for good work and enjoy your dev fee. i plan to use your miner on my 2nd rig as well as soon API is available.

[dstm]

I've done a 10h test on flypool: local 79.7 - pool 78.1  79.7/78.1=1.0204. I'll do some more test on different pools with a 10GPU system this week.

Edit:
1-(78.1/79.7) = 0.020075

6x1070 System - local 2632 Sols
flypool: 2540 (24 hours average)
(1-(2540/2632) = 0.03495

Previously i had ~5% difference before flypool changed default diffictulty. Not sure what could be the reason of the remaining 1.495% difference ( 3,495%-2%) but for me low enough to "accept" it without further investigation.

- Is the miner already fully optimized or do you think there is even chance for further optimizations and few more sols/s ?
- miner is stable for me except that outage yesterday as flypool changed default difficulty. (manual restart of miner was necessary)
- could you also put timestamp for each line to console output? i created script to parse output and import data into grafana and timestamp would be usefull. as soon as API is available i wouldnt need it anymore ;-)
- thx for good work and enjoy your dev fee. i plan to use your miner on my 2nd rig as well as soon API is available.

Previously i had ~5% difference before flypool changed default diffictulty. Not sure what could be the reason of the remaining 1.495% difference ( 3,495%-2%) but for me low enough to "accept" it without further investigation.                           

Some pool servers are having performance difficulties currently due to the massive increase of solution rate in Zcasch's network - so if you had some disconnects during the 24h period you've lost some shares.                                             
Also I'm using asynchronous queues and prepare some work for GPUs in advance, this is very helpful in situations where your cpu has load spikes, the miner doesn't drop it's solution rate even if you fully load your cpu with other tasks. However the consequence is that if you receive a new job you have some outdated work already in the driver queue which lowers the solution rate as seen by the pool. I've done some more statistics now - the queue sizes are rebalanced now.

                                                                                                                       
Is the miner already fully optimized or do you think there is even chance for further optimizations and few more sols/s ?     

                                                                                                                       
It's pretty well optimized, however I've some more Ideas I wanna try out, they require some more restructuring on the GPU-side however I wanna finish some important stability/feature work first.

could you also put timestamp for each line to console output? i created script to parse output and import data into grafana and timestamp would be usefull. as soon as API is available i wouldnt need it anymore ;-)                                       

I don't want to put more numbers on the ui, there are already lots of them now ;-). I'm planning to implement logfile support,logfile output will contain timestamps. The dev branch contains already API-support, it will be available in the next release.

[dstm]

New Version 0.5

con: support set_extranonce rpc
con: improve handling of temporary slow network conditions
con: add monitoring support using web browser
con: add monitoring support using json-rpc
mp: rebalance queue sizes - this improves the solution rate as
seen by the pool, especially on pool that submit new jobs often


This is a testing version, it has a lot internal changes and is less tested. Feedback on stability performance is welcome. Rebalanced queue sizes improve the solution rate on pool side, however this might reduce the performance in situations of heavy cpu load - pls check if there are any improvement on the pool side for you. Telemetry is pretty simple currently, if there is anything more you need - suggestions are welcome.

[NameTaken]

You can explain more what json-rpc.txt is and how to see miner stats in json format?

[dstm]

You can explain more what json-rpc.txt is and how to see miner stats in json format?

I have to write some more documentation when there is time for it ofc
For more description just start zm without parameters and you'll get help on the new telemetry option.

So if you start zm like this: zm ...... --telemetry=0.0.0.0:2222

Just send to the host zm is running on:

Code:

{"id":1, "method":"getstat"}

and you'll get a response:

Code:

{"id":1,"result":[{"gpu_id":0,"temperature":0,"sol_ps":0.00,"sol_pw":0.00,"avg_power_usage":0}],"error": null}

You can try it with netcat:

Code:

echo "{\"id\":1, \"method\":\"getstat\"}\n" |nc 127.0.0.1 2222

[Nokia555]

Thanks you dstm , now windows version would be really nice

You can explain more what json-rpc.txt is and how to see miner stats in json format?

I have to write some more documentation when there is time for it ofc
For more description just start zm without parameters and you'll get help on the new telemetry option.

So if you start zm like this: zm ...... --telemetry=0.0.0.0:2222

Just send to the host zm is running on:

Code:

{"id":1, "method":"getstat"}

and you'll get a response:

Code:

{"id":1,"result":[{"gpu_id":0,"temperature":0,"sol_ps":0.00,"sol_pw":0.00,"avg_power_usage":0}],"error": null}

You can try it with netcat:

Code:

echo "{\"id\":1, \"method\":\"getstat\"}\n" |nc 127.0.0.1 2222

[dstm]

Thanks you dstm , now windows version would be really nice

Right, I've bought it already and installed it on my pc, so the hardest part is done

[cryptoDahu]

Right, I've bought it already and installed it on my pc, so the hardest part is done

nice to hear it!
good work @dstm 

[dstm]

I haven't stated it clearly - some users were confused. All telemetry values are averages. Temperature is an exception, it shows the current temp.

The use case for telemetry I had in mind is like this: You don't look at it all the time. You check it let's say 5 times a day. So the averages are a much more accurate overview of the system than the jumpy values of the last run.

[jmayniac]

I haven't stated it clearly - some users were confused. All telemetry values are averages. Temperature is an exception, it shows the current temp.

The use case for telemetry I had in mind is like this: You don't look at it all the time. You check it let's say 5 times a day. So the averages are a much more accurate overview of the system than the jumpy values of the last run.

How about some color in the output, it will help to distinguish between items.  Right now with all the text it is hard to see data at a glance.

[Nokia555]

Hey dstm,

Is json-rpc missing shares? Accepted, Rejected.

[dstm]

Hey dstm,

Is json-rpc missing shares? Accepted, Rejected.

This is a testing version.... Telemetry is pretty simple currently, if there is anything more you need - suggestions are welcome.

Will add.

[Nokia555]

Hey dstm,

Is json-rpc missing shares? Accepted, Rejected.

This is a testing version.... Telemetry is pretty simple currently, if there is anything more you need - suggestions are welcome.

Will add.

If you can, add also fan speed, very useful for monitoring.

[dstm]

Hey dstm,

Is json-rpc missing shares? Accepted, Rejected.

This is a testing version.... Telemetry is pretty simple currently, if there is anything more you need - suggestions are welcome.

Will add.

If you can, add also fan speed, very useful for monitoring.

Thx , Nvidia provides this information, will add.