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

Hi DSTM!
When will the version 0.6.1 be released?

Hi DSTM!

Tell me where and what should be entered in the file json-rpc.th to display the current amount of hashed? Here is the current file:

Request:
-->{"id":1, "method":"getstat"}

Response:
<--{
    "id": 1,
    "result": [{
        "gpu_id":            0,         // GPU CUDA id
        "gpu_name":          "string",  // GPU name
        "gpu_pci_bus_id":    0,         // PCI bus id
        "gpu_pci_device_id": 0,         // PCI device id
        "gpu_uuid":          "string"   // GPU UUID
        "temperature":       0,         // current GPU temperature
        "sol_ps":            0.00,      // current Sol/s
        "avg_sol_ps":        0.00,      // average Sol/s
        "sol_pw":            0.00,      // current Sol/s / Watt
        "avg_sol_pw":        0.00,      // average Sol/s / Watt
        "power_usage":       0.00,      // current power usage
        "avg_power_usage":   0.00,      // average power usage
        "accepted_shares":   0,         // total amount of accepted shares
        "rejected_shares":   0,         // total amount of rejected shares
        "latency":           0          // network latency
    }],

    "uptime":   0,                      // uptime in seconds
    "contime":  0,                      // connection time in seconds (gets reset on reconnect)
    "server":   "string",               // server name
    "port":     0000,                   // port
    "user":     "string",               // username
    "version":  "string",                // zm version
    "error":    null
}



What do you need to write and where?

Hi DSTM!
I have a question about telemetry. The telemetry message does not display the latest, up-to-date information, but only the average value? It is quite logical to see the actual, the latest information, taken from the log of the miner, because possibly overclocking was increased, or other manipulations were performed and the average readings would not immediately reflect this change. In my opinion, the current hash is more important in monitoring than the average, which is smeared in time.

Thank you very much for your answer! When will the version 0.6.1 be released?

Hi DSTM!

After switching to the 2-nd pool from the config, after what time interval will the availability check of the 1st pool be? Last night, at 5-14, there was a reconnection to the 2nd pool, and back to 8-47 dstm for the 1st pool did not switch. At 8-47, I closed the program, reopened and the connection to the 1st pool was successful, although I suspect that it was already a long time working. After what time after switching to an alternative pool, is the availability check of the main pool checked?

2018-03-07 5:13:47|   ========== Sol/s: 4387.7 Sol/W: 2.91  Avg: 4364.8 I/s: 2338.9 Sh: 7.28   1.00 1607
2018-03-07 5:13:48|   GPU5  49C  Sol/s: 506.6  Sol/W: 2.93  Avg: 510.6  I/s: 273.6  Sh: 0.84   1.00 969 +
2018-03-07 5:13:49|   GPU6  52C  Sol/s: 511.4  Sol/W: 2.93  Avg: 511.4  I/s: 274.1  Sh: 0.87   1.00 953 +
2018-03-07 5:13:49|   GPU4  56C  Sol/s: 511.4  Sol/W: 2.98  Avg: 507.4  I/s: 272.3  Sh: 0.85   0.99 1828 +
2018-03-07 5:13:50|   GPU1  54C  Sol/s: 504.6  Sol/W: 2.89  Avg: 511.9  I/s: 274.5  Sh: 0.85   1.00 2969
2018-03-07 5:13:53|#  connection closed by server r:0
2018-03-07 5:13:53|#  reconnecting
2018-03-07 5:14:03|#  connected to: btcp.suprnova.cc:6822 [1/2]
2018-03-07 5:14:18|sinit timeout
2018-03-07 5:14:20|#  connected to: 94.23.199.191:3333 [2/2]
2018-03-07 5:14:23|#  server set difficulty to: 0004189374bc6a7ef9db22d0...
2018-03-07 5:14:44|>  GPU0  57C  Sol/s: 793.4  Sol/W: 2.85  Avg: 793.4  I/s: 424.9  Sh: 2.99   1.00 63  +
2018-03-07 5:14:45|>  GPU1  50C  Sol/s: 517.0  Sol/W: 2.92  Avg: 517.0  I/s: 275.9  Sh: 0.00   . .   
2018-03-07 5:14:47|>  GPU2  48C  Sol/s: 519.4  Sol/W: 3.11  Avg: 519.4  I/s: 275.2  Sh: 3.00   1.00 297 +


......



2018-03-07 8:47:26|#  zm 0.6
2018-03-07 8:47:26|#  GPU0 + GeForce GTX 1080 Ti      MB: 11264 PCI: 5:0
2018-03-07 8:47:26|#  GPU1 + GeForce GTX 1070         MB: 8192  PCI: 1:0
2018-03-07 8:47:26|#  GPU2 + GeForce GTX 1070         MB: 8192  PCI: 2:0
2018-03-07 8:47:26|#  GPU3 + GeForce GTX 1070         MB: 8192  PCI: 3:0
2018-03-07 8:47:26|#  GPU4 + GeForce GTX 1070         MB: 8192  PCI: 6:0
2018-03-07 8:47:26|#  GPU5 + GeForce GTX 1070         MB: 8192  PCI: 7:0
2018-03-07 8:47:26|#  GPU6 + GeForce GTX 1070         MB: 8192  PCI: 8:0
2018-03-07 8:47:26|#  GPU7 + GeForce GTX 1070         MB: 8192  PCI: 10:0
2018-03-07 8:47:26|
2018-03-07 8:47:26|#  using configuration file zm.cfg
2018-03-07 8:47:26|#  pool1 btcp.suprnova.cc:6822
2018-03-07 8:47:26|#  pool2 94.23.199.191:3333
2018-03-07 8:47:26|
2018-03-07 8:47:26|#  telemetry server listening on 192.168.1.103:2003
2018-03-07 8:47:26|#  connected to: btcp.suprnova.cc:6822 [1/2]
2018-03-07 8:47:28|#  server set difficulty to: 000f0f0f0f0f0f0f0f0f0f0f...
2018-03-07 8:47:50|>  GPU0  55C  Sol/s: 791.6  Sol/W: 2.83  Avg: 791.6  I/s: 422.0  Sh: 11.99  1.00 54  ++++
2018-03-07 8:47:50|>  GPU1  50C  Sol/s: 506.2  Sol/W: 2.90  Avg: 506.2  I/s: 270.4  Sh: 0.00   . .   
2018-03-07 8:47:52|>  GPU2  48C  Sol/s: 500.3  Sol/W: 2.99  Avg: 500.3  I/s: 270.7  Sh: 17.91  1.00 49  ++++++

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.