Happy to report that the standard unit I ordered from Batch 3 arrived yesterday and I had zero issues connecting it into my existing Full + Standard ones that were from batch #2. I did have an old USB 2 hub at the ready in case it was needed, however it was not. I hooked up the additional standard unit to one of the full unit's USB3 ports and it was immediately added to the party when I powered everything back up.

Thanks for a great job Team FutureBit!

IMHO, your general questions are better suited for reddit's ether mining sub --- www.reddit.com/r/EtherMining/

Good luck!

Here's a quick update re: a workaround I discovered that remediates the bizarre errors I was getting from PM...

So to recap, for the past five days the rig was running PM v5.9d for the AMD RX580 GPUs and t-rex for the nVidia GPUs because PM glitched on me after this month's Win10 patches. That was alright, but let's just say I am not a fan of the t-rex console, nor of its higher dev-fees, and I missed some of PM's features like being able to hit C while mining when you want the app to re-read its config settings and update them on the fly, so I didn't leave well enough alone.

This evening, I went into the UEFI of the motherboard (it's an ASUS brand with an AMD x570 chipset) and fiddled with the settings for the PCIe version assigned to each PCIe slot. Previously, all four were set to Auto and the newer nVidia RTX 3000-series GPUs were being set to PCIe 4 automatically while the RTX 580s were being set to PCIe 3. Pretty normal stuff. Don't ask me why but I decided to set all four expansion slots to PCIe 3 to see what would happen. Lo and behold, PhoenixMiner is back to normal! You could even go so far as to say that it's risen from the ashes. (cue rimshot)

So, take this fwiw. Maybe it'll help someone else too. Cheers.

@miner29 - if your reply was directed towards my post, just above yours, then first off thank you for weighing in... I should add that per the nVidia control panel we're still using driver package 470.05, and per device-manager's info the timestamp on the driver file is still 2021-02-26, so I believe I've ruled out Microsoft being helpful with a GPU driver update. (Also, I looked at update history and aside from the monthly cumulative update, nothing else was applied yesterday. bummer.)

That said, I'm not averse to cleaning up the existing nVidia drivers package using DDU followed by a reinstallation of the same to see if anything changes.

In the meantime I did get t-rex going to see what it thinks. Both cards are hashing and t-rex was able to set the memory and clock speed deltas, and the clock power delta. Of course nothing's perfect - it is claiming it can't see the temps of the graphics memory so I can't specify a fanspeed range based on mem-temps. IDK if that ever worked because I've never used t-rex for ethash before and heck, I'm not sure I want to switch because t-rex doesn't support AMD GPUs like PM does, which means I'd have to run PM for AMD and t-rex for nVidia on this mixed GPU rig. Yaay.

Hey all, got what amounts to a head's up for folks. (Not sure there's a solution...)

I have a rig running Win10 with two nVidia GPUs, one being a 3060 so I have the drivers v470.05 installed to unlock full hashrate for that GPU which is also installed in a 16-bit slot and cabled up to HDMI. The other nVidia card is a 3060 Ti (non-LHR) and this system also has a pair of AMD RX580-8GB in it. PM is in charge of all hardware control for all four cards.

