WEBVTT

00:00:00.080 --> 00:00:06.839
so you've got all the best hardware CPU

00:00:03.240 --> 00:00:10.080
GPU ssds the good stuff but for some

00:00:06.839 --> 00:00:11.639
reason your rig is still slow despite

00:00:10.080 --> 00:00:17.199
having the best of the best you're experiencing noticeable stuttering and

00:00:14.000 --> 00:00:18.800
serious downtime well I'm no doctor but

00:00:17.199 --> 00:00:24.160
it's possible that your system is getting spammed by interrupt requests

00:00:21.800 --> 00:00:28.080
interrupt requests typically aren't a bad thing in fact they're essential to

00:00:26.160 --> 00:00:32.160
the basic momentto moment functioning of your computer sometimes in order order

00:00:30.160 --> 00:00:37.000
to take an action your system needs to ask the processor to interrupt code that

00:00:34.760 --> 00:00:41.520
is currently being executed if the processor accepts the request it pauses

00:00:39.399 --> 00:00:46.760
its activity saves its state and executes an interrupt Handler otherwise

00:00:44.120 --> 00:00:51.520
known as an interrupt service routine or ISR after the new task is finished the

00:00:49.640 --> 00:00:56.520
processor resumes the interrupted process but not just any task gets to

00:00:54.559 --> 00:01:01.160
burst in like the Kool-Aid man and demand to take Center Stage your

00:00:58.879 --> 00:01:06.720
computer runs BAS based on a strict hierarchy of priority essential urgent

00:01:04.199 --> 00:01:12.600
tasks come first and can interrupt any other task nonessential non-urgent tasks

00:01:09.960 --> 00:01:17.600
will either share available resources or wait in line for their turn handing over

00:01:14.840 --> 00:01:22.240
control when necessary to more important processes then there's tasks in the

00:01:19.920 --> 00:01:27.079
middle urgent enough to interrupt low priority tasks but not so urgent that

00:01:24.759 --> 00:01:31.240
they get actioned immediately over anything else we all know the feeling

00:01:29.759 --> 00:01:35.720
however however some critically important interrupt requests will come

00:01:33.320 --> 00:01:39.680
with a timeout counter that resets the system if it's unable to run its

00:01:37.280 --> 00:01:44.399
essential task before the time runs out while the system can decide when and if

00:01:42.240 --> 00:01:49.640
it will accept an interrupt request once that interrupt is accepted and its

00:01:46.399 --> 00:01:51.759
action is in progress the CPU or GPU

00:01:49.640 --> 00:01:55.759
servicing the request cannot be interacted with by the rest of the

00:01:53.399 --> 00:02:00.680
system most interrupts happen quickly and seamlessly but longer than usual

00:01:58.520 --> 00:02:05.039
interrupts or large large numbers of interrupt requests can cause stuttering

00:02:02.880 --> 00:02:10.080
or result in dropped packets and higher latency when networking longer than

00:02:07.600 --> 00:02:14.560
usual interrupts are often the result of misbehaving Hardware but some devices

00:02:12.440 --> 00:02:18.400
like Wi-Fi adapters flood the system with interrupt requests which increases

00:02:16.720 --> 00:02:22.599
the likelihood that part of the system will stall there are also times when

00:02:20.560 --> 00:02:27.680
bugs and glitches have caused the usually clear hierarchy of priority to

00:02:25.280 --> 00:02:32.599
get jumbled leading to perhaps the most severe consequence of interrupt requests

00:02:30.120 --> 00:02:37.640
a little thing called priority inversion or thrashing we'll explain what that is

00:02:35.680 --> 00:02:42.720
and how to avoid it after we say thanks to our sponsor Corsair Corsair custom

00:02:40.480 --> 00:02:47.280
lab allows you to create a gaming setup as unique as you are start with a

00:02:44.800 --> 00:02:51.560
product like their K65 plus wireless keyboard and select from a variety of

00:02:49.280 --> 00:02:56.440
different themed key caps to match your style from there you can add a mouse and

00:02:53.879 --> 00:03:00.120
a mouse pad to complete the look Corsair handles all the heavy lifting for you

00:02:58.360 --> 00:03:03.640
just make your Custom Creation and they'll build it and ship it right to

00:03:01.920 --> 00:03:08.680
you learn more at the link in the description priority inversion is a

00:03:06.319 --> 00:03:13.400
situation where the strict task priority hierarchy that allows a computer to make

00:03:10.519 --> 00:03:18.319
decisions is violated this can happen when a high priority and low priority

00:03:15.840 --> 00:03:22.560
task both need to use a resource that can only do one task at a time if the

00:03:20.400 --> 00:03:27.680
low priority task is running and it gets interrupted by a medium priority task

00:03:25.120 --> 00:03:31.640
that doesn't need the specific exclusive resource that it's using that might

00:03:29.400 --> 00:03:36.080
trigger a bug that causes the low priority task to refuse to relinquish

00:03:33.959 --> 00:03:40.400
its hold if the system then attempts to run a high priority task that requires

00:03:38.599 --> 00:03:45.360
that exclusive resource it will be inadvertently blocked by the interrupt

00:03:42.840 --> 00:03:50.280
instigated by the medium priority task this can then cause the system to stall

00:03:47.760 --> 00:03:56.319
and time out and it's exactly what happened to the sojer Rover on Mars in

00:03:53.360 --> 00:04:00.360
1997 the Rover's low priority weather data collection task required an

00:03:58.360 --> 00:04:05.000
exclusive lock on the Rover's information bus this task was then

00:04:02.720 --> 00:04:09.959
interrupted and paused by a long duration medium priority communication

00:04:07.400 --> 00:04:15.040
task which held that exclusive lock on the information bus in place this then

00:04:12.640 --> 00:04:20.079
inadvertently blocked a high priority task from servicing the information bus

00:04:17.720 --> 00:04:24.680
the Rover system would then time out and initiate a full system reset this

00:04:22.759 --> 00:04:30.600
happened four times and was only resolved by the most remote of remote

00:04:27.320 --> 00:04:32.720
debugging NASA used a double of sojer

00:04:30.600 --> 00:04:37.400
back on Earth to test a solution and then sent the patch to the robot on Mars

00:04:34.960 --> 00:04:42.919
resolving the issue while your computer is in many ways more sophisticated than

00:04:39.639 --> 00:04:45.199
a computer from 1997 even a cool robot

00:04:42.919 --> 00:04:48.639
space computer it's still vulnerable to the Slowdown that comes with your

00:04:46.680 --> 00:04:54.160
computer spending its valuable processing power deciding what to do

00:04:51.199 --> 00:04:57.360
rather than just doing it not to mention the errors that can happen when your

00:04:55.560 --> 00:05:02.320
machine is trying to juggle several tasks at once so if you have ad8 D like

00:05:00.360 --> 00:05:06.400
me and somebody just criticizes you for your indecisiveness and procrastination

00:05:04.720 --> 00:05:11.400
just tell them you're experiencing an unfortunate priority inversion and

00:05:08.600 --> 00:05:15.240
consequent thrashing it worked for me you know what else worked for me you

00:05:13.000 --> 00:05:18.199
watching this whole video thanks so much like the video if you liked it dislike

00:05:16.720 --> 00:05:21.360
it if you disliked it check out our other videos comment below with video

00:05:20.000 --> 00:05:25.199
suggestions and don't forget to subscribe and follow after you get

00:05:23.120 --> 00:05:29.800
through the the Quee of things that you have to think about before and then do

00:05:27.160 --> 00:05:29.800
it