signal_wait_time_ms > wait_time_ms for SOS_SCHEDULER_YIELD in sys.dm_os_wait_stats Question regarding SOS_SCHEDULER_YIELD when using sys.dm_os_wait_stats:
Should signal_wait_time_ms not be exactly the same as wait_time_ms for the SOS_SCHEDULER_YIELD wait type?
For other wait types signal wait is when a worker thread is waiting in the Runnable Queue on the scheduler. Therefore I conclude that signal wait should be the same as total wait time (= wait_time_ms) for SOS_SCHEDULER_YIELD when looking at sys.dm_os_wait_stats.
So my problem is that the two columns mentioned should have the same value in this DMV for this particular wait type.
More specifically, I am looking at a case where signal_wait_time_ms is larger than wait_time_ms, and I would like an explanation for that difference.
The example I am looking at is from the book &quot;Pro SQL Server 2019 wait Statistics&quot; by Van de Laar. In a screenshot on page 120, signal wait is higher for SOS_SCHEDULER_YIELD.
From the documentation for sys.dm_os_wait_stats (emphasis mine):




Column name
Data type
Description




...
...
...


wait_time_ms
bigint
Total wait time for this wait type in milliseconds. This time is inclusive of signal_wait_time_ms.




If you see signal_wait_time_ms higher than wait_time_ms, then per the current documentation, that is a bug.  You should report it to Microsoft if it's causing you problems so they can investigate where things got off track.  It could be rounding errors in the underlying data that lead to a slight difference (you didn't mention how far off the two values were).
You said this:

the example I am looking at is from the book &quot;Pro SQL Server 2019 wait Statistics&quot; by Van de Laar. In a screenshot on page 120 signal wait is higher for SOS_SCHEDULER_YIELD.

Since the example is from a screenshot in a book, it's quite possible that editorial processes resulted in invalid information making it into the final published result.  In that case, I wouldn't worry about it too much.  You could contact the author to see if it's possible or likely that something happened like that (maybe they were splicing screenshots from multiple tests together for simplicity).