Re: Changing 'Base Priority' of Windows Standard USB driver (usbser.sys)

No it is not possible. A driver is not a program with all dedicated
threads, it is a component that runs on threads from the requesting
application and from the system. There is no way to up the priority
here.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Ashutosh Deshpande” wrote in
message news:xxxxx@ntdev:

> Hi,
>
>
> I am exploring the possibility of changing default ‘Base Priority’ of Windows Standard USB driver (usbser.sys) from user / kernel space using some tool / utility / via program (using some API) / via windows registry.
>
> Do you think that this thing is possible?
>
>
>
> -Thanks,
> Ashutosh D

Ashutosh Deshpande wrote:

I am exploring the possibility of changing default ‘Base Priority’ of
Windows Standard USB driver (usbser.sys) from user / kernel space
using some tool / utility / via program (using some API) / via windows
registry.

Do you think that this thing is possible?

No. Drivers do not have a priority.

Since this not something that would have occurred to you out of the
blue, you must have thought of this as a possible solution to some
larger problem. Tell us what overall problem is, and we can help you
find a REAL solution. This is not it.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hi Don, Tim, Chris,

First of all, Thanks a lot for the reply!

I am working on serial port based device (which is interfaced with PC via USB hub), where I want to achieve response targets of 5 - 7 ms. For this purpose, I am planning to use standard usbser.sys driver.

So, after studying WDF and KMDF architectures I realiased that only by changing thread priority of my user-mode reader thread might not be sufficient, as actual usbhub and usbser drivers down in kernel also should run at higher priority level (>= 15, may be). Of course, dynamic priority boosting that scheduler does upon completion of an I/O request might help, but to achieve ‘guarenteed’ latency I was planning to experiment with adjusting the ‘base priorities’ of usb drivers at kernel level.

[Note- I used Process Exploerer tool and could see that USBPORT.sys threads under System process run at ‘base priority’ of 8 (normal).]

I am not familiar with earlier WDM architecture based windows drivers. But, I think WDF framework internally would be either creating some kernel-mode threads or may be some on-event work-items for each driver and from within their context WDF would be calling the registered driver callbacks.

I think it would be the same set of threads that Process Exploer showed under System process to me. So, that made me think, if there is a way to adjust these ‘base priority’ values somehow.

I came across ‘ZwSetInformationThread’ and ‘KeSetBasePriorityThread’ APIs. These APIs need thread-handle as input, which we may possibly get using ‘Process’ and ‘Thread’ classes from System.dll (System.Diagnostics namespace).

Does this seem feasible at all?

Thanks in advance,
Ashutosh D

wrote in message news:xxxxx@ntdev…
> Hi Don, Tim, Chris,
>
> First of all, Thanks a lot for the reply!
>
> I am working on serial port based device (which is interfaced with PC via
> USB hub), where I want to achieve response targets of 5 - 7 ms. For this
> purpose, I am planning to use standard usbser.sys driver.
>
> So, after studying WDF and KMDF architectures I realiased that only by
> changing thread priority of my user-mode reader thread might not be
> sufficient, as actual usbhub and usbser drivers down in kernel also should
> run at higher priority level (>= 15, may be). Of course, dynamic priority
> boosting that scheduler does upon completion of an I/O request might help,
> but to achieve ‘guarenteed’ latency I was planning to experiment with
> adjusting the ‘base priorities’ of usb drivers at kernel level.
>
> [Note- I used Process Exploerer tool and could see that USBPORT.sys
> threads under System process run at ‘base priority’ of 8 (normal).]
>
> I am not familiar with earlier WDM architecture based windows drivers.
> But, I think WDF framework internally would be either creating some
> kernel-mode threads or may be some on-event work-items for each driver and
> from within their context WDF would be calling the registered driver
> callbacks.
>
> I think it would be the same set of threads that Process Exploer showed
> under System process to me. So, that made me think, if there is a way to
> adjust these ‘base priority’ values somehow.
>
> I came across ‘ZwSetInformationThread’ and ‘KeSetBasePriorityThread’ APIs.
> These APIs need thread-handle as input, which we may possibly get using
> ‘Process’ and ‘Thread’ classes from System.dll (System.Diagnostics
> namespace).
>
> Does this seem feasible at all?
>
> Thanks in advance,
> Ashutosh D
>

So your concern is the latency added by the usb to serial conversion.

Forget about the thread priorities, the Windows usually is good enough
in scheduling ( assuming a modern fast machine and no misbehaving
apps running on raised priorities, or drivers hanging in their DPCs).

Do you use some off-the-shelf adapter or the USB device is your own?

–pa

On Tue, Oct 5, 2010 at 3:31 AM, wrote:
> I came across ‘ZwSetInformationThread’ and ‘KeSetBasePriorityThread’ APIs. These APIs need thread-handle as input, which we may possibly get using ‘Process’ and ‘Thread’ classes from System.dll (System.Diagnostics namespace).
>
So you intend to raise the priority of all system process threads to
15? Or just a select few based on some undefined criteria that makes
them usber.sys threads?

