Persistent data acquisition via usb RRS feed

  • Question

  • Hello!
    I need to get data continuously from USB device. I've got a simple driver(as well as it source code) which allows me to make basic IO operations. The key problem is computer performance. If I run my program on high performance computer there are no problems, otherwise I lose some data packets  during data transfer.

    I want to implement ring buffer within driver. Is it possible to allocate ring buffer, create a thread within driver and then make continuous requests for data transfer(within created thread) so as not to have delays between requests?

    I want to fire events to user mode application each time when half of ring buffer in the driver got completed with data.

    I'm not very experienced with driver programming, could you please point me out the direct related topics or sites or forum links or source examples to learn this topic effectively?

    I guess I must know how to start own thread within the driver, how to allocate kernel space memory in the right way and how to make an event notifier for user space.

    It's not easy to grasp all what I need from the WDF book. Are there any realization examples in source code for related topics? (with comments if possible) 

    ps. sorry for my poor English )

    Tuesday, September 10, 2013 8:50 AM

All replies

  • Have you profiled the slower systems with Xperf or Kernrate to see where the driver has bottlenecks?  Before going to the ring buffer and the techniques you are proposing understand where the delay is, including if it is you application or you driver.   If you designed your driver well, for instance a simple model for "get me a piece of data", you can easily change the interface if that is where the delays are. 

    You may find you can do this with changing the asynchronous I/O handler in user space, to send more requests to the driver and use I/O completion ports (or their newer versions) to manage the I/O.  Also, there are calls that reduce the overhead of Windows I/O for constrained situations see the article for some techniques and there are more.

    You may find there is a path through the driver that is not fast enough then you can work on that path.  First do everything you can to make that path fast in the normal context, then there are ways to step out of the KMDF driver model for that request to speed things up more.

    I have used this incremental technique on a number of drivers to get high performance.  In one case I went from an initial 100,000 IOCTL's a second to speeds approaching 750,000 IOCTL's per second by doing this.   I have also done a lot of rewriting of drivers that assumed they needed "high performance", most of them were a mess and it turned out that rippiing out all the fancy code such as you propose, then testing produced similar or better performance than the original.

    Don Burn Windows Filesystem and Driver Consulting Website: Blog:

    Tuesday, September 10, 2013 11:55 AM
  • Thank you very much for you reply Don Burn, very wise approach! I'll try to make profiling with programs you mentioned.

    Further problems or solutions for my problem I'll post in this topic a bit later.

    • Edited by ikseg Tuesday, September 10, 2013 12:58 PM
    Tuesday, September 10, 2013 12:58 PM
  • Are you using a continuous reader on the wdfusbpipe? You could create a ring buffer (nothing special about that in km), but since the cont reader already allocates buffers for you, just put those buffers into a linked list

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, September 10, 2013 3:49 PM