base priority vs. dynamic priority (vista)

NTDEV
1

Hi all,

one of our customers is complaining that the dynamic priority of a
thread (of our driver) changes constantly downto 2 which is below the
threads base priority of 15 and also below idle priority.
He used the process explorer to observe the priority values.
He says that most of the time the dynamic priority value shows 26
(vista) and 15 (XP), but sometimes the priority dropps.
This issue leads to perfomance problems and is specific to vista (not
observed under XP).
The thread is part of the user mode .dll of my driver. I dont touch the
priority class, but I set the thread priority to

THREAD_PRIORITY_TIME_CRITICAL

This explains the value of 15 (priorty 8 before SetThreadPriority, 15
after SetThreadPriorty) under XP.
Under vista the priority sometimes seems to be even higher (26). I think
this is because of the MMCSS (new feature of vista).
But I have no explaination for the low values (2).

So is this possible, the dynamic priority of a thread falls below the
base priority of that thread. From how I understand the docs I would say no.
But the customer says that this happens on his machine.

Thanks,
/Uwe

2

I would agree that the docs do clearly state that the situation you describe (dynamic < base) should not be occurring, but I’m not
sure what to make of this without you personally verifying the situation as reported by the client. The other thing is that as you
noted, there are at least two new Vista features that might influence this, and it wouldn’t be the weirdest thing if the docs didn’t
reflect this, or perhaps they already do, just not consistently. Yet another is that I’m missing something important.

I would disable the ‘Multimedia Class Service’ and ‘Thread Ordering Service’ and see what happens.

What kind of driver is this?

Good luck,

mm

Uwe Kirst wrote:

Hi all,

one of our customers is complaining that the dynamic priority of a
thread (of our driver) changes constantly downto 2 which is below the
threads base priority of 15 and also below idle priority.
He used the process explorer to observe the priority values.
He says that most of the time the dynamic priority value shows 26
(vista) and 15 (XP), but sometimes the priority dropps.
This issue leads to perfomance problems and is specific to vista (not
observed under XP).
The thread is part of the user mode .dll of my driver. I dont touch the
priority class, but I set the thread priority to

THREAD_PRIORITY_TIME_CRITICAL

This explains the value of 15 (priorty 8 before SetThreadPriority, 15
after SetThreadPriorty) under XP.
Under vista the priority sometimes seems to be even higher (26). I think
this is because of the MMCSS (new feature of vista).
But I have no explaination for the low values (2).

So is this possible, the dynamic priority of a thread falls below the
base priority of that thread. From how I understand the docs I would say
no.
But the customer says that this happens on his machine.

Thanks,
/Uwe

3

Maybe this is the reason:

http://msdn.microsoft.com/en-us/library/ms684247(VS.85).aspx

Category Priority Description
High 23-26 These threads run at a thread priority that is only lower than certain system-level tasks. This category is
designed for pro audio and can theoretically use as much of the CPU resource as required.
Medium 16-22 These threads are part of the application that is in the foreground.
Low 8-15 This category contains the remainder of the threads. They are guaranteed a minimum percentage of the CPU resources
if required.
1-7 These threads have used their quota of CPU resource. They can continue to run if no low-priority threads are ready to run.

I don’t know anything about it really, but it does more or less fit the numbers, and it wouldn’t be the strangest thing ever if the
documentation for new technologies didn’t mesh with older documentation, nor if a service like this caused performance problems.

Good luck,

mm

Martin O’Brien wrote:

I would agree that the docs do clearly state that the situation you
describe (dynamic < base) should not be occurring, but I’m not sure what
to make of this without you personally verifying the situation as
reported by the client. The other thing is that as you noted, there are
at least two new Vista features that might influence this, and it
wouldn’t be the weirdest thing if the docs didn’t reflect this, or
perhaps they already do, just not consistently. Yet another is that I’m
missing something important.

I would disable the ‘Multimedia Class Service’ and ‘Thread Ordering
Service’ and see what happens.

What kind of driver is this?

Good luck,

mm

