[OS] nvOC easy-to-use Linux Nvidia Mining

[DJ ACK]

Is anyone having issues with internal network DoS?  I have re-imaged my entire farm twice and somehow an attacker is getting in.  I am not sure if my IP addy was stolen from one of the BTG mining pools or if there are unpatched security vulnerabilities within the 1.3/1.4 beta builds.   A couple other miners running the same build are not having this problem.  My farm is isolated to a dedicated router and the DoS only happens on the farm. I can run about 10 hours or less and then the attack hits.  I have swapped modems, verified firewall configs on the router and the OS.  I have wiresharked at the gateway and was not able to capture anything that stood out.  Looking at the PacketStorm website I see a continuous flow of Linux vulnerabilities published every day.  How often are security patches pushed for the latest Ubuntu build?   I know that DDoS was the main reason for the exchanges to go down yesterday, but that attack vector was different.  

My test bench rig running the exact same nvOC build on a separate network is not having this issue at all.

[1714494463]

1714494463

[1714494463]

1714494463

[1714494463]

1714494463

[leenoox]

Is anyone having issues with internal network DoS?  I have re-imaged my entire farm twice and somehow an attacker is getting in.  I am not sure if my IP addy was stolen from one of the BTG mining pools or if there are unpatched security vulnerabilities within the 1.3/1.4 beta builds.   A couple other miners running the same build are not having this problem.  My farm is isolated to a dedicated router and the DoS only happens on the farm. I can run about 10 hours or less and then the attack hits.  I have swapped modems, verified firewall configs on the router and the OS.  I have wiresharked at the gateway and was not able to capture anything that stood out.  Looking at the PacketStorm website I see a continuous flow of Linux vulnerabilities published every day.  How often are security patches pushed for the latest Ubuntu build?   I know that DDoS was the main reason for the exchanges to go down yesterday, but that attack vector was different.  

My test bench rig running the exact same nvOC build on a separate network is not having this issue at all.

Have you manually applied ubuntu updates?
Have you changed the default password in nvOC?
Is someone running DDoS against your IP or the DDoS is initiated from your rigs against someone else?

[DangerD]

Can somebody please compile ccminer2.2.2 ?
( https://github.com/tpruvot/ccminer )
I need compiled binary... Can't do it because i don't have free space on flash stick...

I compiled it a few weeks back and put it here:

http://www.cstone.net/~stu/nvOC/miners/

Thanks.

Tried to run timetravel (BTX) and got "Illegal instruction" error

Code:

ccminer -a timetravel -o stratum+tcp://btx.suprnova.cc:3629 -u DangerD.Miner1 -p zzz

It was compiled from git of from downloaded release? (From git is needed because latest changes are not in latest release)

[DJ ACK]

Is anyone having issues with internal network DoS?  I have re-imaged my entire farm twice and somehow an attacker is getting in.  I am not sure if my IP addy was stolen from one of the BTG mining pools or if there are unpatched security vulnerabilities within the 1.3/1.4 beta builds.   A couple other miners running the same build are not having this problem.  My farm is isolated to a dedicated router and the DoS only happens on the farm. I can run about 10 hours or less and then the attack hits.  I have swapped modems, verified firewall configs on the router and the OS.  I have wiresharked at the gateway and was not able to capture anything that stood out.  Looking at the PacketStorm website I see a continuous flow of Linux vulnerabilities published every day.  How often are security patches pushed for the latest Ubuntu build?   I know that DDoS was the main reason for the exchanges to go down yesterday, but that attack vector was different.  

My test bench rig running the exact same nvOC build on a separate network is not having this issue at all.

Have you manually applied ubuntu updates?
Have you changed the default password in nvOC?
Is someone running DDoS against your IP or the DDoS is initiated from your rigs against someone else?

I have verified the integrity of the latest nvOC image, changed the default password, enabled UFW and only allowed port 22.  ISP has no indications of an external attack or an attack originating from me.  I have not applied any Ubuntu updates since the release of 19-1.4 beta.  I have a feeling that is the ultimate cause for my issue is that someone is taking advantage of an exploit that I haven't patched yet.  I have re-imaged twice now and it keeps occurring.  My router firewall logs show "WANATTACK" and IPV4 and IPV6 drops.  

[poisonxa]

dj ack if you want faster troubleshotting i suggest going to our discord channel for latest news updates and troubleshooting that goes for everyone.
The link for the discord channel is on the first page of this post Thanks and happy mining guys!

[nikauforest]

I started using this software for the first time yesterday. ( I love it ! Great work and I will make some donations)

Issue I came across with the H81 BTC Pro Motherboard 1st use of nvOC
(message from bootup was preventing os from starting)


1) I was using ssh with Remote login. 1 card worked fine. So I am thinking wow this is awesome.
2) I added the second card tried different risers and no go.
3) I found the problem when I hooked up a monitor to the first card and rebooted.(used "LOCAL") I have an H81 BTC Pro 2 motherboard that I got cheap. When I booted up with 2 cards There was a message saying when using multiple cards plug in the 4 pin connectors from the power supply to the mother board. Even though I had done this the warning still came up. So there was an option to hit "N" to not see this message again. It was seeing this message and not continuing to boot up nvOC 19_1.4. when 2 cards were connected.

I think I am good now to use putty to ssh and change the 1bash, when I add and test more cards.

Anyways for what it is worth that was my problem which was easily solved but not apparent by starting off with remote login.

[HyPyk]

Hi there

small problem - my miner takes long time to start and whatchdog restart the process since it is not started within expected time. How and where to increase that time?

thanks

[poisonxa]

Hi there

small problem - my miner takes long time to start and whatchdog restart the process since it is not started within expected time. How and where to increase that time?

thanks

go to the first post and come see us at the discord chat channel we will troubleshoot the problems for you.

[moofone]

Hi Stubo,

If you move a cards, that's a conscious effort and I would expect in that case you have to track that by updating 1bash. In this scenario you are changing only two things, so that seems reasonable to me

If we keep using the existing way, potentially all the cards have been re-indexed by taking one out

In the scenario where one fails, it is the same problem, they may all be reindexed if its the first card. At least using a per-bus-id method, you have nothing at all to do in this case as its still correct.

Another option would be overclock per card UUID, but I think that overcomplicates things. But that may work by generating a map between UUID and bus-id once you get things setup the way you want, run a command to build that map then it doesn't matter where you move cards around - it will track them. Add a new card? re-run the map building script... but again kind of overcomplicated. I think by bus-id is best and the most logical.

Completely disagree. This is dangerous way to overclock and could lead to catastrophic failure of your rig if a card dies on its own.. and they do.

Its discussed on the nvidia dev form with some python code that could be adopted to nvOC if anyone is interested:

https://devtalk.nvidia.com/default/topic/769851/multi-nvidia-gpus-and-xorg-conf-how-to-account-for-pci-bus-busid-change-/

Hi Guys,

I discovered a serious and potentially dangerous flaw in the way nvOC handles overclocking and would like to make a suggestion for an improvement.

We really need overclocking tied to the specific pcie slot (bus id) not an index that changes every time your hardware changes.

For example, if you have a gtx1080ti in slot 2, and a gtx1060 in slot 3, and your 1080ti goes offline for some reason or you remove it, the 1080ti overclock is now applied to what it thinks is the next card in the dumb index, and applies it to your gtx1060 potentially going POOF.

We need to apply overclocking to BUS ID:
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1070    Off  | 00000000:02:00.0 Off |                  N/A |
| 70%   56C    P2   152W / 151W |    652MiB /  8112MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX 106...  Off  | 00000000:04:00.0 Off |                  N/A |
| 70%   61C    P2   120W / 120W |    592MiB /  6072MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+
|   2  GeForce GTX 1070    Off  | 00000000:05:00.0 Off |                  N/A |
| 70%   52C    P2   118W / 120W |    614MiB /  8113MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+

Nothing to fix at all oO ...

You modified your RIG, you have to modify setting ...

How is OC by slot going to fix the scenario where a person just moves cards around in a rig as opposed to just removing one? Both scenarios are hardware changes and common sense dictates that the user be aware of this potential because they went down the path of path of individual OC in the first place. It is not like they went there by mistake, right?

[Stubo]

Can somebody please compile ccminer2.2.2 ?
( https://github.com/tpruvot/ccminer )
I need compiled binary... Can't do it because i don't have free space on flash stick...

I compiled it a few weeks back and put it here:

http://www.cstone.net/~stu/nvOC/miners/

Thanks.

Tried to run timetravel (BTX) and got "Illegal instruction" error

Code:

ccminer -a timetravel -o stratum+tcp://btx.suprnova.cc:3629 -u DangerD.Miner1 -p zzz

It was compiled from git of from downloaded release? (From git is needed because latest changes are not in latest release)

Yes, the source (included in the zip) was downloaded from git just a couple of days after the release. I never tried it with BTX because I was trying it with MONA and it worked fine. If it is not working for your rig, I would suggest that you just recompile it.

[alexander1234]

Thank you for the great product!

Could you please assist with this trouble? I run v0019-1.3 with no issues, 10x 1080, all cards stably giving 550 sol on zec with zm. Then I've installed fresh v0019-1.4, applied my OC. Now hashrate and POWER consumption bounces on several of 1080s and overal hashrate decreased significantly. I've rechecked the configs, tried to turn off temp control, played with power mizer setting. But no result. Is it some known issue? Maybe related to driver update from 384 to 387? Could you please point me to the resolution if there is one? Thank you very much!

[ruepa]

If somebody could help,
I've build a mining rig with 3 nvidia 1070 ti AERO and used a Asus Prime Z270-p motherboard.
I've already enabled above 4G decoding and reset the security keys.

Inicially the system was booting fine, and i've set up the cards with CC 175 and a MC 1200, power limit of 115W and fan 80. On the 1bash
I've opened the miner and it was mining around 480 sol's per card, with a temperature around 70 oC, i've letf it running for about 5hrs before turning off the monitor and going to work, at the time temperature were stabe at 68oC with ocasional spikes to 70oC.

Acording to the pool i was connected the machine was running for 12hrs and just before turning off there was a spike in the sol's. When i got home the RIG was on the bios. Now when i boot into linux if i leave the terminal open it crashes and reboots. If i close the terminal i can use the system, i can go into youtube and watch movies in 1080p, see the gpu's detected on the nvidia app.
If i try to run the mining terminal it crashes strait away, with terminal without running any command it also crashes.

First of all, do you think it was possible to have burned the gpu's with those settings with around a total of 20hrs of work?

What can be causing this? I've already tried changing risers, and formatting the USB and running it again.

[Reinars]

Can we get BTG built into next version ? I would like to try that out

[MentalNomad]

Completely disagree. This is dangerous way to overclock and could lead to catastrophic failure of your rig if a card dies on its own.. and they do.

Its discussed on the nvidia dev form with some python code that could be adopted to nvOC if anyone is interested:

https://devtalk.nvidia.com/default/topic/769851/multi-nvidia-gpus-and-xorg-conf-how-to-account-for-pci-bus-busid-change-/

Hi Guys,

I discovered a serious and potentially dangerous flaw in the way nvOC handles overclocking and would like to make a suggestion for an improvement.

We really need overclocking tied to the specific pcie slot (bus id) not an index that changes every time your hardware changes.

For example, if you have a gtx1080ti in slot 2, and a gtx1060 in slot 3, and your 1080ti goes offline for some reason or you remove it, the 1080ti overclock is now applied to what it thinks is the next card in the dumb index, and applies it to your gtx1060 potentially going POOF.

We need to apply overclocking to BUS ID:
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1070    Off  | 00000000:02:00.0 Off |                  N/A |
| 70%   56C    P2   152W / 151W |    652MiB /  8112MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX 106...  Off  | 00000000:04:00.0 Off |                  N/A |
| 70%   61C    P2   120W / 120W |    592MiB /  6072MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+
|   2  GeForce GTX 1070    Off  | 00000000:05:00.0 Off |                  N/A |
| 70%   52C    P2   118W / 120W |    614MiB /  8113MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+

Nothing to fix at all oO ...

You modified your RIG, you have to modify setting ...

How is OC by slot going to fix the scenario where a person just moves cards around in a rig as opposed to just removing one? Both scenarios are hardware changes and common sense dictates that the user be aware of this potential because they went down the path of path of individual OC in the first place. It is not like they went there by mistake, right?

I think the concern is about when no changes are intentionally made.

Example: I have 12 cards in a rig. One card dies completely, mining stops, WDOG restarts the rig...

Rig comes back up, but the dead card is not recognized at all. GPU numbering is now different. Now some OC settings are wrong, may be applying power/fans/OC inappropriately, perhaps making the rig unstable or putting more hardware at risk....

[joshuajones02]

Hello, I've been trying to search in this thread but unable to find a similar issue. Not sure if its related but when I add additional GPU or remove one, my machine will boot up to a blank screen with the _ symbol, when I try to reboot after it'll say cleared or clear with a number of files but will not boot into the Ubuntu GUI, I can access the terminals but that doesnt help. I type in startx in the terminal but it just errors.. I should have taken photos of the screen, I can probably replicate the error if needed.

I have some extra cards I am using for a new build that I wanted to test out and had some extra slots to run them on and won't receive all the parts for a few more days and I can't play with them without taking an entire system offline and having to clone the hard drive to get it to run again.

[Temporel]

those mining Neoscrypt with GTX-1070, what miner are you using with nvOC ?

TIA

[Stubo]

Hello, I've been trying to search in this thread but unable to find a similar issue. Not sure if its related but when I add additional GPU or remove one, my machine will boot up to a blank screen with the _ symbol, when I try to reboot after it'll say cleared or clear with a number of files but will not boot into the Ubuntu GUI, I can access the terminals but that doesnt help. I type in startx in the terminal but it just errors.. I should have taken photos of the screen, I can probably replicate the error if needed.

I have some extra cards I am using for a new build that I wanted to test out and had some extra slots to run them on and won't receive all the parts for a few more days and I can't play with them without taking an entire system offline and having to clone the hard drive to get it to run again.

Have you tried to access it remotely using SSH? I suspect that GPU0 is changing to a different GPU and that is the not the one you have your monitor connected to. So, all that you see is a blank screen. I have this same issue and I don't know if there is a way to force a particular GPU to be GPU0. Since I run headless anyway, it is really not much of a problem.

Hope this helps.

[Stubo]

Completely disagree. This is dangerous way to overclock and could lead to catastrophic failure of your rig if a card dies on its own.. and they do.

Its discussed on the nvidia dev form with some python code that could be adopted to nvOC if anyone is interested:

https://devtalk.nvidia.com/default/topic/769851/multi-nvidia-gpus-and-xorg-conf-how-to-account-for-pci-bus-busid-change-/

Hi Guys,

I discovered a serious and potentially dangerous flaw in the way nvOC handles overclocking and would like to make a suggestion for an improvement.

We really need overclocking tied to the specific pcie slot (bus id) not an index that changes every time your hardware changes.

For example, if you have a gtx1080ti in slot 2, and a gtx1060 in slot 3, and your 1080ti goes offline for some reason or you remove it, the 1080ti overclock is now applied to what it thinks is the next card in the dumb index, and applies it to your gtx1060 potentially going POOF.

We need to apply overclocking to BUS ID:
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1070    Off  | 00000000:02:00.0 Off |                  N/A |
| 70%   56C    P2   152W / 151W |    652MiB /  8112MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX 106...  Off  | 00000000:04:00.0 Off |                  N/A |
| 70%   61C    P2   120W / 120W |    592MiB /  6072MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+
|   2  GeForce GTX 1070    Off  | 00000000:05:00.0 Off |                  N/A |
| 70%   52C    P2   118W / 120W |    614MiB /  8113MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+

Nothing to fix at all oO ...

You modified your RIG, you have to modify setting ...

How is OC by slot going to fix the scenario where a person just moves cards around in a rig as opposed to just removing one? Both scenarios are hardware changes and common sense dictates that the user be aware of this potential because they went down the path of path of individual OC in the first place. It is not like they went there by mistake, right?

I think the concern is about when no changes are intentionally made.

Example: I have 12 cards in a rig. One card dies completely, mining stops, WDOG restarts the rig...

Rig comes back up, but the dead card is not recognized at all. GPU numbering is now different. Now some OC settings are wrong, may be applying power/fans/OC inappropriately, perhaps making the rig unstable or putting more hardware at risk....

Well, I don't think you will put the HW at risk but it could certainly screw up some OC settings. My understanding is that Nvidia builds their GPU's with several different fail-safe mechanisms to prevent this as do the vendors who build and warranty them. Consider the scenario where we attempt to apply a PL that is too high. Here is an old 970 on my test rig whose limit is 220 watts and I try to push it to 225:

Code:

m1@Testy:~$ # Overpower a GPU
m1@Testy:~$ nvidia-smi --query-gpu=name,pstate,temperature.gpu,fan.speed,utilization.gpu,power.draw,power.limit --format=csv
name, pstate, temperature.gpu, fan.speed [%], utilization.gpu [%], power.draw [W], power.limit [W]
GeForce GTX 970, P2, 49, 50 %, 100 %, 114.22 W, 115.00 W
m1@Testy:~$ # Find max power card can handle
m1@Testy:~$ nvidia-smi -a |grep "Max Power"
        Max Power Limit             : 220.00 W
m1@Testy:~$ # Set GPU Power above this
m1@Testy:~$ sudo nvidia-smi -pl 225
Provided power limit 225.00 W is not a valid power limit which should be between 100.00 W and 220.00 W for GPU 00000000:01:00.0
Terminating early due to previous errors.

Has anybody seen a HW failure from this or is this just theoretical?

[poisonxa]

its not going to happen the gpu is designed to only pull the power it needs and nothing more so theres no way to force feeding it more power because it gets to the point that it just wont accept it now giving it alot of power and letting it overheat is autokill "keep in mind power doesnt kill hw heat does" now for overclocking you cant brick a card now adays for over overclocking it because it will just crash the drivers and internal failsafes will just turn the card off or crash it if the clocks are too high.

[infowire]

Still having the last card at 26 mhs, no matter what i do it's always the last card. Evga 1070. All the same cards and they do 31 MHs except the last one.