Okay, I must correct myself. DSTM said +- few days, so my mistake for saying "+- 2 days".
Still, we want more development with all the respect for his personal life.
Topic: [ANN] dstm's ZCash / Equihash Nvidia Miner v0.6.2 (Linux / Windows) - page 41. (Read 224961 times)
February 13, 2018, 12:58:24 PM
February 13, 2018, 12:40:24 PM
Maybe failover pool options?
And lots of other functionalities that this miner lacks.
And lots of other functionalities that this miner lacks.
February 13, 2018, 12:38:29 PM
What is it that you are hoping for? The miner is rock solid and "just works".
I guess hashrate improvement could really be the only thing and, sure, I'd love to see that too but I don't think that happens.
I guess hashrate improvement could really be the only thing and, sure, I'd love to see that too but I don't think that happens.
February 13, 2018, 12:33:12 PM
Agree, 2% dev fee for improvements and then after making a million a month they run off while the fees still roll in.
February 13, 2018, 10:38:32 AM
I'am just afraid that this miner will have a same fate like EWBF. The dev is less and less active, new versions comming out every like 2 months... I understand he has a real life besides this miner development stuff but still, I'm paying him 2% of my earnings to continue the development and keep him motivated, like everybody else do too.
February 13, 2018, 10:33:09 AM
So the dev said that the new version will be released on weekend (last weekend) +- 2 days, let's hope it will be today.
Hope too for today.Present version is "old" now, I'm very curious about what's new with this new version and hope some hashrate improvment :-).
Ready tu update my miners.
February 13, 2018, 07:49:55 AM
So the dev said that the new version will be released on weekend (last weekend) +- 2 days, let's hope it will be today.
February 13, 2018, 03:17:47 AM
A short question about DSTM and Nanopool (ZEC)
The miner works fine (great work @ DSTM!) and the hashrate on nanopool is as expected.
But in the Nanopool Mining Monitor App on Android, there is no "reported" hashrate shown.
Is there any parameter in the DSTM batchfile, which has to be set to report a "local" hashrate to the pool or is it a pool/app issue?
The app might be not the official app for nanopool...
Thanks for help
The miner works fine (great work @ DSTM!) and the hashrate on nanopool is as expected.
But in the Nanopool Mining Monitor App on Android, there is no "reported" hashrate shown.
Is there any parameter in the DSTM batchfile, which has to be set to report a "local" hashrate to the pool or is it a pool/app issue?
The app might be not the official app for nanopool...
Thanks for help
February 12, 2018, 04:17:58 PM
Just crashed again, this time:
right before the crash.
I'm not sure why this is happening all of the sudden as it's been really stable for awhile.
Code:
protocol version 01000030 not supported
right before the crash.
I'm not sure why this is happening all of the sudden as it's been really stable for awhile.
Based on the above, I'd guess that '01000030' is the stratum protocol "mining.notify" method job version for whatever pool you're connecting to - it seems that 0.5.8 added support for '01000020', but now '01000030' is also required. Meaning, pools are updating their software, but miners need to catch up. Is this on nicehash or suprnova (based on your previous posts)?
dstm, if I'm on the right track here, have you investigated whether dropping any job version checks is feasible?
That crash was on Nicehash. I had another one today that just returned:
Code:
2018-02-12 4:10:44 PM|# connection closed by server r:0
2018-02-12 4:10:44 PM|# reconnecting
2018-02-12 4:10:55 PM|# connected to: equihash.usa.nicehash.com:3357
2018-02-12 4:10:57 PM|stratum subscribe failed
2018-02-12 4:10:44 PM|# reconnecting
2018-02-12 4:10:55 PM|# connected to: equihash.usa.nicehash.com:3357
2018-02-12 4:10:57 PM|stratum subscribe failed
February 12, 2018, 03:21:20 PM
If it's one GPU on your main rig, then it's sharing it's resources with everything on that computer. The other thing is it could be overheating or if the power limit is too low. Either one of those will cause hash to start normal and then decline as both will lower the core frequency. What are your afterburner settings? What are the temps? Are you watching videos or anything else taxing the gpu? Is the CPU taxed? How much RAM?
Thanks to you and Smoreno for the response. Turned out to be an Awesome Miner setting. I had selected all of the individual miners in AM to autostart...cause that seemed like the thing to do. So basically all 4 cards I have were starting their own miner and the command line windows were reflecting basically 1/4th of the actual values. Turning off the autostart for 3 of the 4 cards in AM leaves me with only one window and the correct values. Lesson learned.
February 12, 2018, 01:59:02 PM
Trying to get some stats from my miner and noticed the JSON-RPC interface is broken.
$ curl http://192.168.1.6:2222 -X POST -D '{"id":1, "method":"getstat"}' -v
* Rebuilt URL to: http://192.168.1.6:2222/
* Trying 192.168.1.6...
* TCP_NODELAY set
* Connected to 192.168.1.6 (192.168.1.6) port 2222 (#0)
> POST / HTTP/1.1
> Host: 192.168.1.6:2222
> User-Agent: curl/7.57.0
> Accept: */*
>
{"id":1,"result":[{"gpu_id":0,.....cutting some useless stuff here....rsion":"0.5.8","error": null}
* Connection #0 to host 192.168.1.6 left intact
The reply is there, but the reply is not valid HTTP ('HTTP/1.0 200 OK' is missing from reply). Therefore most http-libs and browsers will not be able to use the data.
Can you please add the 'HTTP/1.0 200 OK' line to the json-rpc please?
$ curl http://192.168.1.6:2222 -X POST -D '{"id":1, "method":"getstat"}' -v
* Rebuilt URL to: http://192.168.1.6:2222/
* Trying 192.168.1.6...
* TCP_NODELAY set
* Connected to 192.168.1.6 (192.168.1.6) port 2222 (#0)
> POST / HTTP/1.1
> Host: 192.168.1.6:2222
> User-Agent: curl/7.57.0
> Accept: */*
>
{"id":1,"result":[{"gpu_id":0,.....cutting some useless stuff here....rsion":"0.5.8","error": null}
* Connection #0 to host 192.168.1.6 left intact
The reply is there, but the reply is not valid HTTP ('HTTP/1.0 200 OK' is missing from reply). Therefore most http-libs and browsers will not be able to use the data.
Can you please add the 'HTTP/1.0 200 OK' line to the json-rpc please?
From my experimentation and investigation, the JSONRPC interface here isn't broken. Devs choose what 'transport' flavors to support - the most common by far in the mining space is JSONRPC over plain sockets (either plaintext or TLS secured). "JSONRPC over HTTP" isn't frequently supported that I've seen.
I imagine dstm's decision for the stats/telemetry API was largely based on the informal consensus in the community to implement stratum spec with plain sockets only.
(Edit: I'm open to being wrong here... just observations based on what I've seen.)
That makes sense. I may just be confused that the same port is used. Then I guess my wish is this instead:
Can you please add statistics in json-format over http?
Let me GET /stats.json please!
February 12, 2018, 11:51:46 AM
Just crashed again, this time:
right before the crash.
I'm not sure why this is happening all of the sudden as it's been really stable for awhile.
Code:
protocol version 01000030 not supported
right before the crash.
I'm not sure why this is happening all of the sudden as it's been really stable for awhile.
Based on the above, I'd guess that '01000030' is the stratum protocol "mining.notify" method job version for whatever pool you're connecting to - it seems that 0.5.8 added support for '01000020', but now '01000030' is also required. Meaning, pools are updating their software, but miners need to catch up. Is this on nicehash or suprnova (based on your previous posts)?
dstm, if I'm on the right track here, have you investigated whether dropping any job version checks is feasible?
February 12, 2018, 11:47:45 AM
Trying to get some stats from my miner and noticed the JSON-RPC interface is broken.
$ curl http://192.168.1.6:2222 -X POST -D '{"id":1, "method":"getstat"}' -v
* Rebuilt URL to: http://192.168.1.6:2222/
* Trying 192.168.1.6...
* TCP_NODELAY set
* Connected to 192.168.1.6 (192.168.1.6) port 2222 (#0)
> POST / HTTP/1.1
> Host: 192.168.1.6:2222
> User-Agent: curl/7.57.0
> Accept: */*
>
{"id":1,"result":[{"gpu_id":0,.....cutting some useless stuff here....rsion":"0.5.8","error": null}
* Connection #0 to host 192.168.1.6 left intact
The reply is there, but the reply is not valid HTTP ('HTTP/1.0 200 OK' is missing from reply). Therefore most http-libs and browsers will not be able to use the data.
Can you please add the 'HTTP/1.0 200 OK' line to the json-rpc please?
$ curl http://192.168.1.6:2222 -X POST -D '{"id":1, "method":"getstat"}' -v
* Rebuilt URL to: http://192.168.1.6:2222/
* Trying 192.168.1.6...
* TCP_NODELAY set
* Connected to 192.168.1.6 (192.168.1.6) port 2222 (#0)
> POST / HTTP/1.1
> Host: 192.168.1.6:2222
> User-Agent: curl/7.57.0
> Accept: */*
>
{"id":1,"result":[{"gpu_id":0,.....cutting some useless stuff here....rsion":"0.5.8","error": null}
* Connection #0 to host 192.168.1.6 left intact
The reply is there, but the reply is not valid HTTP ('HTTP/1.0 200 OK' is missing from reply). Therefore most http-libs and browsers will not be able to use the data.
Can you please add the 'HTTP/1.0 200 OK' line to the json-rpc please?
From my experimentation and investigation, the JSONRPC interface here isn't broken. Devs choose what 'transport' flavors to support - the most common by far in the mining space is JSONRPC over plain sockets (either plaintext or TLS secured). "JSONRPC over HTTP" isn't frequently supported that I've seen.
I imagine dstm's decision for the stats/telemetry API was largely based on the informal consensus in the community to implement stratum spec with plain sockets only.
(Edit: I'm open to being wrong here... just observations based on what I've seen.)
February 12, 2018, 10:05:11 AM
Hey guys 
Anyone have issue with SHA-1 on this file ?
It seems last version available dont have correct SHA-1 as result.
Is what i get for zm 5.8 as SHA-1 with QuickHash 42F586F88866FA6D41E3E1CB91614C6E638B0905
Be careful ...
Anyone have issue with SHA-1 on this file ?
It seems last version available dont have correct SHA-1 as result.
Is what i get for zm 5.8 as SHA-1 with QuickHash 42F586F88866FA6D41E3E1CB91614C6E638B0905
Be careful ...
You hashed the zip/gz file, but you must hash the ...ehh...whatever it is called on Linux, in Windows it is .exe (executable) file
A common usage is to verify hash of archive not file it self
Thanks for reply
Everything look legit
February 12, 2018, 08:32:30 AM
How can I run DSTM under OS X Terminal?
You can't unless you run Boot Camp (install Windows) on your Mac. It is Linux or Windows program, not for OS X operating system.
February 12, 2018, 08:01:54 AM
Hey guys
Anyone have issue with SHA-1 on this file ?
It seems last version available dont have correct SHA-1 as result.
Is what i get for zm 5.8 as SHA-1 with QuickHash 42F586F88866FA6D41E3E1CB91614C6E638B0905
Be careful ...
Anyone have issue with SHA-1 on this file ?
It seems last version available dont have correct SHA-1 as result.
Is what i get for zm 5.8 as SHA-1 with QuickHash 42F586F88866FA6D41E3E1CB91614C6E638B0905
Be careful ...
You hashed the zip/gz file, but you must hash the ...ehh...whatever it is called on Linux, in Windows it is .exe (executable) file
February 12, 2018, 05:56:17 AM
Hey guys
Anyone have issue with SHA-1 on this file ?
It seems last version available dont have correct SHA-1 as result.
Is what i get for zm 5.8 as SHA-1 with QuickHash 42F586F88866FA6D41E3E1CB91614C6E638B0905
Be careful ...
Anyone have issue with SHA-1 on this file ?
It seems last version available dont have correct SHA-1 as result.
Is what i get for zm 5.8 as SHA-1 with QuickHash 42F586F88866FA6D41E3E1CB91614C6E638B0905
Be careful ...
February 12, 2018, 12:33:26 AM
How can I run DSTM under OS X Terminal?
February 11, 2018, 10:54:49 PM
whats the dev fee for dstm? . Is their a way to change the fee?
February 11, 2018, 04:47:42 PM
Any way to run DSTM on GPU 0,1 and 2 and disable mining on 3, 4 and 5?
put --dev 0 1 2 in your bat
Thanks!
Jump to: