Topic: [ANN] dstm's ZCash / Equihash Nvidia Miner v0.6.2 (Linux / Windows) - page 155. (Read 224961 times)
October 05, 2017, 07:17:34 PM
I can confirm that the CPU load is very low on a 12 gtx1060 rig with Intel G4560.
October 05, 2017, 07:06:01 PM
Nice work! But i have some problem with CPU perfomance.
CPU - Intel G3900 / RAM - 4G / GPU - 10 1080ti
left EWBF Miner (10 card) - right dstm (8 card)
https://snag.gy/TRXPJy.jpg
If I run the miner for 10 cards, the performance drops.
Miner version 0.5
CPU - Intel G3900 / RAM - 4G / GPU - 10 1080ti
left EWBF Miner (10 card) - right dstm (8 card)
https://snag.gy/TRXPJy.jpg
If I run the miner for 10 cards, the performance drops.
Miner version 0.5
Thx for reporting. Seems like I'm heavier on the CPU side. This is partially because of the strict separation of the GPUs and the way I'm preparing work for the GPUs I guess, I don't want to give up both since they have benefits.
This is what I'm getting on a 10GPU system (6*1070 + 4*1080Ti) with an i3-7300T (a 35W CPU).
Code:
1 [|||||||||| 18.2%] Tasks: 112, 279 thr; 2 running
2 [|||||||||| 16.6%] Load average: 0.80 0.57 0.27
3 [|||||||||||||||||||||||||||| 51.0%] Uptime: 00:53:42
4 [||||||||| 15.3%]
CPU performance isn't currently an issue for most users as you can see how an i3-7300T performs, so I'm not focusing on it now, I'll do more CPU optimization work after I'm done with the current requests. Sry for the delay.
October 05, 2017, 05:24:34 PM
Nice work! But i have some problem with CPU perfomance.
CPU - Intel G3900 / RAM - 4G / GPU - 10 1080ti
left EWBF Miner (10 card) - right dstm (8 card)
https://snag.gy/TRXPJy.jpg
If I run the miner for 10 cards, the performance drops.
Miner version 0.5
CPU - Intel G3900 / RAM - 4G / GPU - 10 1080ti
left EWBF Miner (10 card) - right dstm (8 card)
https://snag.gy/TRXPJy.jpg
If I run the miner for 10 cards, the performance drops.
Miner version 0.5
October 05, 2017, 11:11:22 AM
For me your miner is way more stable than ewfb's. While ewfb's simply hangs in 24-48hrs period on Windows and even sooner under Ubuntu, yours working stable. If only I could figure out how to overclock under Linux on a headless rig...
EDIT: However, It disconnected today twice. Once it just said server disconnected (i'm using nanopool) and failed to restore the connection, despite internet was working flawelessly on all other devices in a household. Restart of the miner itself immediately fixed the issue. And the second time it started throwing some connection errors, and again everything else worked like a charm. Restart fixed it as well.
EDIT: However, It disconnected today twice. Once it just said server disconnected (i'm using nanopool) and failed to restore the connection, despite internet was working flawelessly on all other devices in a household. Restart of the miner itself immediately fixed the issue. And the second time it started throwing some connection errors, and again everything else worked like a charm. Restart fixed it as well.
Thx for reporting. Working internet doesn't mean the server is reachable, the server itself might have issues - however I've fixed a bug in my reconnection procedure which was introduced by a change of error codes in one of my functions. I'm currently testing 0.5.1, if it passes tests I'll upload it today.
If it starts throwing connections errors pls post them here since I'm unable to fix them otherwise. I'm pretty verbose in my networking code currently some of the messages can be safely ignored, they are there to make debugging easier.
October 05, 2017, 09:51:14 AM
For me your miner is way more stable than ewfb's. While ewfb's simply hangs in 24-48hrs period on Windows and even sooner under Ubuntu, yours working stable. If only I could figure out how to overclock under Linux on a headless rig...
I can help you with that......
Create a new X11/Xorg config using
Code:
nvidia-xconfig -o xorg.conf --enable-all-gpus --cool-bits=28 --allow-empty-initial-configuration
Move/copy the config to /etc/X11
Code:
cp ./xorg.conf /etc/X11
Kill all your Xorg/X11 processes (or reboot)
Use the following sequence to OC your cards
Code:
Xorg :0 &
sleep 5
export DISPLAY=:0
/usr/bin/nvidia-settings -a GPUPowerMizerMode=1
/usr/bin/nvidia-settings -a GPUFanControlState=1
/usr/bin/nvidia-settings -a GPUTargetFanSpeed=100
/usr/bin/nvidia-settings -a GPUGraphicsClockOffset[3]=10
/usr/bin/nvidia-settings -a GPUMemoryTransferRateOffset[3]=100
October 05, 2017, 03:28:07 AM
For me your miner is way more stable than ewfb's. While ewfb's simply hangs in 24-48hrs period on Windows and even sooner under Ubuntu, yours working stable. If only I could figure out how to overclock under Linux on a headless rig...
EDIT: However, It disconnected today twice. Once it just said server disconnected (i'm using nanopool) and failed to restore the connection, despite internet was working flawelessly on all other devices in a household. Restart of the miner itself immediately fixed the issue. And the second time it started throwing some connection errors, and again everything else worked like a charm. Restart fixed it as well.
EDIT: However, It disconnected today twice. Once it just said server disconnected (i'm using nanopool) and failed to restore the connection, despite internet was working flawelessly on all other devices in a household. Restart of the miner itself immediately fixed the issue. And the second time it started throwing some connection errors, and again everything else worked like a charm. Restart fixed it as well.
October 04, 2017, 06:19:11 PM
The GPUs are OC'd to where Claymore and EWBF will run for days. I restarted the zm miner and it's still mining after 4 hours so I'll let it run and see what it does.
This doesn't mean it's stable, it's still overclocked. It could crash simply because I'm using different instructions - different compiler - or simply because of different ordering of instructions.
yeah that makes sense. Right now with it overclocked it's running about the same as EWBF, but if I pull the overclocks out it will be slower no doubt. I want to let it run for as long as it will then I can go back and see about pulling the OC's out.
October 04, 2017, 03:23:18 PM
The GPUs are OC'd to where Claymore and EWBF will run for days. I restarted the zm miner and it's still mining after 4 hours so I'll let it run and see what it does.
This doesn't mean it's stable, it's still overclocked. It could crash simply because I'm using different instructions - different compiler - or simply because of different ordering of instructions.
Quote
Also displaying time on each line would be helpful so I can see what time it failed--or maybe just on the total line ===. I should be logging as that probably has the time...
This was requested several times - so yes there will be timestamps.
October 04, 2017, 02:37:55 PM
The GPUs are OC'd to where Claymore and EWBF will run for days. I restarted the zm miner and it's still mining after 4 hours so I'll let it run and see what it does.
Also displaying time on each line would be helpful so I can see what time it failed--or maybe just on the total line ===. I should be logging as that probably has the time...
Also displaying time on each line would be helpful so I can see what time it failed--or maybe just on the total line ===. I should be logging as that probably has the time...
October 04, 2017, 11:47:47 AM
Fired up zm on Ubuminer doing Zen on Suprnova when after about 20 minutes I had the miner fail with:
gpu_id 1 1 0x1072dcb0200 the launch timed out and was terminated
cudaMemcpy 1 failed
gpu_id 1 1 0x1072dcb0200 the launch timed out and was terminated
cudaMemcpy 1 failed
Thx, that's the 3rd time I get this error report. Are your GPUs overclocked? If yes, might you pls try without overclocking? If you have time for test, I'll compile a version with more debugging output to check what's causing this.
October 04, 2017, 11:33:07 AM
Fired up zm on Ubuminer doing Zen on Suprnova when after about 20 minutes I had the miner fail with:
gpu_id 1 1 0x1072dcb0200 the launch timed out and was terminated
cudaMemcpy 1 failed
gpu_id 1 1 0x1072dcb0200 the launch timed out and was terminated
cudaMemcpy 1 failed
October 04, 2017, 07:41:51 AM
Since you've pointed out that you're getting TCP errors on your network before zm reconnects (TCP Retransmissions in particualar): I'm not dealing with the TCP/IP layer in zm, that's the responsibility of the kernel. It seems that your router/nat has troubles to keep multiple connections open, it just closes them after some time.
I can monitor the network, but the funny thing is the network only does this with your miner, it does not happen with any other program or configuration. and it happens only on 1 computer. if what you suggest were true, it would have several disconnections for all computers at the same time. But it doesn't. Everything points to be something in your code triggering some weird configuration on the latest ubuntu update (since I updated both ubuntu and your miner at the same time).
I'll take a look at the NAT/routing tables in the kernel and see if I can find out what is going on.
Sigh.
That's what I was trying to say
ZM uses multiple constantly opened connection, it seems that your router/nat has troubles to keep multiple connections constantly open. That's most likely why you're not seeing this behavior with other programs which are using only one connection.Edit:
Quote
it would have several disconnections for all computers at the same time
Not necessarily. Your router might drop the connections to a particular host only.
Quote
and it happens only on 1 computer.
This might be very helpful to debug the issue. What's different on this PC? Does it have more GPUs such that it opens more connections? Are the GPUs faster/slower such that they produce more/less shares/network traffic? October 04, 2017, 07:14:00 AM
Seems like quite a few pools are having trouble recently so how about being to set a backup pool?
Right, pools are very unreliable currently. Some of them can't event handle an 10% increased share rate.
A backup pool seems like a good idea however it has also issues.
Let's assume I'll simply alternate between the primary and the backup pool on every disconnect.
You might switch to the backup pool even if your primary pool had an issue only once.
You might switch to the backup pool on temporary local network issues.
You might start alternating between the pools.
I have to think some more time how a good backup pool implementation might look like. If you have ideas, suggestions are welcome.
October 04, 2017, 07:10:49 AM
Since you've pointed out that you're getting TCP errors on your network before zm reconnects (TCP Retransmissions in particualar): I'm not dealing with the TCP/IP layer in zm, that's the responsibility of the kernel. It seems that your router/nat has troubles to keep multiple connections open, it just closes them after some time.
I can monitor the network, but the funny thing is the network only does this with your miner, it does not happen with any other program or configuration. and it happens only on 1 computer. if what you suggest were true, it would have several disconnections for all computers at the same time. But it doesn't. Everything points to be something in your code triggering some weird configuration on the latest ubuntu update (since I updated both ubuntu and your miner at the same time).
I'll take a look at the NAT/routing tables in the kernel and see if I can find out what is going on.
Sigh.
October 04, 2017, 06:22:02 AM
Seems like quite a few pools are having trouble recently so how about being to set a backup pool?
October 04, 2017, 05:50:05 AM
Have you tried the 0.5_nat version I pm to you? Does it have the same issues?
I have been running it for 1h30m and so far it has not disconnected. not even once. I'll leave them running and report back later.
edit: added a period to make it clearer.
edit2: it happened again
it took longer, but same effect.
Since you've pointed out that you're getting TCP errors on your network before zm reconnects (TCP Retransmissions in particualar): I'm not dealing with the TCP/IP layer in zm, that's the responsibility of the kernel. It seems that your router/nat has troubles to keep multiple connections open, it just closes them after some time.
October 03, 2017, 09:36:02 PM
Have you tried the 0.5_nat version I pm to you? Does it have the same issues?
I have been running it for 1h30m and so far it has not disconnected. not even once. I'll leave them running and report back later.
edit: added a period to make it clearer.
edit2: it happened again
it took longer, but same effect.https://image.prntscr.com/image/isZkxQR2Q5eAaowYdayVCQ.png
October 03, 2017, 08:41:53 PM
I'm testing zm on Suprnova right now. Suprnova will sometimes show my Efficiency is less than 100%, but I don't see the miner showing rejected shares like Claymore or EWBF.
Right now zm appears to be just as fast, if not faster than EWBF's miner.
Right now zm appears to be just as fast, if not faster than EWBF's miner.
Right, I'm not showing them on the ui currently - they will be shown in the next version on the ui and their amount will be accessible via json-rpc.
October 03, 2017, 08:20:45 PM
I'm testing zm on Suprnova right now. Suprnova will sometimes show my Efficiency is less than 100%, but I don't see the miner showing rejected shares like Claymore or EWBF.
Right now zm appears to be just as fast, if not faster than EWBF's miner.
Right now zm appears to be just as fast, if not faster than EWBF's miner.
October 03, 2017, 08:03:45 PM
I think an intensity option would be useful for people who want their desktop to remain responsive while mining for example.
Something like an option to throttle the amount of work that is sent to the GPU? If I understand you correctly.
Does it even make sense to use your desktop while mining? Not sure if I understand the use case for this option.
Some people mine on their main PC while doing other things, that's useful, if not too troublesome to implement I highly appreciate if you can add intensity options.
I see, will do.
So you must be able to set intensity per GPU - since you might have multiple GPUs on your main PC on you want to throttle only the GPU that's used for rendering, right?
In case someone has a video editing desktop that would be sweet even though this can be bypassed by creating multiple batchfiles to select with which GPU you want to mine.
Jump to: