 Show Posts
|
|
Pages: [1]
|
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. |
|
|
|
|
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.
|
|
|
|
|
Any idea why all rigs crashed last night. v0018 and v0019 rigs all died and won't boot. v0018 rigs hang trying to perform cleaning functions. v0019 rigs ask for a password. v19-1.3 rigs are all running fine. Rigs are in three completely different geographic locations.
|
|
|
|
Witnessed an odd issue with v0018 today. All 8 of my 1050Tis only report ~13 MH/s. Thought it was risers and swapped a couple out, no change. Re-imaged the SSD and upon initial boot up, everything was fine, reporting 14.7 MH/s. As soon as I rebooted it dropped the hash back down to 13 MH/s. Swapped out cards and booted with just a single card same result. Re-imaged again, same result. Any idea what would cause this?
I am running ASUS Z270 Prime-A boards with Gigabyte 1050Ti Boost Clock 1506 cards. I don't think it is an ETH difficulty issue as my other rigs have the same configuration and I am not seeing the same issue. My power is set at 60watts, temp settings at 60, my fan setting 50, core OC is 0 and mem OC is 1450. I changed around power and mem settings, but no difference.
Could one of the modules be adjusting this to match one of the above variables? My cards never get hot enough for the fan to go above 50.
Autotemp could be lowering the powerlimit; but only after your fans go to max. If they don't go above 50% then that is unlikely. The current powerlimit is displayed by the autotemp readout, so you can verify if it has changed when this is the case. If it has been; I would raise your temp target to 70. Watchdog only restarts 1bash or the rig; it shouldn't make an OC changes. What kind of risers are you using? Are you powering them direct with Pcie 6pin? If not this may be the problem. Also you can probably get the same MH/s with the minimum powerlimit and -100 or -200 cc. Well amazing.. that was it.. bumped the temp target up to 70, dropped the cc down to -200 and I found my missing hash. Now to tweak my other rigs. Looks like you help me find another 65 MH/s for my entire setup. Thank you very much. That one rig has mixed molex and 6 pin type risers. I will change out the molex when my new stock of risers comes in. |
|
|
|
|
Not really v0018 related. However, interesting to learn. Received a batch of Gigabyte 1050Ti 1506 Boost Clock edition cards from Amazon last week. Installed them in a rig and they hashed at an insanely low rate (single digits). I swapped out risers, swapped cards between rigs, and they just would not hash. You can tell these cards have issues because the DAG file % complete lags way behind the other cards during the DAG file build. Running the card as a stand alone the DAG file builds quickly and the card hashes fine. The minute you add it with another card the hash rate tanks. Even with the same manufactured batch (serial number off by a couple digits). After comparing the serial number to the 48 other Gigabyte 1050Ti cards I have, I noticed that the serial number is a very low/early edition number compared to all the rest of my cards. My hunch is that these cards were sitting in a warehouse corner for years and they were a failed production batch with crap memory. Sent them back to Amazon as defective.
Anyone else had crap card inventory show up since May/June time frame?
|
|
|
|
|
Witnessed an odd issue with v0018 today. All 8 of my 1050Tis only report ~13 MH/s. Thought it was risers and swapped a couple out, no change. Re-imaged the SSD and upon initial boot up, everything was fine, reporting 14.7 MH/s. As soon as I rebooted it dropped the hash back down to 13 MH/s. Swapped out cards and booted with just a single card same result. Re-imaged again, same result. Any idea what would cause this?
I am running ASUS Z270 Prime-A boards with Gigabyte 1050Ti Boost Clock 1506 cards. I don't think it is an ETH difficulty issue as my other rigs have the same configuration and I am not seeing the same issue. My power is set at 60watts, temp settings at 60, my fan setting 50, core OC is 0 and mem OC is 1450. I changed around power and mem settings, but no difference.
Could one of the modules be adjusting this to match one of the above variables? My cards never get hot enough for the fan to go above 50.
|
|
|
|
Love the v0018 release and all the functionality!
However, POWERLIMIT NIGHTMARES!
I have one major issue, I cannot lower the POWERLIMIT. I run 8 rigs of 1050Ti and 125W is just way to high. I have tried adjusting the base line and the individual POWERLIMIT settings and I am still seeing maximum power being utilized in NVIDIA-SMI and TEMP CONTROL. I thought maybe the TEMP CONTROL was trumping the setting, but I don't think that is the case (at least based on what my 46 year old brain and eye balls looking at the 1bash code understands). I thought maybe it was the correction in line 527, but that didn't change anything.
I tried "NO" for both WATCHDOG and TEMP CONTROL with POWERLIMIT set below MAX for the 1050Ti and I still see max power output.
I did notice during startup, of the three terminal screens that pop-up during startup that the second terminal session has the POWERLIMIT set correctly at 60. However, something happens after the third terminal screen initiates (miner starting) that pushes the POWER back to MAX.
I added another rig of 1050Tis tonight and I saw more unusual behavior from POWER settings again where GPU0 goes to 125W as the max power limit and the rest of the GPUs all complied with my setting of 65Watts. I have no idea what is causing this inconsistency in power limit settings.
I also noticed in the Guake terminal that the TEMP CONTROL module is displaying continuous notifications that 125W is not a valid power limit (even after changing the settings in the module to 60-65).
I normally run all my rigs at 60W, which keeps the current draw low enough to run 3 rigs of 8 GPUs on each 15 AMP circuit. Also, extremely efficient.
I am still hunting for what is causing the forced 125W power setting.
Try the new 1bash and additional files posted on the OP. Let me know if it doesn't solve this for you. [/quote] Fullzero, yes this solved all my POWERLIMIT problems. All 8 rigs up and hashing away. Thank you very much! |
|
|
|
|
Love the v0018 release and all the functionality!
However, POWERLIMIT NIGHTMARES!
I have one major issue, I cannot lower the POWERLIMIT. I run 8 rigs of 1050Ti and 125W is just way to high. I have tried adjusting the base line and the individual POWERLIMIT settings and I am still seeing maximum power being utilized in NVIDIA-SMI and TEMP CONTROL. I thought maybe the TEMP CONTROL was trumping the setting, but I don't think that is the case (at least based on what my 46 year old brain and eye balls looking at the 1bash code understands). I thought maybe it was the correction in line 527, but that didn't change anything.
I tried "NO" for both WATCHDOG and TEMP CONTROL with POWERLIMIT set below MAX for the 1050Ti and I still see max power output.
I did notice during startup, of the three terminal screens that pop-up during startup that the second terminal session has the POWERLIMIT set correctly at 60. However, something happens after the third terminal screen initiates (miner starting) that pushes the POWER back to MAX.
I added another rig of 1050Tis tonight and I saw more unusual behavior from POWER settings again where GPU0 goes to 125W as the max power limit and the rest of the GPUs all complied with my setting of 65Watts. I have no idea what is causing this inconsistency in power limit settings.
I also noticed in the Guake terminal that the TEMP CONTROL module is displaying continuous notifications that 125W is not a valid power limit (even after changing the settings in the module to 60-65).
I normally run all my rigs at 60W, which keeps the current draw low enough to run 3 rigs of 8 GPUs on each 15 AMP circuit. Also, extremely efficient.
I am still hunting for what is causing the forced 125W power setting.
|
|
|
|
I am running 5 of these boards and do not have any issues. This board appears to have the most PCI lane management features I have ever seen on a motherboard. Be sure your M.2 slots are configured for PCI and not SATA. Also, if you are using a SSD/HDD for nvOC, be sure you are not using a SATA slot that might be conflicting with the M.2 slot. There is a chart for this in the mobo manual. My 2 cents. |
|
|
|
First off thanks for all the work Fullzero!
I've been fighting with Win10 on my rig for a month. Can't get it to recognize any more than 3 of my 1070 cards, and one always is disabled with an error. So I've decided to dump Win10.
I've just got nvoc 0017 running with my old USB 2.0 stick on my ASUS Prime Z270-A with 6 Geforce GTX 1070s rig and I am not sure now how to get the mining started.
I guess I was under the impression that it would start automatically on boot but I must have missed something in the setup. It's just sitting there with the terminal screen open.
Also in the Nvidia X server settings it's also only recognizing 3 of the 1070 gpus. I'm hoping this is something that can be easily worked out as I'd hate to think that 3 of the 6 1070's I have only had for a month are bad.
Thanks in advance for any help.
If you had the same problem with windows only recognizing 3 out of 6 GPUs; this indicates there is most likely a hardware problem. Have you tried swapping your risers? How are you powering your risers? What kind of risers are you using? If you run with only 3x GPUs and it works: swap out the 3 working GPUs with the 3 that aren't being recognized and see if they work. Actually hardware wise I've already change motherboards thinking it was the MSI Z170A SLI Plus that I started out with. I sent it back to Amazon earlier this week and ordered the Asus. The risers are directly powered by the SATA cable from the PSU. These are the risers... https://www.amazon.com/Extender-Powered-Extension-Adapter-Card-Currency/dp/B072MFBYCM/ref=sr_1_10?s=electronics&ie=UTF8&qid=1499386958&sr=1-10&keywords=PCIe%2BPowered%2BRiser%2BAdapter%2BCard%2B-%2BUSB%2B3.0%2BPCIe%2B1x%2Bto%2B16x%2BExtender%2BCard%2B-%2B6-Pin%2BPCI-E%2Bto%2BSATA%2BPower%2BCable&th=1Yes I have swapped them around many time, but when I was on win10, haven't yet with nvoc as I just got it going tonight. All of them worked in that testing. Just a side note here.... I shut down the rig after I posted the first post and just powered it back a few mins ago. Getting this scrolling on the terminal now... bash: /media/m1/1263-A96E/oneBash: Permission denied dos2unix: /media/m1/1263-A96E/oneBash: No such file or directory dos2unix: Skipping /media/m1/1263-A96E/oneBash, not a regular file. I have to laugh at myself cause I've obviously dorked something up I guess. As fullzero mentioned the image or partioning on your USB stick may have issues. Depends on how you installed the image. I used Etcher in Ubuntu and had no problems (yes having Linux on another box saves you a lot of trouble). When I installed nvOC 17 on my SSD, I had to change the 2Unix file. By default the oneBash sits on the 9Gig partition. I copied over to the home directory where the 2unix file sits and just changed the 2Unix file pointing it to the new location. Problem solved. Swapping out my MSI Z170 Gaming M5 boards for the ASUS Z270 Prime-A boards solved a lot of instability problems that I thought were riser related. Additionally these boards are awesome for running 9 GPUs or more. I have 9 x 1050Tis (1506 Boost Clock versions) running solid on these boards (0 Core OC, 1550 Mem OC, power limit 65, 133 MH/s per rig). |
|
|
|
|
Good day! Does anyone know of a good way to identify which PCI Lane is assigned to each physical PCI slot. Scanning system logs, System Info, etc. it is easy to correlate which PCI lane, GPU #, GPU serial number, etc. fell off the bus. But is there a way to correlate PCI Lane to actual PCI slot? Short of me logging the GPU serial number as I add each card to the board, It would be nice if there was a one stop shop to display GPU PCI slot information.
I don't believe that they are assigned sequentially during system boot up because I have seen lane assignments go from 1, 2, 5, 6, 7, 8. It would really help in troubleshooting riser problems if physical slot assignment was easily found.
I have learned over the years that riser board version type really does not matter (even though I have seen several posts that claim v6 is better, v7 is better, C vs. S, etc.). It all depends on where each lot is manufactured and if they had any kind of quality assurance check prior to shipment. Heck I have an allotment of v1s from the BTC mining days that still work great. Some riser boards work fine if the card is not overclocked too high. But it is never the same across the board.
Whether the risers are purchased from eBay, Newegg, Amazon, Craig's List, etc., it all seems to be a crap shoot. And returning products across the ocean is real pain in the a$$. My recommendation is find one vendor that has not failed you and stick with them (regardless of the wait time)...and order EXTRAS! Does anyone know of a US, UK or Asia based reliable vendor?
Just some food for thought from an extremely happy nvOC user.
|
|
|
|
Does anyone know of a way to detect GPU memory vendor information in Linux? Similar to how GPU-Z can display the info in Winblows. I want to group my mining rig clusters based on GPU memory vendors. I think this will dramatically help in improving stability when tweaking each card in each rig.  |
|
|
|
My hats off to fullzero! Thank you for taking the time to put together and maintaining this amazing build. Back in the BTC days I was stuck with Win 7 and finally dived back in when ETH started it's journey to the moon. Win7 gave me plenty of instability issues, Win10 gave me low hash rates, Xubuntu gave me plenty of instability as well, specifically with GPUs falling off the bus. Additionally Xubuntu did not utilize the second CPU core, which made a Kaby Lake CPU run 15-20 degrees hotter. Under your build, the one Kaby Lake CPU I have runs nice and cool using both cores. nvOC gave me a completely worry free and easy to use solution. Again, I thank you! Here is my current setup 7 Rigs total OS Build: Yours! nvOc v0017 MSI Z170 Gaming M5 motherboards w/ May 2017 BIOS Celeron G3900 Skylake CPUs (except 1 Kaby Lake) 8GB of Corsair DDR4 Samsung EVO 750 SSD (overkill, but this was before I was on nvOC) 33 x Gigabyte 1050Ti (stock boost clock 1506) - 12.5Mh/s ea. on these with no oneBash changes 2 x ZOTAC 1070 Amp Editions - still testing these. I should be able to bump the mem up by 650Mhz, but they are running much hotter than in Win10. I did the fuzzy %/TDP math and set them at 105W, but no difference. Work in progress. 1 x EVGA Classified 980Ti (why not, just collecting dust). TP Link Smart Plugs for emergency shutdown or cluster power cycle 3 x 15 Amp Circuits Shelly SSH App for iPhone Total cranking out an average of 500Mh/s Future additions include adding 2 more cards (one for the 7th slot and hopefully at least 1 more on the m.2 slot). I would try for a 9th card, but I heard the second m.2 slot will not hash (even though I'm going to try). And I will be adding a couple more 1070s to the 7th rig cluster. |
|
|
|
|
