Re: Polling Thread, Where to locate?
From: Randy Aull \(MSFT\) (randyau_at_microsoft.com)
Date: 09/13/04
- Next message: Randy Aull \(MSFT\): "Re: IRP_MJ_CREATE on HidClass under XP SP2"
- Previous message: Arik Yavilevich: "Re: SendInput with DirectInput"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 13 Sep 2004 13:45:48 -0700
As others have stated, an Interrupt endpoint may be more suitable if latency
is a concern. Do keep in mind that maximum data throughput is lower on
interrupt than bulk, but bulk has no guarantees.
You should change your device to NAK instead of respond with 0 bytes. This
is standard USB endpoint behavior. If you change this behavior then you can
actually pend more than one URB if you would like in order help maximize
throughput, as there would always be a read pending and your device will be
polled as frequently as possible. The URBs will complete when they either
receive all of the requested data, or there is a short (or zero-length)
packet.
If your device is receiving data up to 100 MBytes/Sec, you may have some
troubles. Over USB 2.0 hi-speed bulk endpoints, the max data rate that I
have ever been able to achieve is almost 40MBytes/Sec. That pretty much
saturates all USB bandwidth. So your device is going to need a buffer large
enough to hold your maximum burst time unless you want to drop data.
-- This posting is provided "AS IS" with no warranties, and confers no rights. "Dennis Burns" <dburns@rtessentials.com> wrote in message news:uSoNrKJjEHA.2908@TK2MSFTNGP10.phx.gbl... > Hi Randy, > Thanks for the response. > I have full control over the device's response protocol. I have written > the > firmware so that if there is no data to send, it will respond with 0 > bytes, > but I can change that so that it would NAK instead. > The device has only 1024 bytes of buffer space, so if data is coming fast > (up to 100 MByte/Sec ), then I need to pull the data pretty quickly. > Please elaborate a bit on your idea. I think you might have a much better > way to handle this. > By the way, this is a CAN to USB interface device. The CAN network data > can > be up to 1Mbit/sec, but the rate is pretty bursty. > Thanks, > Dennis > > "Randy Aull (MSFT)" <randyau@microsoft.com> wrote in message > news:412f7aa9$1@news.microsoft.com... >> Is there a reason you don't want to simply pend a read that will complete >> when the device responds? Does your device actually send data over bulk > to >> NAK at your protocol level? >> >> While pending a read may take up more bus bandwidth, it will use much >> less >> CPU. You can even pend multiple reads in order to achieve your high data >> rate. >> >> Randy >> >> -- >> This posting is provided "AS IS" with no warranties, and confers no > rights. >> "Dennis Burns" <dburns@rtessentials.com> wrote in message >> news:ekrbS4FjEHA.2556@TK2MSFTNGP10.phx.gbl... >> > I'd like to implement a polling thread to periodically read data (via a >> > Bulk >> > Transfer) from my USB device, and save that data into a buffer until my >> > application gets time to use it. I can implement this thread in either > my >> > kernel mode driver, or in my user mode api. Under high loading > conditions, >> > I >> > may need to run this loop at a pretty high rate (up to every 10 ms, if >> > that's achievable). >> > Is there a clear advantage to where it's located: kernel vs user? For >> > example, will the kernel-mode choice be guaranteed higher priority? Or, >> > are >> > there are other reasons to choose one over the other? >> > Thanks in advance for the help, >> > Dennis >> > >> > >> >> > >
- Next message: Randy Aull \(MSFT\): "Re: IRP_MJ_CREATE on HidClass under XP SP2"
- Previous message: Arik Yavilevich: "Re: SendInput with DirectInput"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
