sit_rp
-
Posts
54 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by sit_rp
-
-
Hello,
After I upgraded from 6.11.5 to 6.12.3 (currently on 6.12.4), I began receiving log messages below.
Oct 18 22:03:05 tower kernel: kvm: vcpu 3: requested 13593 ns lapic timer period limited to 200000 ns
Oct 18 22:03:05 tower kernel: kvm: vcpu 1: requested 13593 ns lapic timer period limited to 200000 ns
I get multiple messages like this everyday since the upgrade. Not sure if it is affecting anything (have not noticed any performance degradation).
Has anybody seen this before? -
Have anybody had issues with not being able to log in after changing password via WebGui? I am on the latest Docker release.
Recently changed my password and can't log in anymore. I tried multiple browsers and incognito modes.
I went ahead and used FILE__PASSWORD variable. And pointed it to /tmp/ folder. Can confirm that the file is there with the password when I cat from console.Also, when container starts I do see this in the logs: [env-init] PASSWORD set from FILE__PASSWORD
But I can't login...Any ideas would be much appreciated. Bad timing since I am very low on space on my backup jobs...
-
On 9/12/2021 at 2:23 AM, jodirt said:
Hi I recently installed Delugevpn but I've been having trouble setting it up. To my knowledge it should say "privoxy process listening to port 8118" at the bottom but it doesn't and I can't access the webui. I'm pretty new to docker and vpns in general so I apologize if the fix is really obvious. I've looked around and I can't work out what the issue is so any help would be appreciated. I'm on arch-linux by the way.
Here's the logs when I start itand here's the compose file
I have the same issue. I have confirmed that VPN tunnel is UP (see below). I can ping the container, but nothing on port 8112. My VPN provider is Windscribe and I am using OpenVPN.
I am able to connect when I turn off VPN.
sh-5.1# ping google.com
PING google.com (142.250.176.206) 56(84) bytes of data.
64 bytes from lga34s37-in-f14.1e100.net (142.250.176.206): icmp_seq=1 ttl=120 time=12.0 ms
64 bytes from lga34s37-in-f14.1e100.net (142.250.176.206): icmp_seq=2 ttl=120 time=11.1 ms
64 bytes from lga34s37-in-f14.1e100.net (142.250.176.206): icmp_seq=3 ttl=120 time=12.2 ms
64 bytes from lga34s37-in-f14.1e100.net (142.250.176.206): icmp_seq=4 ttl=120 time=11.5 ms
64 bytes from lga34s37-in-f14.1e100.net (142.250.176.206): icmp_seq=5 ttl=120 time=14.0 ms
64 bytes from lga34s37-in-f14.1e100.net (142.250.176.206): icmp_seq=6 ttl=120 time=15.3 ms
^C
--- google.com ping statistics ---
7 packets transmitted, 6 received, 14.2857% packet loss, time 6009ms
rtt min/avg/max/mdev = 11.114/12.681/15.269/1.481 ms
sh-5.1# curl ifconfig.io
185.232.22.215
sh-5.1# ss -tulpen
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Failed to find cgroup2 mount
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 0.0.0.0:6771 0.0.0.0:* users:(("deluged",pid=585,fd=21)) uid:99 ino:1389810279 sk:5001 cgroup:unreachable:1 <->
udp UNCONN 0 0 127.0.0.11:59772 0.0.0.0:* ino:1389810785 sk:5002 cgroup:unreachable:1 <->
udp UNCONN 0 0 10.112.82.69%tun0:35759 0.0.0.0:* users:(("deluged",pid=585,fd=17)) uid:99 ino:1389810255 sk:5003 cgroup:unreachable:1 <->
udp UNCONN 0 0 10.112.82.69:35967 0.0.0.0:* users:(("deluged",pid=585,fd=18)) uid:99 ino:1389810276 sk:5004 cgroup:unreachable:1 <->
udp UNCONN 0 0 0.0.0.0:53641 0.0.0.0:* users:(("openvpn",pid=348,fd=3)) ino:1389804412 sk:5005 cgroup:unreachable:1 <->
tcp LISTEN 0 5 10.112.82.69%tun0:35759 0.0.0.0:* users:(("deluged",pid=585,fd=16)) uid:99 ino:1389810254 sk:5006 cgroup:unreachable:1 <->
tcp LISTEN 0 50 0.0.0.0:8112 0.0.0.0:* users:(("deluge-web",pid=617,fd=8)) uid:99 ino:1389768200 sk:5007 cgroup:unreachable:1 <->
tcp LISTEN 0 4096 127.0.0.11:36595 0.0.0.0:* ino:1389810786 sk:5008 cgroup:unreachable:1 <->
tcp LISTEN 0 50 0.0.0.0:58846 0.0.0.0:* users:(("deluged",pid=585,fd=13)) uid:99 ino:1389831372 sk:5009 cgroup:unreachable:1 <->EDIT: I added supervisord.log.
-
Yeah, I only reserved 3%...
Any reason why the actual file is reporting to be bigger than the drive capacity?
-
Please see screenshots attached. I am on Unraid 6.8.3 having issues starting Windows 10 VM (worked fine till recently). Looks like I ran out of space on disk mounted with Unassigned Devices plugin. Everything is up to date and nothing in the logs. Tried rebooting the host.
Any idea what could have happened here and how I can prevent this in the future? I can live with rebuilding a VM, just want to make sure this won't happen again.
-
6 hours ago, saarg said:
Downloading the container and downloading the deb to install the Plex version you set is not from the same place, so it might be that the download speed you have for the Plex deb is slow.
Yeah, you are probably right. I went over the logs and didn't see anything out of normal (I looked at the Plex container logs and docker logs in diagnostics). The only thing I noticed was downgrade warning below.
dpkg: warning: downgrading plexmediaserver from 1.20.4.3517-ab5e1197c to 1.19.5.3112-b23ab3896
At this point I am on the right version and when I restart the container it start in seconds, so it is possible it could have been something stupid like download.
I do appreciate your attention on this.
-
2 hours ago, saarg said:
It's downloading and installing the Plex version you set it to install and that depends on your internet speed and horsepowers.
There is a log button at the end of the Plex container line.
It downloads container within seconds on my server. After I hit play it gets stuck. I don’t have this issue with any other container and if I use the latest version it starts up immediately.
I didn’t notice the logs button but will take a look.
-
11 minutes ago, saarg said:
If you post the container log we might be able to see what is going on. Just saying it hangs isn't really helping us help you.
Very true...I will look up where docker logs are stored.
So I left Plex container alone for about 1 hour while it was "hanged" (0% cpu utilization, only using about 5mb of RAM). Just came back to get my Plex back online with latest version and noticed that it finally booted up and I can get into it. It is reporting 1.19 version in the dashboard.
Definitely need to look through logs here. 1 hour to boot up a container is not gonna roll with me.
-
1 minute ago, wgstarks said:
Have you tried entering just the version number without “VERSION=“?
Sorry I didn't clarify that I pulled that from actually config file. Here is the screenshot of the settings which makes more sense. With this docker starts but hangs. I tried multiple versions including the latest one.
-
Folks, I hope you can point me in the right direction here. I am trying to downgrade from 1.20 to 1.19 to get my camera upload working again.
Version field is there and I read official documentation. Container either pulls the latest image, or just hangs. This is the syntax I am using:
VERSION=1.19.5.3112-b23ab3896
When I do above for any specific version, container starts but doesn’t work. Every other syntax combination just downloads the latest image.
-
Any ideas or should I submit a bug report?
-
Hello,
I have an odd issue as I stated in the title. Time Machine just stops backing up with a generic error message stating that disk is not available. It can take weeks. Most recently it took only 1 day to break. I can access that share no problem from the MacBook (10.15.6). No funny logs on Unraid.
My Time Machine share is not on the array but instead passed through by Unassigned Devices plug-in (external drive connected to USB3 port). Below are the settings I used for SMB. Enhanced MacOS interoperability is enabled. Rather than this, it works well. To get it back and running I restart SMB with /etc/rc.d/rc.samba restart
I hope somebody has seen this before. Thanks for your help!
[Time Machine]
ea support = Yes
path = /mnt/disks/WD4TBPASSPORT/Time_Machine
vfs objects = catia fruit streams_xattr
valid users = timemachine
write list = timemachine
fruit:time machine max size = 3500 G
fruit:encoding = native
fruit:locking = netatalk
fruit:metadata = netatalk
fruit:resource = file
fruit:time machine = yes
fruit:advertise_fullsync = true
durable handles = yes
kernel oplocks = no
kernel share modes = no
posix locking = no
inherit acls = yes#disable SMB1 for security reasons
[global]
min protocol = SMB2#unassigned_devices_start
#Unassigned devices share includes
include = /tmp/unassigned.devices/smb-settings.conf
#unassigned_devices_end -
Just got the same thing.
-
It was worth the try. It doesn't matter what I do, slot1 is always the primary. I ended up swapping my cards around. Gonna test now and see if there is difference in performance. I believe both slots were already running in x8, so I don't think it should matter a lot.
-
Hello,
I have one GPU in slot 1 on mother board (asrock x370 taichi) that I pass through to the VM.
Then, I have a second GPU in slot 2 that I want to use specifically for Unraid.
When server boots up, it always uses the first GPU until the certain point where it get's black listed.
I get no output on the second GPU. It is showing up under System Devices. I can not change this behavior in BIOS because the option is greyed out.
I guess my question here, is there anything I can do in the config file to dedicate second GPU to unraid? I really don't want to move second GPU to slot 1 if I don't have to.
-
Alright. So I was able to run some benchmarks on bare metal and it appears that I am already getting pretty close to the native performance. It's crazy how much my old 6700k is better for gaming than 1700x.
At this point I am pretty positive that CPU is getting bottle necked. Playing around with pinning and isolation is definitely worth it. I have been thoroughly reading the thread below. Completely same behavior on my machine.
Thank you for your help! Hopefully 3900x will help me to get more power out of my 2080 ti.
-
9 hours ago, testdasi said:
Hyper threading is essentially just glorified smart queue management to increase the chance that once the (physical) core is done on its current task, another task is already primed up and available to work on. It does NOT mean both tasks are done in parallel.
The automobile analogy may not be immediately clear to non-petrolheads so maybe it's easier to imagine your CPU as 8 workers, each having 2 apprentices.
- Each apprentice collects necessary materials and put them in a basket for the worker to assemble.
- The assembling takes more time than collection.
- A worker immediately works on assembling if the materials are readily collected but has to wait if the apprentice is still collecting material (or because there's nothing to collect).
I think it probably is more obvious why having 4 workers with 8 apprentices is slower than 8 workers with 8 apprentices.
With regards to isolation, it does not mean 0% load all of the time (but rather 0% load most of the time). Back to the apprentice analogy.
- You isolate the odd apprentice just to deal with VM work but the apprentice is dumb - he doesn't know if the materials handed to him is "VM" or not.
- So if the odd apprentice is handed some non-VM materials, he still hands it over to the worker, who then looks at it and says "yo odd apprentice, you aren't supposed to deal with this, hand it back to someone else" (Digression: I have to do this with my interns all the time)
- Now if the worker is overloaded because the even apprentice keeps on giving him work to do, then the odd apprentice will have to wait for his turn, which will record on the CPU usage measurement as "load".
The above is the reason why if you assign an isolated core to a docker, you will get 100% load only on that single core and nothing on other cores. It's because the apprentice keeps on handing non-VM stuff to the worker who keeps on having to tell the apprentice to hand it to someone else.
Of course, the above assumes you have assigned and isolated cores correctly.
I think I forgot to mention that I didn’t dump gpu bios and it’s not configured in the XML file. I never had any errors passing 2080ti, so I never bothered with that. Can that be the problem? Is it necessary to configure?
-
3 minutes ago, testdasi said:
You misunderstood physical vs logical cores.
- All of your cores 0 to 16 as you see them in Unraid are logical cores i.e. with hyper-threading.
- The physical cores are not numbered. They are inferred based on the logical cores pairing e.g. 0 + 1 = 1 physical core.
Imagine of your CPU as 8 cars being chained together in a train.
They can be front wheel drive (FWD), rear wheel drive (RWD) or all wheel drive (AWD).
- Each car is a physical core. Each pair of wheels is a logical core.
- So in your low performance config, it's equivalent of having only 4 cars driving the train but each car runs in AWD mode.
- The better config, all 8 cars run but in FWD mode. Naturally you get more power. However, the front wheels of the 1st car are also used for steering so you lose a bit of power.
- The best config, all 8 cars run in RWD mode. Same amount of power as the better config but because the rear wheels are not used for steering, you use the maximum power.
- Of course, barebone is all 8 cars run in AWD mode.
Hmm interesting. I was always under impression that 4 cars AWD should be faster than 8 cars of RWD. I guess I was wrong.
It sucks that I can't fully isolate odd cores to be used in Win10 VM only. I have them isolated now and definitely see other VMs using them even though they are isolated and other VMs are pinned to even cores.
-
4 minutes ago, sit_rp said:
The only thing that bothers me is that according to Unraid all odd cores suppose to be hyper threaded and all even cores physical. Looking at the testing I did, it appears that all odd cores are in fact physical, and even hyper threaded.
What I don't understand is why I am getting better performance using all even cores (hyper threaded) versus using 4 physical along with 4 logical cores. So to summarize:
Low performance (Physical along with their logical, according to Unraid dashboard):
8-9
10-11
12-13
14-15
Better performance (All logical, in theory):
0-2
4-6
8-10
12-14
Best so far (All physical, in theory):
1-3
5-7
9-11
13-15
Something about this doesn't make sense to me. I am just hoping that cores are not assigned in the manner where physical core 0 is matched with logical core 3, for example. Assigning all threaded cores to the VM (all even) should have lower performance than assigning physical+corresponding (even+odd) threaded.
Is there any specific way to figure this out or only by testing the pair?
On top of that, I just noticed that even though I have all odd cores isolated, I still see some utilization on those cores even though machine assigned to them is down. Would this be a sign of add cores being hyper threaded? I am getting more and more confused here....
-
2 hours ago, testdasi said:
If I understand what you are doing:,
- Your 8 even cores = 0 2 4 etc. That covers core 0 which Unraid tends to use for its own things so naturally it will have a bit lower performance than 1 3 5 etc.
- Your 8 even / odd cores should by itself be more powerful than your previous 10 cores because your 10 cores = 5 physical cores with hyper threading and your 8 even / odd cores = 8 physical cores without hyper threading. The latter should always be faster than the former, especially since you turned off all other activities i.e. dockers and VMs.
Based on what you reported, it looks like your pairing is 0 + 1 = 1 pair. You can double check that on the Unraid dashboard.
Btw, what you did is one way to maximize performance. I did a similar thing (pinning 3 out of every 4 odd cores to my workstation VM) + use Process Lasso (app recommended by Wendell the Level1Tech guy) to ensure that my games and Plex and work stuff generally don't overlap.
The only thing that bothers me is that according to Unraid all odd cores suppose to be hyper threaded and all even cores physical. Looking at the testing I did, it appears that all odd cores are in fact physical, and even hyper threaded.
What I don't understand is why I am getting better performance using all even cores (hyper threaded) versus using 4 physical along with 4 logical cores. So to summarize:
Low performance (Physical along with their logical, according to Unraid dashboard):
8-9
10-11
12-13
14-15
Better performance (All logical, in theory):
0-2
4-6
8-10
12-14
Best so far (All physical, in theory):
1-3
5-7
9-11
13-15
Something about this doesn't make sense to me. I am just hoping that cores are not assigned in the manner where physical core 0 is matched with logical core 3, for example. Assigning all threaded cores to the VM (all even) should have lower performance than assigning physical+corresponding (even+odd) threaded.
Is there any specific way to figure this out or only by testing the pair?
-
On 8/9/2019 at 9:17 AM, testdasi said:
Let's set the expectation straight first.
- The 6700K base clock is a 4GHz and the 1700X base clock is 3.4GHz. That is a significant difference. GPU-intensive benchmarks (and games) benefit more from a higher base clock.
- Barebone can turbo boost higher since there's a lower load on all cores.
- You have to then add virtualisation overhead to the equation. Again it's not insignificant.
So basically, your barebone 6700K vs VM 1700X comparison may not be entirely oranges vs apples but it's pretty close.
Now in terms of optimisation:
-
You need to appreciate that a Ryzen CPU contains 2 CCX "glued" together.
- Don't use an odd number of physical cores (e.g. your 10 logical = 5 physical) on Ryzen. An odd number of physical cores ensures that 1 CCX is always overloaded, reducing overall performance. Based on my testing, the lost performance can be as much as 1 core (e.g. 3+3 is just as fast as 3+4)
- Spread the even number of physical cores evenly across both CCX will also help (so don't do 2+4, do 3+3)
- Check your CPU core numbering scheme so you don't accidentally pin the wrong hyperthreaded pair. BIOS changes have been known to change the numbering scheme (e.g. 0+1 = 1 pair becomes 0+8).
- When you do your Q35 machine type template, did you add the qemu tag (see below) at the end so your emulated PCIe slots run at full PCIe x16 speed?
You need to add this above </domain> for Q35 machine type.
<qemu:commandline> <qemu:arg value='-global'/> <qemu:arg value='pcie-root-port.speed=8'/> <qemu:arg value='-global'/> <qemu:arg value='pcie-root-port.width=16'/> </qemu:commandline>
So I am making some progress here. I added the PCi express values for Q35 machine, but didn't see any increase in performance. I did notice that under Nvidia Control Panel I used to get PCI Express x1, but after adding above to XML file I am getting x16 GEN 3. So that's good.
Now cpu pinning. I have been reading some threads and experimenting with cpu assignment. For this test I turned off all my other VMs and docker containers. If I use 8 even cores, my 3dmark graphics score goes up to 32000, which is an extra 2000. No change in CPU score.
If I use 8 odd cores, my 3dmark graphics score stayes at 32000, but my CPU score goes up by 2000 points. Basically better score than when I had 10 vcores assigned. But this time only 8
At this point I am trying to determine a proper way to figure out physical core numbering and their relative logical cores. I will be doing some reading, but so far my motherboard manual has no such information.
If you guys know a decent way to figure this out please let me know. I am going to continue experiment with core assignment...
Also, I purchased another 1tb M.2 drive. I will install fresh copy of windows on it so I can do some proper testing. This way we don't have to compare 6700k 4.5ghz 3200mhz RAM machine with 1700x 3.5ghz 3000mhz RAM one.
At the end of the day, I am pretty positive on getting 3900x when new bios comes out with fvio fixes. That's if I can find one in stock...
I will update this thread as I make more progress.
-
2 hours ago, bastl said:
As you maybe already noticed. It's kinda hard to compare 2 systems if every spec is different. Memory speeds and latency is a huge thing on the first gen Ryzen's. As already mentioned by testdasi, the chiplet design and the communication between the chips is the next thing you have to count in. Different cores for a VM can lead to different memory speeds/latency. The next thing, which slot for the GPU are you using? Some aren't connected directly to the CPU. Limiting the speed of the PCIe lanes by using a slot wired to the chipset can also be an issue. 16 vs 8 lane slots shouldn't be an issue but only using 4 lanes of the chipset shared with other devices (USB, network, storage) will bottleneck the GPU.
Yeah i know it's hard to troubleshoot this way. Unfortunately I don't have a choice at the moment.
GPU is connected to the first pci slot. It should be running at 16 but I will have to double check.
-
1 minute ago, bastl said:
ACS Override is not a thing that you set to gain performance. It's only usecase is to split your IOMMU groupings to separate devices from each other. 30k vs 37k is a huge difference for graphics score only. With overhead of virtualisation 1k maybe 2 is what you can expect. Disc IO as example shouldn't be the issue. Benchmarks and game engines are loading the most stuff at the start. Maybe the memory speed is what causing the difference for you. Are you using the same dimms and the same XMP profile for both tests?
Tests we performed on two different machines.
In terms of Unraid, I don't recall enabling XMP, I will have to double check. RAM should be running at 3000Mhz.
-
2 minutes ago, testdasi said:
Let's set the expectation straight first.
- The 6700K base clock is a 4GHz and the 1700X base clock is 3.4GHz. That is a significant difference. GPU-intensive benchmarks (and games) benefit more from a higher base clock.
- Barebone can turbo boost higher since there's a lower load on all cores.
- You have to then add virtualisation overhead to the equation. Again it's not insignificant.
So basically, your barebone 6700K vs VM 1700X comparison may not be entirely oranges vs apples but it's pretty close.
Now in terms of optimisation:
-
You need to appreciate that a Ryzen CPU contains 2 CCX "glued" together.
- Don't use an odd number of physical cores (e.g. your 10 logical = 5 physical) on Ryzen. An odd number of physical cores ensures that 1 CCX is always overloaded, reducing overall performance. Based on my testing, the lost performance can be as much as 1 core (e.g. 3+3 is just as fast as 3+4)
- Spread the even number of physical cores evenly across both CCX will also help (so don't do 2+4, do 3+3)
- Check your CPU core numbering scheme so you don't accidentally pin the wrong hyperthreaded pair. BIOS changes have been known to change the numbering scheme (e.g. 0+1 = 1 pair becomes 0+8).
- When you do your Q35 machine type template, did you add the qemu tag (see below) at the end so your emulated PCIe slots run at full PCIe x16 speed?
You need to add this above </domain> for Q35 machine type.
<qemu:commandline> <qemu:arg value='-global'/> <qemu:arg value='pcie-root-port.speed=8'/> <qemu:arg value='-global'/> <qemu:arg value='pcie-root-port.width=16'/> </qemu:commandline>
Thank you for reply.
Yes, I understand that single threaded performance will be better on 6700k. This is the reason why I am leaning towards only testing with Superposition since it uses very little CPU.
I did notice that I was getting slightly higher graphics score in 3dMark with 4 physical cores passed through versus 5. The only issue is that most of the games I play do like having an extra 2 threads, since like you mentioned, 1700x 3.5ghz boost is rather low (keeping fingers crossed for that 3900x one of these days).
I am usually running on i440fx machine, but when I did test Q35, I didn't apply the template above (first time reading this), so this might be worth the try.
Another quick thing I forgot to mention. ACS Overrride is off. When I had it enabled before I think performance was worst, but I don't remember anymore since I have been making a lot of changes. Including re-installing Win10 from scratch.
kernel "lapic timer period limited" messages after upgrading to 6.12
in VM Engine (KVM)
Posted
bump.
Nobody seen this before? Maybe this is not an Unraid version issue but a Docker container/VM machine issue? I do upgrade those on monthly basis...