On 17 мар, 20:07, Fedek <fedor.inoch...@gmail.com> wrote:
> On 17 ÜÐ*, 13:17, Fedek <fedor.inoch...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > Hey all!
>
> > My question is:
> > -is there ANY way to configure system to handle my USB device or
> > isuued requests with higher priority?
> > -what is continous reader parameters' maximum values?
> > -I have read about IRQxxPriority parameter in the registry and tried
> > it with no sense. Is it working?
>
> > I am developing a USB driver for camera device and get video data with
> > continuous reader. Data rates are really high for USB - at about 40MB/
> > s.
> > Some machines are fast enough to capture this stream without any
> > problems - other don't. The main requirement to the host system and to
> > the driver (as a part of system) is ability of capturing all the data.
> > If host is late with submitting new request to the bus, the entire
> > video frame is lost (overflow).
> > On my target system I have a situation when most of video frames are
> > captured, but 5% are lost (a frame in 5 sec).
> > It seems that there IS a way to get over this limit.
>
> > And about numbers - continuous reader transfer size = 63*1024, num
> > pending reads=255.
> > I have observed different values for both - numpending reads over 16
> > doesn't make sense (2,4,8 - really loss of bandwidth). Buffer size of
> > 64k and more causes the system to BSOD with IRQL_NOT_LESS_OR_EQUAL.
> > CPU load:
> > user mode client - 20% (doesn`t matter up to 70%)
> > DPC - 10%
> > ISR - 1.5%
>
> > My only next idea is to implement my own continuous reader.
>
> now I see with USBlyzer that only 10 requests are issued with
> continuous reader. and I see that this is enough.
> so the main question is where large 64k transactions are split into
> packets?
well, it seems that EHCI driver is responsible for this splitting.
Does anybody know if there is a way to get implementation details of
the driver?
|