Simple question:

How is the SQL Server Quantum (4 ms) synchronised with the Server OS Quantum (normally: 187.5 ms)?

Deep Dive

In the next couple of sections I'll write up what I have found so far regarding the OS quantum and how the duration of a quantum can be calculated. The duration of an OS "quantum" is based on "ticks" and the duration of the "tick" itself is based on the "clock interval" which is normally 15.625000 ms. But let me elaborate a bit...

Tick

In the Blog article Know Thy Tick the author Jim explains the basics of clock intervals (aka "ticks") and what they are for.

When I read something like “the clock interval… for most x86 multiprocessors is about 15 milliseconds” I’m compelled to determine the value of my clock, or “tick”, interval. Fortunately, the book I read this quote in, Windows Internals Fourth Edition provides a reference for helping me with my affliction.
...
The author, Mark Russinovich, of the aforementioned book has graciously made the utility ClockRes available on his web site. Running this utility, I was able to determine that the clock interval on my x86 multiprocessor PC is 15.625000 ms. Interesting, but my curious mind wants to know more.

Quantum

The author of the article goes on to explain in his second article that...

Of course the real reason why the tick interval is important is that it affects thread scheduling. The Windows scheduler gives each thread a “quantum” of time to execute before allowing another task, at the same priority level, to run. The quantum that the scheduler assigns to a thread is a multiple of the tick interval. The specific quantum value chosen for a specific thread is bit beyond where I want to go with this article.

Ok, so I know what a quantum is, but not how long a quantum will run.

For now, let’s just examine the default quantum value for a foreground thread in XPe. In this case the Windows scheduler assigns a quantum of 18 or 6 tick intervals. (Yes, to convert quantum to tick intervals, one must divide by 3. ..., but the reason for the multiple is to allow the scheduler the ability to “charge” a thread for doing an operation which causes it to suspend.)

We now know that a clock interval (tick) should be around 15.625000 ms and on a Windows Desktop OS where the default quantum is 18 that this will result in 6 ticks or 93.750000 ms (18 / 3 * 15.625000 ms).

On a Windows Server OS the default quantum is different. The "Processor scheduling" setting is set to "Background Services"

^{This setting can be found via "System Settings | Advanced (tab) | Performance (section) | Settings ..." which will open "Perofrmance Options | Advanced (tab) | Processor scheduling"}

The default quantum settings are then 36 (Background) to 36 (Foreground). The quantum is larger and hence longer. This is double the amount of the 93.750000 ms of the 18 (6 tick) quantum foreground setting on a Windows Desktop OS, which on a server OS set up for Background Services is around 187.500000 ms.

Observation / Explanation

When you change the setting from "Background services" to "Applicaitons" on either a server or desktop, then the HKLMSYSTEM CurrentControlSet Control PriorityControl Win32PrioritySeparation key in the registry is changed from 0x18 to 0x02. What is the default quantum value for 0x02? This can be found in a comment:

The value 0x02 implies that the "Short vs. Long" and "Variable vs. Fixed" fields are the default for the OS.

The default for these fields for XPe & XP Pro is: Short & Variable which is the same as having the following bits additional bits set: 0x24.

OR'ing this value in with 0x02 gives you 0x26, which you will find in the table in the article.

^{Reference: Comment to "Master Your Quantum" (MSDN Blogs)}

The table explaining the quantum settings from the same article:

Win32PrioritySeparation Foreground Background
0x28, 0x29, 0x2A 18 18
0x18, 0x19, 0x1A 36 36
0x24 6 6
0x25, 0x14 12 6
0x26 18 6
0x15 24 6
0x16 36 6

Short Summary of OS Quantum

Based on the above information and article quotes, we know that a quantum is not a fixed size, but rather derived from an OS setting in the System Properties. A quantum varies depending on the Win32PrioritySeparation setting in the registry which normally corresponds to one of the setting in the "System Properties" (either "Background services" or "Applications").

A quantum at OS level is

• for the "Applications" setting
  
  
  • 18 (which is 6 ticks) for foreground applications (93.75 ms)
  
  
  • 6 (which is 2 ticks) for background applications (31.25 ms)
  
  


• for the "Background Services" setting
  
  
  • 36 (which is 18 ticks) for foreground applications (187.5 ms)
  
  
  • 36 (which is 18 ticks) for background applications (187.5 ms)
  
  

So now we know that an OS quantum on a Windows Server setup to be optimised for Background Services is ...

36 / 3 * 15.625000 ms = 187.5 ms

My Conundrum

The Server OS Quantum regulates how much time the SQL Server Service is granted to execute "tasks". The SQL Server OS Quantum is defined as 4 ms. If I divide the 187.5 ms by 4 ms then I am left with 3.5 ms.

And we haven't even started the discussion of when the Clock Interval is set to something other than the default of 15.625000 ms....

Simple Question

How is the SQL Server Quantum (4 ms) synchronised with the Server OS Quantum (normally: 187.5 ms)?

I'm not an expert in this, so please take my interpretation with a grain of salt.

There's an old article here that describes thread management under the SQLOS. A relevant section is copied here:

If UMS is to handle SQL Server's scheduling needs rather than allowing
Windows to do so, UMS must somehow prevent the OS from doing what it
does with every other process: schedule threads on and off the
system's processor(s) as it sees fit. How do you do that in a
preemptive OS? UMS pulls this off through some clever tricks with
Windows event objects. Each thread under UMS has an associated event
object. For purposes of scheduling, Windows ignores threads it does
not consider viable—threads that cannot run because they are in an
infinite wait state. Knowing this, UMS puts threads to sleep that it
does not want to be scheduled by having them call WaitForSingleObject
on their corresponding event object and passing INFINITE for the
timeout value. When a thread calls WaitForSingleObject to wait on an
object and passes INFINITE for the timeout value, the only way to
awaken the thread is for the object to be signaled. When UMS wants a
given thread to run, it signals the thread's corresponding event
object. This allows the thread to come out of its wait state and
permits Windows to schedule it to run on a processor.

So if I understand correctly, threads are brought out of a sleep state by the SQLOS and allowed to run until they encounter a wait or reach their 4ms quantum, after which they are put back into a sleep state. In this manner they will never reach the full Windows quantum, and there is no remainder time slice to account for.

I'm not sure what you mean by "the SQL Server Quantum (4 ms)".

The notion of a "quantum" doesn't really apply inside SQL Server. SQL Server uses a cooperative user-mode task scheduler, and tasks are expected to yield frequently, placing themselves on the runable queue of the scheduler.