KMDF-USB-Continuous reader and real-time application

[Fedek]

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.

[Fedek]

Post by Fedek
Hey all!
-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.
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?

[Fedek]

Post by Fedek

Post by Fedek
Hey all!
-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.
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?