Why the startup of a new application causes system stuttering

Question

All modern operating system are supports multitasking. So, each running app would get a certain amount of time slice from cpu for their operation(depending on their demand).

The questions is, if the time slice is always calculated(which is, I guess) then why one app can stagnate the whole OS( or the machine).

Say, I am playing a sound track using VLC player. Then I run NetBeans(an IDE). Then sound from VLC player starts stuttering(and it continues until NetBeans becomes completely responsive). But, VLC player always should have its time slice intact, right? or it is just reallocating new time slice for new software that makes the drop of required slice for an already running app?

Answer 1

Why the startup of a new application causes system stuttering

Then sound from VLC player starts stuttering

You've only provided one example of "stuttering", and it's not the system that stutters, but an application program that is sensitive to I/O latency. In a nutshell, your system has hit a limit for its I/O bandwidth.

So, each running app would get a certain amount of time slice from cpu for their operation(depending on their demand)

Maybe, or maybe not. The OS scheduler may use timeslices to allocate CPU time for each process, or a prioritized preemptive scheme may be utilized. Or if cooperative scheduling is used, a process may be allowed to hog the CPU until it relinquishes control. A "modern operating system" will offer system and application programmers many options to tailor scheduling.

But let's assume a round-robin timeslicing scheduling is used in your example. The VLC player should be categorized as an I/O-intensive program, as opposed to a CPU-intensive. Essentially the VLC player is repeatedly

• reading data (from a disk file)
• writing the data (to the audio device)

The VLC player does not utilize its time slice for intensive computations, but mostly to perform an input or output operation, and is then suspended until that I/O operation completes. Depending on the OS scheduler, the unused portion of the timeslice might be credited back to the process for an extra long timeslice the next go-around, or the process loses it, or the process gets to jump to the head of the ready queue as soon as the I/O completes. What happens exactly will depend on how the OS scheduler is implemented. For instance, the Linux kernel can be built to use one of several schedulers, each with different "fairness" characteristics for different types of processes.

Then when you start NetBeans, you initiate a flurry of disk reads to locate and load application code and shared libraries. Most likely this additional disk activity is intermixed with the VLC player requests, and causing each read for VLC to take longer than the acceptable latency, so the audio device is starved for data and hence the audible "stuttering".

Unfortunately schedulers tend to focus on allocating CPU resources, and have difficulty (or avoid dealing) with unpredictable I/O issues. You could try a faster disk drive, and/or locating the audio file on a drive different from the OS + programs drive.

Your issue is related to realtime and near-realtime systems, which deal with reliable and quick/predictable responses to events. Playback of video and audio do not tolerate variable I/O latency, and have some characteristics of near-realtime systems. Players should incorporate techniques used in near-realtime systems if the OS has capabilities such as process priorities.

Networking has been responsive to handling low-latency traffic versus ordinary traffic, since it had to solve this issue for VoIP. Something similar is needed for mass storage systems.

Answer 2

How can an operating system give the same amount of CPU to an application that is the only one trying to run as it gives that application when 18 other ones are trying to run? The only way is it gives the application only a small fraction of the available resources, even when it's the only one. That obviously would be a disaster.

When the system has to run two applications, to a first approximation, for each resource they both wish to consume, half the available resources are available to each application. If they both want a lot of memory, they'll each get half. If they both want a lot of disk I/Os, they'll each get half. If they both want a lot of CPU time, they'll each get half. More or less.

If it's three application, they can't all get more than 1/3.

How schedulers handle CPU time varies. But as a simple example for a single-core system, it works like this: If there's only one ready-to-run task, that task starts a new timeslice a soon as it finishes a timeslice. If there are two ready-to-run tasks, they alternate timeslices.

In practice, it's a lot more complicated. For example, if a task doesn't use up its full timeslice, it often gets a priority boost. The same may apply if a task is interrupted by system I/O. In practice, this tends to make the system more response. (Imagine you're staring at a web page for a long time and then you click a button. Because your browser was being nice and yielding the CPU while you read, when it suddenly needs the CPU, it's rewarded for being nice and to improve the interactivity.)