Things were completely stable until yesterday and the rig was still running PM v5.7b (just due to laziness on my part - no incentive to update PM's bits, as nothing was having an issue.)

As I said, all was well - the rig was up over 600 hours non-stop until I un-paused updates and allowed the monthly cumulative updates for Windows to be installed yesterday. (I do this manually, every month.)

Now, for these two nVidia cards on that driver version, PM has lost its ability to set clock speeds for GPU and Memory. Instead, I get messages with error - 137, like this:

GPU1: Unable to reset memory clock delta - error -137
GPU3: Unable to reset memory clock delta - error -137
GPU1: Unable to set GPU clock delta to -400 MHz - error -137
GPU1: Unable to set memory clock delta to 1200 MHz - error -137
GPU3: Unable to set GPU clock delta to -200 MHz - error -137
GPU3: Unable to set memory clock delta to 1370 MHz - error -137

I can only assume that something in this month's Win10 patches is messing with stuff and it could be/probably is specific to this particular nVidia driver. One thing I did note was that for the first 20 minutes after the reboot, after patching, everything was still normal as far as mining was concerned. But 22 minutes into it, I saw this appear in the log:

2021.12.17:19:03:55.165: gps3 CUDA error in CudaProgram.cu:256 : unknown error (999)
2021.12.17:19:03:55.165: GPU3 CUDA error in CudaProgram.cu:474 : unknown error (999)
2021.12.17:19:03:55.165: GPU3 GPU3 search error: unknown error
2021.12.17:19:03:55.165: gps3 CUDA error in CudaProgram.cu:256 : unknown error (999)
2021.12.17:19:03:55.165: wdog Fatal error detected. Restarting.
2021.12.17:19:03:55.165: eths Eth: New job #7a9544e3 from ssl://us1.ethermine.org:5555; diff: 4295MH
2021.12.17:19:03:55.219: GPU1 CUDA error in CudaProgram.cu:474 : unknown error (999)
2021.12.17:19:03:55.219: GPU1 GPU1 search error: unknown error

(GPU3 is the 3060, GPU1 is the 3060Ti)


FWIW, there is no difference if I run PM v5.9d with my same config file, I get exactly the same error when PM is starting up as above, the 'unable to set/reset clocks' errors. My next action will be to look in recently-installed updates to see if there is something like a driver that was downloaded after the reboot which I might be able to uninstall.

What's truly insidious about this is the fact that if I test by using PM in benchmark mode and I employ MSI Afterburner to set core clocks/frequencies/undervolts (instead of PM) - that all still works just fine. And Afterburner is not a recent version, it's one that's a few versions behind because I prefer the one with the older UI - which shows that evidently it is still possible (for apps other than PM) to set clock deltas, post this-month's Win10 updates, and with the same version of the nVidia driver, and without said app requiring some sort of update.

OK, there you have it. Sorry about the long post. Just sharing with the class. I've been using PM for a long time and love how stable my particular (four) rigs are - or, were - up till now. BTW, none of the other rigs I have require that funky driver, in fact they're using older nVidia drivers than 470.05, and none of them are any worse for the wear after yesterday's patching. Just this funky one. Cheers.

To upgrade to a larger M.2 SSD without an enclosure, I first got a second SD card and imaged it using the resources from the first post. That was more of a precaution than a necessity.

Then, since my node was fully in sync on the original SSD, before I replaced the M.2 SSD I use the full node's file manager app to connect to a valid SMB file-share target on my home network and copied the node's data-files to it. It's way faster copying ~400 GB of data on your home network than it is to wait for the node to re-sync from scratch. Then I shut everything off and replaced both the SD card and the M.2 SSD. Upon bootup the OS formats the M.2 and starts to sync the node, which will take days. So, that's the time to stop the node, reconnect to the file-share and copy the data-files you backed up onto the new SSD, overwriting whatever the node just recently created with what we know to be complete data files. Then all ya have to do is re-start the node and it'll sync any changes that occurred while you were working on the full unit. That'll take minutes, as opposed to days.

HTH

@Notyourbusiness, just curious if you tried the advice given by @Rickirs and if it changed anything. Please let us know.

I too am seeing this occur on one of my four mining rigs and I can't figure out why. It doesn't run any other apps and I know that the source of the software utilities/drivers that I've installed is trustworthy. Initially I thought this could be the anti-virus/malware engine scanning memory however I've switched brands (from Windows Defender to Symantec Endpoint Protection) and disabled all periodically scheduled scans and this is still happening occasionally. The rig is 100% nVidia 30-series now, however I used to run mixed with AMD. I thought I did a thorough uninstall/cleanup of the AMD drivers when I stopped using those cards however I used the AMD cleanup utility not DDU so I'm curious about your experience.

For anyone experiencing issues connecting to pools, this info might help...

If, in your house you happen to own an ASUS wifi router/firewall, check and see if your model has a feature called 'Two-Way IPS' - which is part of the firewall and packet filtering settings and if you do, try disabling it.

I run an ASUS GT-AX11000 Router - one of their high end gaming routers and evidently the 'Two-Way IPS' logic inside the router was blocking the connection to slushpool. Of course there was NOTHING in the firewall's network protection dashboard that indicated this to be the case, but as soon as I disabled 'two-way IPS' the miner worked.

The background on this is as follows... I was pulling my hair out for two weeks or more trying to understand why I couldn't connect to any pool and then tried testing it using a VPN and discovered the connections were successful if using a VPN.

Since I knew that running the miner inside a VPN tunnel works, the question is, what is not 'seeing' the traffic due to the VPN? - Well, Comcast isn't seeing it, that's true and my ISP was what I was afraid was causing the issue. But with the VPN in use, the port filtering on my firewall/router ALSO isn't seeing traffic to e.g. slushpool, and that's why subsequent connection attempts worked. Turns out it wasn't Comcast, it was my firewall.

Turns out other miners also have experienced this issue. Check this old post on Reddit:  https://www.reddit.com/r/MoneroMining/comments/m1g0y1/cannot_reach_any_pool_without_tls/

Any off the shelf ATX PSU (sized appropriately) should work fine. You just need to be aware that for the PSU to power itself up when the power switch is moved to the ON position requires you to jump two pins on the 24-PIN motherboard cable. This of course means that in addition to the PCIe power cables, if it's a modular PSU you also need to connect the 24-pin cable to the PSU.

reference:  https://www.instructables.com/How-to-power-up-an-ATX-Power-Supply-without-a-PC/

-good luck!

FWIW, I too am only showing 10/32 connections (I'm a batch 2 so the node has been running for just a couple days and is 84% sync'd)

I verified that inbound connections to my node from the internet are working using this website here that someone else in the thread provided earlier. Give it a try:  CanYouSeeMe dot Org

All you do is pull the web page up using the browser on your full node and then edit the 'Port to Check' so it reads 8333 and click the 'Check Port' button. It will come back with 'Success' if your firewall/router is set up correctly.

Hi all, quick question for planning as I wait for my Batch 2 order to arrive...

I ordered a Full package plus a Standard unit, both without PSUs because I have spares here.

Will it be OK to hook one PSU up to both systems provided that the PSU can support the four PCIe power connections that when combined, the Apollo nodes will need? I have a 650 watt and a 750 watt here. Either would be overkill for one unit but one could support both if that's not a concern.

Thoughts?

Is anyone currently using T-rex to mine Conflux via the Octopus protocol?
If so, would you please share the commands you use?

I can't seem to get it to work properly on any of the systems I've tried so far when running either T-Rex v0.20.0 or v0.19.14 (Windows) clients.

I've tried to connect to the WoolyPooly and F2Pool pools and T-Rex behaves the same for both, where I get the same error during startup:


So far I have:

• Verified that I am not being blocked by my firewall. I know this because I can see an established connection to the pool's IP and port when I check using netstat -a. I also added the T-Rex executable to my host OS' firewall exceptions list.
• Made sure that I run T-Rex.exe in an administrative command prompt.

FWIW, I submitted a ticket to F2Pools and they wrote back advising me to shorten and simplify the worker name in my command line, which I've done however it makes no difference.

I'm stumped.