Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

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

Don_Burn_1Don_Burn_1 Member Posts: 4,311
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" <xxxxx@rediffmail.com> 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

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,914
    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.

    Tim Roberts, [email protected]
    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
  • Pavel_APavel_A Member Posts: 2,660
    <xxxxx@Rediffmail.com> 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
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,305
    On Tue, Oct 5, 2010 at 3:31 AM, <xxxxx@rediffmail.com> 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
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,305
    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, <xxxxx@rediffmail.com> 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
    >
  • Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
    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
  • Alex_GrigAlex_Grig Member Posts: 3,238
    "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.
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,914
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • J._J._FarrellJ._J._Farrell Member Posts: 200
    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?
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space