Jump to content

testdasi

Members
  • Content Count

    1345
  • Joined

  • Last visited

  • Days Won

    3

testdasi last won the day on September 5

testdasi had the most liked content!

Community Reputation

135 Very Good

1 Follower

About testdasi

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

1347 profile views
  1. I have she-who-must-be-obeyed put it in her weekly reminder. (She) say it - (I) do it - (backup) sorted.
  2. More RAM alone won't necessarily resolve your problem. Crashplan is known to eat memory for breakfast lunch and dinner (btw, I believe Crashplan uses java so that's what Brit saw). The short term way around it is to limit Crashplan docker memory usage so it doesn't end up eating other stuff. In Docker template, click Advanced View then in the Extra Parameters box add --memory=8G (in the above example, it will limit the memory available to Crashplan to 8G - I actually had to use 8G because 4G crashes my Crashplan - just to demo how much memory Crashplan needs). In the medium term, add more RAM so you have more available for other stuff. In the long term, I would recommend moving away from Crashplan all together. They used to be great but no more.
  3. I go for a simpler approach: my backup trigger is manual. I trust me more than any script and automatic backup, in my opinion, defeats the purpose even without the cryptovirus scenario e.g. maybe I accidentally delete something or edit something wrongly -> automatic backup -> no recovery.
  4. Let's try these: Update to latest (6.8.0-rc9) Change your Q35 machine type to Q35 4.0.1 (6.8.0 has qemu 4.x which has better PCIe support for Q35 machine type). Add <ioapic driver='kvm'/> to before </features> in your xml Tools -> Diagnostics -> attach new zip file (every time you make major changes like ACS Override etc, it's always worthwhile to dump a new set of diagnostics since your config would change rather drastically).
  5. Are you looking to sync or to back up? Same same but different. For example, if u accidentally delete a file, a sync will ensure that file is also gone on the other side. That is why we don't run back up as a sync. Specifically to your case, you don't want the Unraid server to perform the back up (a "pull" ). You want your main PC to decide what and when to back up onto the Unraid storage (a "push" ).
  6. You didn't read my entire post, did you? I specifically mentioned: "For CPU before 2015, you need to multiply the passmark by 2, hence, the 2000 passmark per stream general advice." Your Xeon E5-2680 v2 (there wasn't a 2860 so probably a typo there) came out in 2013. The OP asked specifically about Ryzen (which came out in 2017) so I am comfortable with providing the post-2015 estimate and, even so, tried to protect myself with a specific statement about CPU before 2015. Your point about bit-rate, while valid, is also missing the point about the estimate. The Plex 2000 passmark estimate is conservative to begin with because Plex doesn't want people who skim and blame their (official) guidance that their exactly-2000-passmark CPU can't handle a 20Mbps 1080p stream. Peak bit rate is the reason why we have buffer. The passmark estimate is based on average because with a buffer, the peak is evened out by all the time that the bit rate doesn't reach 50Mbps. Let me quote myself again: "We are estimating, not calculating the trajectory of a nuclear missile." I would say 1x H265 or 2x H264. 3x H264 depends on the actual vids. My 2990WX on a single core (provided it is on the NUMA node with memory controller) can do 2x H264 1080p streams at about 95% load and its single core passmark is 2072 LOL.
  7. Tools -> Diagnostics -> attach zip file. Also provide your VM xml (if copy-paste, use the forum code functionality - the </> button next to the smiley button). Also, your whole paragraph about vfio and initrd suggests you are not following instructions exactly. It is very hard to know what is wrong to help if we can't be sure if what is in the guide was followed or not.
  8. Try switching machine type. I noticed if shutting down Q35 VM = GPU fans still spinning but shutting down i440fx VM = GPU fans stop. That suggests at least a difference in power draw when VM is not running between the 2 machine types.
  9. +1 Customisable grouping would be very useful if incorporated with additional functionalities such as the ability to start/stop a group together. Imagine having 2 set of dockers, 1 for when gaming VM is run and 1 otherwise. In a few clicks, you can switch between them. This can be done using scripts easily (e.g. what I'm doing) but would be a lot more user friendly on the GUI.
  10. Exactly 8 cores, and should be the last 8 physical cores (+ their hyper-threading sisters). The 3950X has 2 CCD's linked together with Infinity Fabric. You don't want to jump CCD when processing things as cache needs to be copied to the other CCD, introducing latency. The IO die design only mitigates cross-CCD latency but cannot eliminate it. The 1st CCD (first 8 physical cores + HT sisters) contains core 0, which should generally be left free for Unraid to do Unraid things - so the 1st CCD can't be fully isolated. The 2nd CCD, in contrast, can be fully isolated to the VM in syslinux for the lowest possible latency. 8 cores are more than enough for all current triple-A titles. For games that don't need that many cores, 4 cores (i.e. same CCX) are probably even better for more consistent performance. But that's overthinking things in a sense. RAM is less important. 16GB is sufficient for most games. 32GB is an overkill. In fact, your rig, with the usage you are reporting, is an overkill.
  11. TL;DR - I don't think his result is different from the expected performance of Ryzen. You can actually get a pretty decent estimate from the passmark score and the relative complexity difference between 4k vs 1080p and H265 vs H264. Each 4k H265 stream needs about 7500-8000 passmark => each 1080p H265 stream about 1800-2000 => each 1080p H264 stream about 1000. Note: the above only applies to CPU after about 2015 when H265 hardware accelerated video became a thing. For CPU before 2015, you need to multiply the passmark by 2, hence, the 2000 passmark per stream general advice. I think there was also a period before 2015 that H264 was accelerated but H265 was not and AMD implementation was different from Intel etc. but that is overly complicating things. We are estimating, not calculating the trajectory of a nuclear missile. So just to estimate from my 2990WX, which has about 23200 passmark. I only use 1 bank of the hyper-threaded pairs for Plex and an additional hyper-threaded core adds about 30% performance so using 1 bank drops my (estimated) score to 17800. I only use half of the cores (let's ignore NUMA problem for now), so I'm down to about 8900 passmark for my Plex. So based on the estimate, I should be comfortable with 1x 4k stream or 4x 1080p streams - which is very much consistent with my own experience. If I ever have to do more than 2 4k streams simultaneously, I will certainly get a P2000 and donate a few beers to Unraid Nvidia guys.
  12. I suggest perhaps you post in the UD support topic. I haven't seen this before.
  13. Press the black + button on the lower right of the black disk icon below the "T" in IDENTIFICATION to show the individual partitions.
  14. Yes and no. You can get a SATA power cable extension to really run as many output from a single PSU cable as you want. However, the power draw (i.e. current) on the cable can exceed what it is rated for and causes it to literally melt. This can happen even without actual failure of the connector / cable due to HDD power surge when spinning up. When this happens, at best, your PC smells really bad and you need to rebuild parity due to drives dropping offline but at worst, your disks are dead. Note: not that it will definitely happen, just that the chance of it happening increases with every additional drive you add to the same line. So you are better off running multiple cables (i.e. using multiple plugs on the PSU).
  15. Turn on Syslog server to mirror to flash (Settings -> Syslog Server). Start your server, wait till crash happens, reboot. Tools -> Diagnostics -> attach zip file Attach mirrored syslog file (which should include both pre and post crash events).