Re: [qubes-users] [R4.0] CPU Freq Scaling, or "Why am I stuck at 2.1 Ghz?"
With careful hardware selection you can avoid the pitfalls to gaming in a VM. Well not the security pitfalls, although they are mostly contained in a VM. Also with the correct hardware you can game with 95% of the performance when compared to bare metal. There are many pitfalls to avoid like Nvidia blocking PCI pass-through to AMD reset bugs. These can be avoided with careful hardware selection. This link will get you started in your search for gaming in a VM. https://forum.level1techs.com/t/play-games-in-windows-on-linux-pci-passthrough-quick-guide/108981 Please do not bother the good developers here with questions as I believe this is outside the scope of qubes. Take any questions you have to Level1Techs. John On Sunday, December 9, 2018 at 9:13:05 PM UTC+1, Stuart Perkins wrote: > On Sun, 9 Dec 2018 17:13:54 + > Mike Keehan <>snip>> wrote: > > >On Thu, 6 Dec 2018 15:54:17 -0800 (PST) > >Eric Duncan <>snip.com>> wrote: > > > >> Finally received my new Thinkpad X1 Yoga 3rd gen. > >> > >> i7-8650U up to 4.2 Ghz Turbo > >> > >> How can I debug/check that my CPU governor/frequency is scaling > >> correcting under Qubes R4? > >> > >> So far, the only thing I've found is xentop/xl top that lists the CPU > >> - as a never-changing 2.1 Ghz. Maybe this isn't the best way to > >> measure CPU freq under dom0? All other tools seemed to want to use > >> xfce4 tools, which seemed to only be specific to that fedora VM - and > >> not the xen host. > >> > >> /TL;DR > >> > >> > >> I let Windows 10 register itself before wiping the disk and > >> installing Qubes R4. Under Windows, Google Chrome benchmarked around > >> 5300 pts with the online tool I was using. As a test, I also > >> installed Arch Linux briefly to test Chrome performance, and it came > >> in around 4500 pts. I chalk that up to not optimizing anything on > >> the system - just a raw install and no tweaks. > >> > >> Now, under Qubes R4.0, I'm still noticing a lot of > >> sluggishness/slowdowns just like my older Thinkpad Helix has always > >> had under Qubes R3.2 (and one of the reasons why I waited for this > >> quad core CPU to upgrade my Qubes install). I could never benchmark > >> Chrome under that Helix dual-core low-powered device. > >> > >> I loaded up Chrome on a new debian-9 VM and... Almost the same > >> extremely sluggish performance. Google Chrome can't even get > >> partially through the benchmarks without timing out, much less finish > >> them. > >> > >> I've tried assigning 4 and even 8 vcpus to try to max things out. > >> > >> I am wondering where to start to debug this. > >> > >> Is it a dom0 cpu scaling thing? > >> > >> Does Qubes impose some artificial throttling? > >> > >> Is it a lag in iGPU rendering through the DisplayVM? (this DisplayVM > >> is a new concept to me, still trying to figure it out) > >> > >> I've spent about 3 days on this device with various other issues to > >> get to this point (no S3 sleep yet, pixel-perfect scaling of the HDR > >> 1440p 14" display, etc). I few duckduckgo searches hasn't turned > >> anything up yet; so, i'll continue when I have some time. > >> > >> Thanks! > >> -E > >> > > > >Hi Eric, > > > >If your Chrome benchmarks involve 3D acceleration using the GPU, then > >they won't work under Qubes. > > > >Each Qube VM renders it's windows in software, which is then copied to > >dom0 for display on the Xwindow system. Only dom0 has access to the > >GPU, and you are not supposed to run applications on dom0 for security > >reasons. (And of course, dom0 has no internet connection anyway.) > > > >Mike. > > > > Qubes is a "security oriended" OS. If you want to game, use a different > physical system. Gaming by its very nature is best done NOT in a VM. > > Stuart -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0b78e341-d149-49ef-86d7-026489e699b1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [R4.0] CPU Freq Scaling, or "Why am I stuck at 2.1 Ghz?"
On Sun, 9 Dec 2018 17:13:54 + Mike Keehan wrote: >On Thu, 6 Dec 2018 15:54:17 -0800 (PST) >Eric Duncan wrote: > >> Finally received my new Thinkpad X1 Yoga 3rd gen. >> >> i7-8650U up to 4.2 Ghz Turbo >> >> How can I debug/check that my CPU governor/frequency is scaling >> correcting under Qubes R4? >> >> So far, the only thing I've found is xentop/xl top that lists the CPU >> - as a never-changing 2.1 Ghz. Maybe this isn't the best way to >> measure CPU freq under dom0? All other tools seemed to want to use >> xfce4 tools, which seemed to only be specific to that fedora VM - and >> not the xen host. >> >> /TL;DR >> >> >> I let Windows 10 register itself before wiping the disk and >> installing Qubes R4. Under Windows, Google Chrome benchmarked around >> 5300 pts with the online tool I was using. As a test, I also >> installed Arch Linux briefly to test Chrome performance, and it came >> in around 4500 pts. I chalk that up to not optimizing anything on >> the system - just a raw install and no tweaks. >> >> Now, under Qubes R4.0, I'm still noticing a lot of >> sluggishness/slowdowns just like my older Thinkpad Helix has always >> had under Qubes R3.2 (and one of the reasons why I waited for this >> quad core CPU to upgrade my Qubes install). I could never benchmark >> Chrome under that Helix dual-core low-powered device. >> >> I loaded up Chrome on a new debian-9 VM and... Almost the same >> extremely sluggish performance. Google Chrome can't even get >> partially through the benchmarks without timing out, much less finish >> them. >> >> I've tried assigning 4 and even 8 vcpus to try to max things out. >> >> I am wondering where to start to debug this. >> >> Is it a dom0 cpu scaling thing? >> >> Does Qubes impose some artificial throttling? >> >> Is it a lag in iGPU rendering through the DisplayVM? (this DisplayVM >> is a new concept to me, still trying to figure it out) >> >> I've spent about 3 days on this device with various other issues to >> get to this point (no S3 sleep yet, pixel-perfect scaling of the HDR >> 1440p 14" display, etc). I few duckduckgo searches hasn't turned >> anything up yet; so, i'll continue when I have some time. >> >> Thanks! >> -E >> > >Hi Eric, > >If your Chrome benchmarks involve 3D acceleration using the GPU, then >they won't work under Qubes. > >Each Qube VM renders it's windows in software, which is then copied to >dom0 for display on the Xwindow system. Only dom0 has access to the >GPU, and you are not supposed to run applications on dom0 for security >reasons. (And of course, dom0 has no internet connection anyway.) > >Mike. > Qubes is a "security oriended" OS. If you want to game, use a different physical system. Gaming by its very nature is best done NOT in a VM. Stuart -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20181209141257.1656323c%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [R4.0] CPU Freq Scaling, or "Why am I stuck at 2.1 Ghz?"
On Thu, 6 Dec 2018 15:54:17 -0800 (PST) Eric Duncan wrote: > Finally received my new Thinkpad X1 Yoga 3rd gen. > > i7-8650U up to 4.2 Ghz Turbo > > How can I debug/check that my CPU governor/frequency is scaling > correcting under Qubes R4? > > So far, the only thing I've found is xentop/xl top that lists the CPU > - as a never-changing 2.1 Ghz. Maybe this isn't the best way to > measure CPU freq under dom0? All other tools seemed to want to use > xfce4 tools, which seemed to only be specific to that fedora VM - and > not the xen host. > > /TL;DR > > > I let Windows 10 register itself before wiping the disk and > installing Qubes R4. Under Windows, Google Chrome benchmarked around > 5300 pts with the online tool I was using. As a test, I also > installed Arch Linux briefly to test Chrome performance, and it came > in around 4500 pts. I chalk that up to not optimizing anything on > the system - just a raw install and no tweaks. > > Now, under Qubes R4.0, I'm still noticing a lot of > sluggishness/slowdowns just like my older Thinkpad Helix has always > had under Qubes R3.2 (and one of the reasons why I waited for this > quad core CPU to upgrade my Qubes install). I could never benchmark > Chrome under that Helix dual-core low-powered device. > > I loaded up Chrome on a new debian-9 VM and... Almost the same > extremely sluggish performance. Google Chrome can't even get > partially through the benchmarks without timing out, much less finish > them. > > I've tried assigning 4 and even 8 vcpus to try to max things out. > > I am wondering where to start to debug this. > > Is it a dom0 cpu scaling thing? > > Does Qubes impose some artificial throttling? > > Is it a lag in iGPU rendering through the DisplayVM? (this DisplayVM > is a new concept to me, still trying to figure it out) > > I've spent about 3 days on this device with various other issues to > get to this point (no S3 sleep yet, pixel-perfect scaling of the HDR > 1440p 14" display, etc). I few duckduckgo searches hasn't turned > anything up yet; so, i'll continue when I have some time. > > Thanks! > -E > Hi Eric, If your Chrome benchmarks involve 3D acceleration using the GPU, then they won't work under Qubes. Each Qube VM renders it's windows in software, which is then copied to dom0 for display on the Xwindow system. Only dom0 has access to the GPU, and you are not supposed to run applications on dom0 for security reasons. (And of course, dom0 has no internet connection anyway.) Mike. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20181209171354.226b77a3.mike%40keehan.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [R4.0] CPU Freq Scaling, or "Why am I stuck at 2.1 Ghz?"
On 12/7/18 1:54 AM, Eric Duncan wrote: Finally received my new Thinkpad X1 Yoga 3rd gen. i7-8650U up to 4.2 Ghz Turbo How can I debug/check that my CPU governor/frequency is scaling correcting under Qubes R4? So far, the only thing I've found is xentop/xl top that lists the CPU - as a never-changing 2.1 Ghz. Maybe this isn't the best way to measure CPU freq under dom0? All other tools seemed to want to use xfce4 tools, which seemed to only be specific to that fedora VM - and not the xen host. see `xenpm` eg. in dom0: sudo xenpm get-cpufreq-para /TL;DR I let Windows 10 register itself before wiping the disk and installing Qubes R4. Under Windows, Google Chrome benchmarked around 5300 pts with the online tool I was using. As a test, I also installed Arch Linux briefly to test Chrome performance, and it came in around 4500 pts. I chalk that up to not optimizing anything on the system - just a raw install and no tweaks. Now, under Qubes R4.0, I'm still noticing a lot of sluggishness/slowdowns just like my older Thinkpad Helix has always had under Qubes R3.2 (and one of the reasons why I waited for this quad core CPU to upgrade my Qubes install). I could never benchmark Chrome under that Helix dual-core low-powered device. It could be that the smt=off "fix" for L1TF causes you pain (see issues 4372 and 4252). Unplug your laptop from AC, open a VM, browse the web casually and check your power consumption - a recent laptop should be between 5 to 7 W on Qubes with light usage. If you see something >10W (like I did), try to re-enable smt - which is not really a good thing to do but that's that or throwing the laptop out of the window. Note: I haven't tested if recent kernels fixed the issue. I loaded up Chrome on a new debian-9 VM and... Almost the same extremely sluggish performance. Google Chrome can't even get partially through the benchmarks without timing out, much less finish them. I've tried assigning 4 and even 8 vcpus to try to max things out. You shouldn't configure more vcpus that cpus, that'll add overhead. I am wondering where to start to debug this. Is it a dom0 cpu scaling thing? Does Qubes impose some artificial throttling? Is it a lag in iGPU rendering through the DisplayVM? (this DisplayVM is a new concept to me, still trying to figure it out) DisplayVM ? AFAIK Qubes dev are working to isolate the gui stuff into a specific domain but I think it was planned for 4.1. Or maybe you meant dispVM ? If yes, disposable VMs in R4 are a bit different than R3.2 (way more flexible). I've spent about 3 days on this device with various other issues to get to this point (no S3 sleep yet, pixel-perfect scaling of the HDR 1440p 14" display, etc). I few duckduckgo searches hasn't turned anything up yet; so, i'll continue when I have some time. Good luck :) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/23b47a1f-d34b-7d9d-057b-1d71e343a0e7%40maa.bz. For more options, visit https://groups.google.com/d/optout.
[qubes-users] [R4.0] CPU Freq Scaling, or "Why am I stuck at 2.1 Ghz?"
Finally received my new Thinkpad X1 Yoga 3rd gen. i7-8650U up to 4.2 Ghz Turbo How can I debug/check that my CPU governor/frequency is scaling correcting under Qubes R4? So far, the only thing I've found is xentop/xl top that lists the CPU - as a never-changing 2.1 Ghz. Maybe this isn't the best way to measure CPU freq under dom0? All other tools seemed to want to use xfce4 tools, which seemed to only be specific to that fedora VM - and not the xen host. /TL;DR I let Windows 10 register itself before wiping the disk and installing Qubes R4. Under Windows, Google Chrome benchmarked around 5300 pts with the online tool I was using. As a test, I also installed Arch Linux briefly to test Chrome performance, and it came in around 4500 pts. I chalk that up to not optimizing anything on the system - just a raw install and no tweaks. Now, under Qubes R4.0, I'm still noticing a lot of sluggishness/slowdowns just like my older Thinkpad Helix has always had under Qubes R3.2 (and one of the reasons why I waited for this quad core CPU to upgrade my Qubes install). I could never benchmark Chrome under that Helix dual-core low-powered device. I loaded up Chrome on a new debian-9 VM and... Almost the same extremely sluggish performance. Google Chrome can't even get partially through the benchmarks without timing out, much less finish them. I've tried assigning 4 and even 8 vcpus to try to max things out. I am wondering where to start to debug this. Is it a dom0 cpu scaling thing? Does Qubes impose some artificial throttling? Is it a lag in iGPU rendering through the DisplayVM? (this DisplayVM is a new concept to me, still trying to figure it out) I've spent about 3 days on this device with various other issues to get to this point (no S3 sleep yet, pixel-perfect scaling of the HDR 1440p 14" display, etc). I few duckduckgo searches hasn't turned anything up yet; so, i'll continue when I have some time. Thanks! -E -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1bbc7347-95f0-4a72-bea5-2e58b40220c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
