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

new version works fine and stable. API works fine as well.
- could you please add current values in JSON as well and not only average values. ( i put all values into grafana for monitoring and statistics)
- lower sols/s on poolside is fixed. localy i have ~2644 and currently (after 24 hours) on flypool up to 2600- (even less than the devfee of 2%). So average Sols/s on poolside is now perfect. very well done.

Thx , Nvidia provides this information, will add.

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

Will add.

Hey dstm,

Is json-rpc missing shares? Accepted, Rejected.

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.

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.

nice to hear it!
good work @dstm 

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

Thanks you dstm , now windows version would be really nice

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:

and you'll get a response:

You can try it with netcat:

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

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.

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.

                                                                                                                       
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.


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.

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.

Windows Version would be really great

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

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

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

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.