Veah

Try this then update it. Then verify the boot settings; I typically disable every option for boot other than the USB drive.

That's certainly a good idea. Let mover take care of it's thing when nothing is going on.

Would depend the amount of streams. Try to max out how many streams you aim to host and then check the drive speeds on your nvme under main. Should give the a reasonable answer.

Set it to 99 downloads and see. In my case with a 400mbps connection, I see no difference between 50 and 99. For nvme write speeds... I don't think gen 3 or gen 4 would be noticeable in your downloading endeavours.

Would you need a firewall>rules wan rule set to pass data?

Might be your drive blk size is not 512? Look over this if so.

Found something peculiar while testing and I am not sure how to explain it. While running some ARRs and Nzbget, I have a single disk that continuously spins up and writes a couple hundred KB data every ew minutes while the rest remain spun down. This thread made me look closely because it started to bother me. I (tried 100 random things then) went through the containers settings (gui) under 'Show more settings...' and changed the Appdata path from </mnt/user/appdata/nzbget/> to </mnt/NVMEDRIVENAME/appdata/nzbget/> and now ALL my HDDs are staying spun down. I'm at 30 min now with Radarr, Sonarr, Lidarr, Hydra2 going, as well as Nzbget actively downloading linux distros. My problem drive is sleeping soundly. If someone can help this make sense to me, I would appreciate it.

Just drop in the new CPU and fire it back up. Adjust pinning at your leisure.

Should get about double that. Bottleneck somewhere.

Something like that is tough to nail down. My guess is something about your new HW. Maybe the memory or could be individual core speed of the CPU. Was your nvme connected directly to CPU on previous config and now shared thru a MB chipset? Probably more possible explanations along that line. I do not think unraid would harbor old drivers causing an issue within itself. Could fire up a trial USB and test. If that's faster, you could have your answer.

The iperf speeds look right. Cache drive activity is normal.

Can try 3.3v mod https://imgur.com/a/3-3v-pin-reset-BFdmB

Is the drive seen in bios? Check power and data cables.

@Lou2k7 if you have a drive controller card in there, check to disable all of its power related settings. Those cause conflicts with Unraid drive power settings.

You could stop the array and sort it out. If lucky, it's just a cable issue (power/data)

If you have parity there is no real rush to upgrade it unless you need the extra space or for some other reason anticipate the drive to fail. Normally these things start throwing errors for a bit before they just stop completely.

May be best. If you have the resource, time, and inclination, you could try a VM to see how it goes.

USB drives and Unraid are a hit and miss combo. Cautious to write the MB off as bad in your scenario.

I use 86400 (seconds) which is 1 day

Possibly polling. Try this:

I'm not versed with this game but this here looks like some more ports to forward.

Have you tried assigning the docker it's own IP? May be easier to work with that way. Edit: Host instead of bridge mode.

You could technically HW raid the 2 8TB drives together into a single 16TB drive, then assign as a single parity disk within unraid. The parity drive size requirement of being equal or larger than your biggest array drive still remains. Have tested that with an ase 71605. Was more of a novelty than practical and I reverted back to normal singular parity siak after a few days.

Didn't realize this was double post. Have a read this thread.

Hope this can help