Uwe Kirst wrote:
> Hi all,
>
> one of our customers is complaining that the dynamic priority of a
> thread (of our driver) changes constantly downto 2 which is below the
> threads base priority of 15 and also below idle priority.
> He used the process explorer to observe the priority values.
> He says that most of the time the dynamic priority value shows 26
> (vista) and 15 (XP), but sometimes the priority dropps.
> This issue leads to perfomance problems and is specific to vista (not
> observed under XP).
> The thread is part of the user mode .dll of my driver. I dont touch
> the priority class, but I set the thread priority to
>
> THREAD_PRIORITY_TIME_CRITICAL
>
> This explains the value of 15 (priorty 8 before SetThreadPriority, 15
> after SetThreadPriorty) under XP.
> Under vista the priority sometimes seems to be even higher (26). I
> think this is because of the MMCSS (new feature of vista).
> But I have no explaination for the low values (2).
>
> So is this possible, the dynamic priority of a thread falls below the
> base priority of that thread. From how I understand the docs I would
> say no.
> But the customer says that this happens on his machine.
>
> Thanks,
> /Uwe
>
>

4

Uwe,

That does look like MMCSS behavior. MMCSS gives certain threads a real-time priority for up to 80% of a 10 ms interval and then drops their priority down to 2 for the remaining 20% (by default… this can be changed via a regkey).

Is your thread calling AvRtSetMmThreadCharacteristics or calling into a multimedia-esque library that could be doing so on your behalf? That’s the way you get MMCSS behavior, otherwise MMCSS has nothing to do with what you’re seeing. I own some of the tests for this code, and I’d be happy to discuss any specifics with you offline.

Thanks,
Neeraj

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of Martin O’Brien [xxxxx@evitechnology.com]
Sent: Tuesday, June 24, 2008 1:51 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] base priority vs. dynamic priority (vista)

Maybe this is the reason:

http://msdn.microsoft.com/en-us/library/ms684247(VS.85).aspx

Category Priority Description
High 23-26 These threads run at a thread priority that is only lower than certain system-level tasks. This category is
designed for pro audio and can theoretically use as much of the CPU resource as required.
Medium 16-22 These threads are part of the application that is in the foreground.
Low 8-15 This category contains the remainder of the threads. They are guaranteed a minimum percentage of the CPU resources
if required.
1-7 These threads have used their quota of CPU resource. They can continue to run if no low-priority threads are ready to run.

I don’t know anything about it really, but it does more or less fit the numbers, and it wouldn’t be the strangest thing ever if the
documentation for new technologies didn’t mesh with older documentation, nor if a service like this caused performance problems.

Good luck,

mm

Martin O’Brien wrote:

I would agree that the docs do clearly state that the situation you
describe (dynamic < base) should not be occurring, but I’m not sure what
to make of this without you personally verifying the situation as
reported by the client. The other thing is that as you noted, there are
at least two new Vista features that might influence this, and it
wouldn’t be the weirdest thing if the docs didn’t reflect this, or
perhaps they already do, just not consistently. Yet another is that I’m
missing something important.

I would disable the ‘Multimedia Class Service’ and ‘Thread Ordering
Service’ and see what happens.

What kind of driver is this?

Good luck,

mm

Uwe Kirst wrote:
> Hi all,
>
> one of our customers is complaining that the dynamic priority of a
> thread (of our driver) changes constantly downto 2 which is below the
> threads base priority of 15 and also below idle priority.
> He used the process explorer to observe the priority values.
> He says that most of the time the dynamic priority value shows 26
> (vista) and 15 (XP), but sometimes the priority dropps.
> This issue leads to perfomance problems and is specific to vista (not
> observed under XP).
> The thread is part of the user mode .dll of my driver. I dont touch
> the priority class, but I set the thread priority to
>
> THREAD_PRIORITY_TIME_CRITICAL
>
> This explains the value of 15 (priorty 8 before SetThreadPriority, 15
> after SetThreadPriorty) under XP.
> Under vista the priority sometimes seems to be even higher (26). I
> think this is because of the MMCSS (new feature of vista).
> But I have no explaination for the low values (2).
>
> So is this possible, the dynamic priority of a thread falls below the
> base priority of that thread. From how I understand the docs I would
> say no.
> But the customer says that this happens on his machine.
>
> Thanks,
> /Uwe
>
>

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

