WEBVTT 00:00:00.000 --> 00:00:07.830 many serious game streamers use a second PC actually so they got one for gaming 00:00:05.609 --> 00:00:11.910 and then another one dedicated to encoding and interacting with their 00:00:09.719 --> 00:00:15.420 audience so we were brainstorming and talking about some cool projects that 00:00:13.590 --> 00:00:20.689 we've done in the past with unread and virtualization technology and well let's 00:00:18.510 --> 00:00:26.970 just say the old light bulb went off what if we could build using an Intel 00:00:24.240 --> 00:00:32.390 high core count core I nine processor a two-in-one solution splitting a single 00:00:30.510 --> 00:00:37.100 Tower with a single motherboard effectively in half to perform both of 00:00:35.670 --> 00:00:42.660 those duties virtually of course would we end up with 00:00:40.410 --> 00:00:51.770 a viable day-to-day streaming solution well thanks to Intel sponsorship of this 00:00:46.280 --> 00:00:56.759 investigation we are about to find out 00:00:59.380 --> 00:01:06.740 okay so let's start with this why would anyone want to run a virtualized 00:01:04.610 --> 00:01:12.170 two-in-one setup as opposed to just having two separate machines I mean bare 00:01:09.140 --> 00:01:14.000 metals more efficient right let's take a 00:01:12.170 --> 00:01:20.810 look at a few reasons why it might actually be a cool idea first and most 00:01:17.050 --> 00:01:23.270 importantly for many is cost unless you 00:01:20.810 --> 00:01:30.590 already have a second computer to dedicate to encoding you would still 00:01:25.760 --> 00:01:33.170 have to buy GPU RAM and storage for two 00:01:30.590 --> 00:01:38.240 but you could save the considerable expense of many other components in 00:01:35.570 --> 00:01:43.220 addition your total power consumption and heat output will be a touch lower 00:01:40.850 --> 00:01:49.640 than running separate PCs meaning your energy bill will be lower - the second 00:01:46.160 --> 00:01:51.229 reason to go virtual is space while it's 00:01:49.640 --> 00:01:55.729 not a concern for some if you're streaming from a college dorm or a small 00:01:53.390 --> 00:02:00.170 apartment this means one less tower taking up space in your gaming area not 00:01:58.369 --> 00:02:06.229 every virtualized - and one has to be this big reason number three versatility 00:02:03.770 --> 00:02:11.750 since the gaming and streaming setups are virtualized not only are any 00:02:08.899 --> 00:02:17.690 potential software issues confined to each VM but they can also be much more 00:02:14.660 --> 00:02:19.940 quickly and easily backed up or cloned 00:02:17.690 --> 00:02:25.069 once you're set up so in the future you can easily hit the reset button in case 00:02:22.580 --> 00:02:30.020 anything should go wrong also thanks to the magic of on raid your gaming / 00:02:27.260 --> 00:02:34.459 streaming machine can act as a file and media server for the rest of your 00:02:31.550 --> 00:02:39.920 household so the plan then is to use a portion of our CPU to encode our video 00:02:37.670 --> 00:02:44.600 stream using x264 with high quality settings that way we can avoid the 00:02:42.530 --> 00:02:48.980 potential for scheduler conflicts without manually assigning CPU 00:02:46.880 --> 00:02:54.590 affinities and task manager like we would if we were doing both tasks on one 00:02:51.530 --> 00:02:56.630 OS well okay Linus this all sounds great 00:02:54.590 --> 00:03:02.450 but there's got to be disadvantages right well there is the fact that when 00:02:59.930 --> 00:03:08.020 using virtualization some devices can't be easily allocated to a VM our onboard 00:03:05.450 --> 00:03:13.960 audio for example shares an eye a new group with the chipset and essentially 00:03:10.390 --> 00:03:16.480 cannot be used same story with USB ports 00:03:13.960 --> 00:03:21.130 each grouping of ports has to be on a dedicated controller in order to pass it 00:03:19.150 --> 00:03:25.350 through so that you can hot plug your devices something that we pretty much 00:03:22.900 --> 00:03:31.780 take for granted these days and finally while it's possible to run on 00:03:28.690 --> 00:03:34.090 raid without its own video card it's a 00:03:31.780 --> 00:03:38.950 royal pain so we grabbed a dedicated sound card for our gaming VM and extra 00:03:36.640 --> 00:03:44.820 USB controller we're using one of the onboard ones for the other VM and an el 00:03:41.800 --> 00:03:50.110 cheapo third graphics card for under 8 00:03:44.820 --> 00:03:52.030 so we are ready to you oh wait so during 00:03:50.110 --> 00:03:57.340 our testing we found that gaming performance was actually best when we 00:03:54.670 --> 00:04:02.530 assigned four cores and eight threads to our gaming VM and in some configurations 00:03:59.560 --> 00:04:07.660 we actually found tests that performed better in a virtualized environment 00:04:05.350 --> 00:04:12.430 compared to an equivalent configuration running on bare metal Y so this is the 00:04:11.080 --> 00:04:16.630 kind of thing that we encounter sometimes when we're running on the 00:04:14.560 --> 00:04:19.900 bleeding edge we spoke with on raids developers about the issue and they're 00:04:18.280 --> 00:04:24.370 putting together some information to share with the Red Hat and KVM 00:04:22.090 --> 00:04:27.970 hypervisor folks so that hopefully we'll see a resolution by the time game's 00:04:26.350 --> 00:04:32.440 demand more cores for optimal performance but for the time being our 00:04:30.100 --> 00:04:38.320 classic four core eight thread setup manages a negligible performance hit 00:04:35.230 --> 00:04:40.990 compared to bare metal and our streaming 00:04:38.320 --> 00:04:46.300 VM can suck up those extra cores anyway so that it could be used for heavier 00:04:43.480 --> 00:04:50.590 video editing and faster encoding for those edited videos that can later be 00:04:48.280 --> 00:04:55.030 uploaded to YouTube or other video on-demand sites alright then so let's 00:04:53.290 --> 00:05:00.400 show off the rest of the setup we're using the utterly unique level one text 00:04:57.460 --> 00:05:05.470 DisplayPort 1.2 KVM from Wendell and his team this gives us support for high 00:05:02.560 --> 00:05:12.310 refresh rate monitors like a Seuss's 240 hertz rog swift PG 2 v 8 q and easy 00:05:09.610 --> 00:05:15.970 switching between our VMs saving us from using two keyboards and mice though it 00:05:14.410 --> 00:05:21.809 should be noted that having an extra one on hand is pretty useful in some cases 00:05:18.510 --> 00:05:24.479 we're using Corsairs massive obsidian 00:05:21.809 --> 00:05:31.439 900 D tower thanks to its ample cooling capacity and we're powering all three of 00:05:27.659 --> 00:05:34.649 our GPUs the 1080 Ti for gaming the 1050 00:05:31.439 --> 00:05:37.289 Ti for streaming and that basic one for 00:05:34.649 --> 00:05:44.159 unrated off of an ax 1200 eye power supply and we've thrown in a monstrous 00:05:40.439 --> 00:05:48.300 on raid array of 712 terabyte Seagate 00:05:44.159 --> 00:05:50.580 iron wolf pro drives for 60 terabytes of 00:05:48.300 --> 00:05:55.169 protected storage that's visible to both VMs not to mention as I said before 00:05:52.889 --> 00:05:59.849 anyone else on the network who needs it allowing us to record our streams 00:05:57.110 --> 00:06:03.289 basically indefinitely so we can make them epic frag vids after we're done 00:06:02.189 --> 00:06:09.899 streaming finally for our capture Carlo and other 00:06:06.809 --> 00:06:12.330 surprise no capture card so we actually 00:06:09.899 --> 00:06:19.019 originally had planned to use one that 4k one from El Gato but this ended up 00:06:16.379 --> 00:06:25.649 being way cooler so our gaming VM is actually transmitting its video and 00:06:21.959 --> 00:06:29.399 audio feed to the encoder VM using the 00:06:25.649 --> 00:06:32.519 low impact OBS NDI plugin which runs 00:06:29.399 --> 00:06:34.769 with very little quality loss over our 00:06:32.519 --> 00:06:39.749 virtualized 10 gigabit network connection between our VMs then from 00:06:37.769 --> 00:06:46.139 there we've set the streaming machines output settings to Twitch's ultimate 00:06:42.149 --> 00:06:48.360 1080p 60fps quality setting and would 00:06:46.139 --> 00:06:54.300 you look at that after a few command-line tweaks we could not only 00:06:50.550 --> 00:06:57.569 encode on the fly but do so at x264 00:06:54.300 --> 00:06:59.819 s-slow preset which is 6 notches up from 00:06:57.569 --> 00:07:04.860 the default potato quality ultra-fast and 00:07:00.829 --> 00:07:07.889 to validate our original hypothesis is 00:07:04.860 --> 00:07:11.729 there some benefit from separating them 00:07:07.889 --> 00:07:14.519 in VMs we pushed our 11 hyper threaded 00:07:11.729 --> 00:07:20.550 cores to their limit in the streaming vm to the point where we forced our encoded 00:07:17.789 --> 00:07:24.689 video to start dropping frames then we went back to the gaming vm to see if 00:07:22.769 --> 00:07:28.889 those resources were effectively being isolated and it was still running games 00:07:26.999 --> 00:07:34.060 like nobody's business so what have we learned then on this 00:07:31.000 --> 00:07:36.370 journey well for one a virtualized dual 00:07:34.060 --> 00:07:41.169 head system with all of its shortcomings has some advantages operating our two 00:07:39.220 --> 00:07:45.639 virtual machines was about as transparent as running two completely 00:07:43.060 --> 00:07:50.350 independent systems whether via KVM switch or with two full sets of 00:07:47.710 --> 00:07:54.639 peripherals this is a use case for many course systems that we've been excited 00:07:52.240 --> 00:07:58.900 about for years now and one that has many applications beyond game streaming 00:07:57.130 --> 00:08:06.010 that is just gonna get better in time and second is that with superior codecs 00:08:02.919 --> 00:08:07.810 such as x265 on the horizon that are 00:08:06.010 --> 00:08:13.630 better optimized not only for image quality but for better thread and memory 00:08:10.780 --> 00:08:17.680 utilization that happens to mesh great with core I nines new cache design 00:08:15.160 --> 00:08:21.910 you'll be able to push the quality even higher with a setup like this all we 00:08:20.139 --> 00:08:26.500 need to do then is wait for twitch and mainstream broadcasting software to 00:08:24.160 --> 00:08:32.680 support it in the meantime though we've still built one of the coolest x264 00:08:29.680 --> 00:08:36.460 streaming setups out there so thanks to everyone for their help with this and 00:08:34.390 --> 00:08:41.560 especially Intel for sponsoring this sick experiment and also you guys for 00:08:39.310 --> 00:08:44.980 watching it so if you guys dislike this video you can hit that button but if you 00:08:42.969 --> 00:08:48.460 liked it hit like yet subscribe maybe consider checking out where to buy the 00:08:46.510 --> 00:08:52.450 stuff we featured at the link in the video description maybe a shiny new core 00:08:50.320 --> 00:08:55.839 I 9 also link down there is our merch storage has cool shirts like this one 00:08:53.860 --> 00:08:58.350 and our community forum which you should totally join