“You’re lost in a maze of twisty passages, all alike”

Find another approach.

Mark Roddy
Not as “valuable” as he used to be.

Hi Pavel,
Response target for me is 5 - 7 ms, which is a concern and that us why I am trying to be proactive here. Do you think, this much latency would be achievable on a good fast machine ?

We are using a custom designed USB-to-Serial converter adapter.

Hi Mark,
Yeah, I am evaluating a possibility to raise priorities of usbser.sys related threads only. I am not very sure about this though.

May be you can suggest some alternate approach.

  • Ashutosh

I have no idea how you are going to identify these “usbser.sys”
related threads either, which is why I suggested you abandon this
approach.

As you do not appear to have a driver in this design - you are using
usbser.sys - all of the performance tuning you can do is going to be
in your application.

Mark Roddy

On Tue, Oct 5, 2010 at 9:09 AM, wrote:
> Hi Pavel,
> Response target for me is 5 - 7 ms, which is a concern and that us why I am trying to be proactive here. Do you think, this much latency would be achievable on a good fast machine ?
>
> We are using a custom designed USB-to-Serial converter adapter.
>
> Hi Mark,
> Yeah, I am evaluating a possibility to raise priorities of usbser.sys related threads only. I am not very sure about this though.
>
> May be you can suggest some alternate approach.
>
> - Ashutosh
>
>
> —
> 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
>

Windows is not a Real Time Operating System. If you need real-time
performance then you need a RTOS. If you need to make your application
run on Windows, you need to make your design not to require real time
operation.


Aram Hăvărneanu

“Response target for me is 5 - 7 ms, which is a concern and that us why I am
trying to be proactive here.”

There is no hard guarantee, but normally, the latencies can be made less than that. If you need usermode responsiveness, increase your app thread priorities.

USB host mostly operates at DISPATCH_LEVEL. This means it’s not subject to thread priorities.

xxxxx@Rediffmail.com wrote:

First of all, Thanks a lot for the reply!

I am working on serial port based device (which is interfaced with PC via USB hub), where I want to achieve response targets of 5 - 7 ms. For this purpose, I am planning to use standard usbser.sys driver.

What, exactly, do you mean by “response targets of 5 - 7 ms”? Do you
mean that you want an application to be running within 5 ms of the
receipt of a character?

Have you tried any of this yet? Do you even know if you have a
problem? If not, why are you exploring these strange options?

… Of course, dynamic priority boosting that scheduler does upon completion of an I/O request might help, but to achieve ‘guarenteed’ latency I was planning to experiment with adjusting the ‘base priorities’ of usb drivers at kernel level.

Drivers do not have base priorities. What you are saying is akin to
saying “I’d like my DLL to have a higher priority”. It doesn’t make
sense. Processes and threads have priorities. Drivers respond to
events. Those events occur on whatever thread happened to be running
when the event occurred.

The USB host controller will fire an interrupt when a frame is completed
(every millisecond). The host controller driver will notice that the
usbser.sys transfer has been completed, and will complete its IRP.
Usbser.sys will then complete the user-mode request that triggered the
read. That changes the user mode thread from blocked to ready-to-run.
However, the thread still has to be chosen for scheduling.

Also, you seem to be under the common but mistaken impression that
increasing a thread’s priority makes it run faster. The higher the
priority, the faster it runs. That, of course, just silly.

Does this seem feasible at all?

Not as you have described it. USB serial ports are even LESS real-time
than traditional wired serial ports, because you have the added overhead
of USB involved.

Windows does not guarantee latency and response time under AND
circumstances. If equipment damage or personal injury results from
missing your response time goals, then in all seriousness you need to
abandon Windows right now and go find a real-time operating system.

However, it’s quite likely that you’ll achieve your targets most of the
time without too much difficulty.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

xxxxx@Rediffmail.com wrote:

I am working on serial port based device (which is interfaced with PC via USB hub), where I want to achieve response targets of 5 - 7 ms. For this purpose, I am planning to use standard usbser.sys driver.

So what response times are you currently seeing, what have you done so
far to reduce them, and what has that achieved?

On 10/05/2010 06:44 PM, Tim Roberts wrote in respose to Ashutosh:

Windows does not guarantee latency and response time under AND
circumstances. If equipment damage or personal injury results from
missing your response time goals, then in all seriousness you need to
abandon Windows right now and go find a real-time operating system.

+1

Ashutosh: How about delegating any time-critical task to an embedded
system that e.g. in turn communicates with Windows? Microcontrollers may
not be fast but they can easily provide a guaranteed response time.

Yes, you would essentially build your own USB-to-serial converter. But
with added “intelligence” to respond in time to a time-critical input.

What is your *real* problem? Is it really crucial to respond within 7 ms
to an input, or are you just afraid that you wil lose data if you don’t
respond fast enough? The latter is no problem - the USB system and the
USB/serial converter will buffer some data.