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

0.5.8 links latest openssl statically, so it should work now.

It was requested multiply times, it's somewhat longer on my todo list, will add.

ZM performs about 2% slower when compiled against CUDA 9.0/9.1. CUDA 9.0 mainly introduces new synchronisation primitives.

Console, so bminer could very well be lying err, stretching the truth, but I will verify using the average difficulty for the last 24 hours once it has been running for that long.

I'm having problems with dstm 0.5.8 and EthMonitoring 0.29, anyone got it to work?

Are you looking into console stats or pool?

General question guys! How do you monitor your DSTM? Is it possible to receive email or maybe there is some phone app? What is your way? I came into some problems with pool monitoring so maybe i will need some local monitor solution.

Better watch out, dstm; I just switched over to bminer 4.0.0 and am getting about 5-7 Sols/s more out of each of my two GTX 1060 compared to dstm 0.5.7 and at the same power draw...

Anyone else running Linux with 12+ cards on a single motherboard? I have several Asrock H110 (13 pcie slots) and GTX1070 or GTX1070Ti.

Let's please share some experiences:

• which driver version is most stable for you? For 1070 Ti v384.98 crashes more than v387.34 for me. For 1070 (non-Ti) they seem happy with 384.90.
• have you found a solution to the driver setup delay when using all 13 cards? On v384.x it takes about 40 seconds for the driver to initialize before any card can be used (nvidia-persistenced or Xorg or nvidia-smi all trigger the same delay). On 387.x it seems it's taking over 60 seconds. I haven't found a way to get around it.
• for those who are also mining ethereum (via ethminer or claymore), are any drivers better than those you use to mine via dstm (equihash)?

I am seeing Devfees accelerating...
Is this to be expected?
https://mega.nz/#!JXhUEb4K!70-rEqMwK3ikdJKMxPGsaMBziv3Jf22DSWITvq6ugZY

Exactly! It's relatively easy to get an Ubuntu headless server running; tweaking nVidia OC settings on the command line is simple and scriptable. When big enough, I can see something like https://www.ansible.com/ being handy for managing rigs.

I was just saying that if you want something for free, it's probably going to be slower, not that slower means it needs to be free. C'mon, man.

   GPU4  55C  Sol/s: 497.6  Sol/W: 3.88  Avg: 504.0  I/s: 270.2  Sh: 0.33   1.00 59  +
   GPU2  54C  Sol/s: 497.4  Sol/W: 3.86  Avg: 500.3  I/s: 268.1  Sh: 0.30   1.00 64
   GPU3  54C  Sol/s: 490.2  Sol/W: 3.87  Avg: 501.5  I/s: 268.7  Sh: 0.33   0.99 60
   GPU0  55C  Sol/s: 499.9  Sol/W: 3.86  Avg: 501.4  I/s: 268.9  Sh: 0.32   1.00 66
   GPU5  55C  Sol/s: 496.3  Sol/W: 3.86  Avg: 501.2  I/s: 268.6  Sh: 0.32   1.00 63
   GPU1  55C  Sol/s: 498.3  Sol/W: 3.85  Avg: 500.0  I/s: 268.2  Sh: 0.34   1.00 59
   GPU6  54C  Sol/s: 501.0  Sol/W: 3.88  Avg: 502.5  I/s: 269.3  Sh: 0.32   0.99 57
   ========== Sol/s: 3480.9 Sol/W: 3.87  Avg: 3510.8 I/s: 1882.0 Sh: 2.26   1.00 61

Seven GTX 1070Ti pulling 130W each.  Core +200 Mem +700.  Rock solid on Ubuntu Server.  I don't even bother to actively monitor the rig.  Just SSH into it daily to make sure everything is running along.

Major concern in open source codes as this is the security issues to protect against
malwares and phishing softwares that may becomes serious bugs in the programme.
I guess if this is not sorted, it may affect the mining process.

Hi:
While something like Teamviewer can handle accessing & managing a non frozen or non-crashed system , we do often face crashes or unresponsive rigs what with bleeding edge overclocking etc.

I am asking for a little feedback on the below feature set(CA$HCUBE product dev) as I am looking at developing a system to auto reboot a (crashed/frozen) mining rig without having to monitor it or access smart plugs etc. People do sleep or go off grid from time to time (airplanes) and need a robust system to keep the rigs running.

I posted in another section of the forum, but the post disappeared, not sure why. So since the question is raised here, and I support DSTM I am posting here. Also, I am willing to establish comms from DSTM via USB/RS232 serial link to feedback total 'mains' power usage so DSTM can report on overall system hashing efficiency. This allows for CPU clock adjustment to optimize overall system power efficiency.
DSTM can also gain the option for a hard system reboot should it become necessary. I can see the miner sending a watchdog signal (once per minute)  to the CA$HCUBE, and, if this signal is lost the hard reboot sequence engages. This makes for faster 'crashed' system restarts and less mining downtime.

General Operation, miner & OS  independent.
1) To optimize your rig, plug the rig into the Ca$hCube and the cube into the wall socket.  It features a removable, remote mount capable,  LED wattage display (4 digit). Place the LED wattage display at a convenient spot.
2) Tune your rig to the optimum efficiency.
3) Configure the Ca$hCube via a couple buttons on the wattage display to setup a wattage window with transient tolerance (I figure on a transient tolerance of 60 seconds).
  Perhaps +/- 50W, or some value appropriate for the GPUs in the rig.
4) Enable the wattage window reset capability.

Now if the rig steps out of the power draw window for more than 60 seconds the Ca$hCube will power down the rig for 15 seconds and then power it back up.
The Ca$hCube will allow for 5 mins for the rebooted rig to stabilize and then assess the wattage window again.
If this cycle occurs 3 times inside a 30 minute window the Ca$hCube will shutdown the rig as unstable or faulted in some way and beep every 30 secs with a continually flashing fault LED.
After 4 hours of a powered down faulted condition the Ca$hCube will reboot the system and start the process again to mitigate any loss of internet or mining pool access.

As a bonus, the Ca$hCube can monitor the KWh used with a manual reset capability.

Any thoughts on this are welcome.

I am looking at crowdfunding.
Thanks
Ancel

Same issue here, playing card roulette right now. It seems to only happen when one of my cards is in, what I have done so far:
1. Removed all overclocks
2. Watt use is at 110 for 1070ti's, 120 for 1070, and 200 for 1080ti's (note: all hash rates drop, the 1080ti's in particular hit the 500's)
3. Swapped entire riser on suspect gpu
4. Swapped pci ports, tested pci port with alternative gpu
5. Looked at wattage use of cards when they drop, cards all drop power down well below my set wattage. So the power drop I think is the cause of  less hash, what's causing the power drop I am unsure of.

Smos
dtsm 0.5.6 (trying 5.7 now)
10 cards currently (have had various amounts between 9-13)
h110 pro btc

EDIT: So far so good on new version, but judging by change log this is just luck right now.

If two miners are charging a 2% devfee but one of them is faster and just as stable than the other is it not fair to say the slower miner's devfee is too high? That doesn't mean the devfee for the slower miner should be 0% (unless it really sucks), just that it either needs to reflect its second place position or else improve.

How do you guys monitor your rigs?

I would appreciate an advice as I'm building 3 rigs these days.

Thanks.

With EWBF, I was getting ~790-805 Sol/s with my 3 1080 Ti's and  ~555-570 Sol/s with my 1080.

With DSTM's, and without touching anything, I am getting a solid average of 822-825 Sol/s & 586 Sol/s, respectively.

Well done, thanks. And to all those complaining about the dev fee, don't download it. If you want something for free, go find a different, slower miner. If you want improvements to this miner, then support the developer.

Certainly! To clarify, I'm running on Ubuntu Linux. These are the commands I'm running to OC all the cards:


You're probably aware, but from what I understand, the overclocking uses a different numbering scheme on Windows (half of what Linux uses?) as well as power levels are %-based on Windows, but watt-based on Linux. Hope this helps!

Edit: adding the date/time is via an option: `zm --time `

Yeah, I'm getting about 305 Sols/s on each of my GTX 1060 3GB - Asus Dual Fan OC Edition (White). I'm not pushing the core/mem clocks too hard, either: 1950/4150 (2075 actual?) reported by MSI AB.

0.5.7 seems to be stable - running non-stop for 5+ days now - and with a very low rejected share rate. The devfee is a little high given the relative performance boost over the competition, but at least it works.