Hi all,

if I understand Neeraj correct, MMCSS boosts the prioirty of my thread
for about 8 ms, but afterwards the priority drops down for 2 ms.
From my understanding my thread should never come to the point where
the priority drops, because it is not running for more than 8 ms.
After some processing time there is a WaitForMultipleObjects function
called, which should reset the thread to high priority. It seems that in
practice this reset doesnt happen. So even if Im using small audio
buffersizes, the priority of my thread drops down.

In case I disable the MMCSS service, audio is running ok. So there seem
to be 3 cases:

-Do not support MMCSS in the driver - audio is worse
-Support MMCSS in the driver - audio is getting better
-Disable MMCSS service - audio is running perfect, like XP

Thanks,
/Uwe

Neeraj Singh schrieb:

Uwe,

That does look like MMCSS behavior. MMCSS gives certain threads a real-time priority for up to 80% of a 10 ms interval and then drops their priority down to 2 for the remaining 20% (by default… this can be changed via a regkey).

Is your thread calling AvRtSetMmThreadCharacteristics or calling into a multimedia-esque library that could be doing so on your behalf? That’s the way you get MMCSS behavior, otherwise MMCSS has nothing to do with what you’re seeing. I own some of the tests for this code, and I’d be happy to discuss any specifics with you offline.

Thanks,
Neeraj

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of Martin O’Brien [xxxxx@evitechnology.com]
Sent: Tuesday, June 24, 2008 1:51 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] base priority vs. dynamic priority (vista)

Maybe this is the reason:

http://msdn.microsoft.com/en-us/library/ms684247(VS.85).aspx

Category Priority Description
High 23-26 These threads run at a thread priority that is only lower than certain system-level tasks. This category is
designed for pro audio and can theoretically use as much of the CPU resource as required.
Medium 16-22 These threads are part of the application that is in the foreground.
Low 8-15 This category contains the remainder of the threads. They are guaranteed a minimum percentage of the CPU resources
if required.
1-7 These threads have used their quota of CPU resource. They can continue to run if no low-priority threads are ready to run.

I don’t know anything about it really, but it does more or less fit the numbers, and it wouldn’t be the strangest thing ever if the
documentation for new technologies didn’t mesh with older documentation, nor if a service like this caused performance problems.

Good luck,

mm

Martin O’Brien wrote:

> I would agree that the docs do clearly state that the situation you
> describe (dynamic < base) should not be occurring, but I’m not sure what
> to make of this without you personally verifying the situation as
> reported by the client. The other thing is that as you noted, there are
> at least two new Vista features that might influence this, and it
> wouldn’t be the weirdest thing if the docs didn’t reflect this, or
> perhaps they already do, just not consistently. Yet another is that I’m
> missing something important.
>
> I would disable the ‘Multimedia Class Service’ and ‘Thread Ordering
> Service’ and see what happens.
>
>
> What kind of driver is this?
>
>
> Good luck,
>
> mm
>
> Uwe Kirst wrote:
>
>> Hi all,
>>
>> one of our customers is complaining that the dynamic priority of a
>> thread (of our driver) changes constantly downto 2 which is below the
>> threads base priority of 15 and also below idle priority.
>> He used the process explorer to observe the priority values.
>> He says that most of the time the dynamic priority value shows 26
>> (vista) and 15 (XP), but sometimes the priority dropps.
>> This issue leads to perfomance problems and is specific to vista (not
>> observed under XP).
>> The thread is part of the user mode .dll of my driver. I dont touch
>> the priority class, but I set the thread priority to
>>
>> THREAD_PRIORITY_TIME_CRITICAL
>>
>> This explains the value of 15 (priorty 8 before SetThreadPriority, 15
>> after SetThreadPriorty) under XP.
>> Under vista the priority sometimes seems to be even higher (26). I
>> think this is because of the MMCSS (new feature of vista).
>> But I have no explaination for the low values (2).
>>
>> So is this possible, the dynamic priority of a thread falls below the
>> base priority of that thread. From how I understand the docs I would
>> say no.
>> But the customer says that this happens on his machine.
>>
>> Thanks,
>> /Uwe
>>
>>
>>

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer