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

[WaveRiderx]

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

[1713265787]

1713265787

[1713265787]

1713265787

[1713265787]

1713265787

[volapyk]

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!

[d0n4ald]

whats the dev fee for dstm? .  Is their a way to change the fee?

[lmannyr]

How can I run DSTM under OS X Terminal?

[Bibi187]

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 ...

[Atronoss]

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 ...

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

[Atronoss]

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.

[Bibi187]

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 ...

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 

[wetblanket]

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?

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.)

[wetblanket]

Just crashed again, this time:

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?

[gruvalex]

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?

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! 

[1gek]

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.

[calculatorduck]

Just crashed again, this time:

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

[Morama]

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

[akuci]

So the dev said that the new version will be released on weekend (last weekend) +- 2 days, let's hope it will be today.

[ZenFr]

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.

[akuci]

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.

[cannonballdex]

Agree, 2% dev fee for improvements and then after making a million a month they run off while the fees still roll in.

[Biggen1]

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.

[akuci]

Maybe failover pool options?
And lots of other functionalities that this miner lacks.