title: Will moving code into kernel space give more precise timing?
body: <p>Background information:</p>
  
  <p>I presently have a hardware device that connects to the USB port.  The hardware device is responsible sending out precise periodic messages onto various networks that it, in turn, connects too.  Inside the hardware device I have a couple Microchip dsPICs.  There are two modes of operation.  </p>
  
  <p>One scenario is where send simple "jobs" down to the dsPICs that, in turn, can send out the precise messages with .001ms accuracy.  This architecture is not ideal for more complex messaging where we need to send a periodic packet that changes based on events going on within the PC application.  So we have a second mode of operation where our PC application will send the periodic messages and the dsPICs simply convert and transmit in response.  All this, by the way, is transparent to the end user of our software.  Our hardware device is a test tool used in the automotive field.</p>
  
  <p>Currently, we use a USB to serial chip from FTDI and the FTDI Windows drivers to interface the hardware to our PC software.</p>
  
  <p>The problem is that in mode two where we send messages from the PC, the best we are able to achieve is around 1ms on average hardware range.  We are subjected to Windows kernel pre-emption.  I've tried a number of "tricks" to improve things such as:</p>
  
  <ol>
  <li>Making sure our reader &amp; writer threads live on seperate CPU affinities when possible.</li>
  <li>Increasing the thread priority of the writer while reducing that of the reader.</li>
  <li>Informing the user to turn off screen saver and other applications when using our software.</li>
  <li>Replacing createthread calls with CreateTimerQueueTimer calls.</li>
  </ol>
  
  <p>All our software is written in C/C++.  I'm very familiar and comfortable with advanced Windows programming; such as IO Completions, Overlapped I/O, lockless thread queues (really a design strategy), sockets, threads, semaphores, etc...</p>
  
  <p>However, I know nothing about Windows driver development.  I've read through a few papers on KMDF vs. UDMF vs. WDM.  </p>
  
  <p>I'm hoping a seasoned Windows kernel mode driver developer will respond here... </p>
  
  <p>The next rev. of our hardware has the option to replace the FTDI chip and use either the dsPIC's USB interface or, possibly, port the open source Linux FTDI stuff to Windows and continue to use the FTDI chip within our custom driver.  I think by going to a kernel mode driver on the PC side, I can establish a kernel driver that can send out periodic messages at more precise intervals without preemption and/or possibly taking advantage of DMA.</p>
  
  <p>We have a competitor in our business who I think does exactly something similar with their tools.  As far as I know, user space applications can not schedule a thread any better than 1ms.  We currently use timeGetTime in a thread.  I've experiemented with timer queues (via CreateTimerQueueTimer) with no real improvement.</p>
  
  <p>Is a WDM the correct approach to achieve more precise timing?</p>
  
  <p>Our competitor some how is achieveing very precise timing from Windows driven signals to their hardware and they do load a kernel driver (.sys) and their device runs over USB2.0 as does ours.</p>
  
  <p>If WDM is the way to go, can I get some advise on what kernel functions I should be studying for setting up the timings?
  Thanks for reading</p>