Usb Max Transfer Size
Wu@discussions.microsoft.com Charly Wu
What is the definition of USB Max Transfer Size.
In bulkusb src i noticed there are a few variable which i think related to
that
1. in bulkpnp.c: Interface->Pipe[i].MaximumTransferSize =
USBD_DEFAULT_MAXIMUM_TRANSFER_SIZE. (PAGE_SIZE)
2. in bulkusb.h BULKUSB_MAX_TRANSFER_SIZE 256,
BULKUSB_TEST_BOARD_TRANSFER_BUFFER_SIZE (64*1024)
3. in bulkusb.inf, Registry entry MaximumTransferSize, 4096
How are those three variables related?
How are they used in DispatchReadWrite,
What is the general rule in setting them in order to maximize throughput
How will those value affect ReadFile? can I request as much data as I want
here?
Regards
charly
chris.a...@gmail.com
wrote:
> What is the definition of USB Max Transfer Size.
It's referring to the maximum size of the data area in the URB that
you submit to the host controller. Basically, this value means
different things on different OSes, and is actually ignored much of
the time. See here:
http://msdn2.microsoft.com/en-us/library/ms790486.aspx
> What is the general rule in setting them in order to maximize throughput?
Ultimately, I think you'll need to experiment. I've actually read
several folks say that pending many (like 32) small URBs (say, 8K to
32K in size) is the best way to get the highest performance.
> How will those value affect ReadFile? can I request as much data as I want
> here?
ReadFile is going to come into your driver's upper edge, not the lower
edge facing the HC. If your driver doesn't do any buffering, the size
in ReadFile will probably become your URB size. If it does buffer,
then the two are probably not directly related.
So yes you can request as much data as you want, it is up to your
driver to decide how many bytes actually are fulfilled when the
ReadFile request completes.
Maxim S. Shatskih
>
> It's referring to the maximum size of the data area in the URB that
> you submit to the host controller. Basically, this value means
> different things on different OSes
Starting from some OSes (XP SP?) it is just plain ignored.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
Doron Holan [MSFT]
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message
news:eB4KJfVf...@TK2MSFTNGP03.phx.gbl...
Charly Wu
Is there anything I can do to optimize bulkusb.sys?
for example:
in BulkUsb_DispatchReadWrite:
removing uncessary checking on:
1. BULKUSB_TEST_BOARD_TRANSFER_BUFFER_SIZE
2. breaking of totalLength into stageLength -> since now in XP SP2 there;s
no limit of bulk transfer
our hardware implements circular buffer of 25KB
or u think i need to look at other factor or implementation?
Regards
Charly
Tim Roberts
>
>Is there anything I can do to optimize bulkusb.sys?
What makes you think it needs to be optimized? Nowhere in this thread have
you actually mentioned anything about a specific problem.
>for example:
>in BulkUsb_DispatchReadWrite:
>removing uncessary checking on:
>1. BULKUSB_TEST_BOARD_TRANSFER_BUFFER_SIZE
>2. breaking of totalLength into stageLength -> since now in XP SP2 there;s
>no limit of bulk transfer
That's not what they said. They said MaximumTransferSize was not used.
There is still a limit.
> our hardware implements circular buffer of 25KB
>
>or u think i need to look at other factor or implementation?
Does that mean that you need to read in units of 25KB? Or just that you
need to read 512-byte packets continuously so that the buffer doesn't
overflow?
To get maximum throughput, you must have multiple URBs outstanding at once.
If you ever get to the start of a USB frame and you do not have a request
already queued, you will miss that frame.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Charly Wu
My device only supports USB 2.0 FullSpeed, bulk-in endpoint.
he driver is bulkusb.sys from DDk 2600.1106
I changed the BULKUSB_MAX_TRANSFER_SIZE in bulkusb.h to 8192 bytes
my application does an overlapped readfile requesting 4096 or 8192 bytes per
read.
my throughput calculation is simply the accumulative number of bytes
returned divided by the time from the start of the return of the first read
until the time when the number of bytes threshold is reached. then then
reading stop
bStart = 0;
total = 0;
bSTOP = FALSE;
while(!bSTOP)
{
bRet = readFile (hHandle, buffer, 8192, &readLen)
...
getOverlappedResult(&readLen, TRUE) // blocking
if(readLen)
{
total+=readLen;
memcpy(largeBuffer, buffer, readLen);
if(!bStart)
{
start = current time;
bStart = 1;
}
else
{
if (total >=MAX)
{
end time = current time
thput = total / (end-time)
bSTOP = TRUE;
}
}
}
the throughput i get was around
6~7Mbps
I need more than this.. at least 8Mbps
Regards
CW
chris.a...@gmail.com
wrote:
> the throughput i get was around
> 6~7Mbps
>
> I need more than this.. at least 8Mbps
So when Tim told you to pend multiple URBs at the device, what made
you decide to totally ignore him?
Charly Wu
It's not that I ignore him.. it's just I dont have experience in driver
writing.
and I dont know what it means to pend multiple urbs in term of
implementation in bulkusb driver.
Perhaps u can give me some light or reference
Regards
chris.a...@gmail.com
wrote:
> and I dont know what it means to pend multiple urbs in term of
> implementation in bulkusb driver.
I actually don't know much about bulkusb, but based on the code you
gave, it looks like bulkusb converts IRP_MJ_READ requests into bulk IN
URBs.
If that's the case, then one solution would be to issue multiple
ReadFile() calls simultaneously from your user-mode app, and then
probably use WaitForMultipleObjects() to wait on the array of (all of
the) overlapped completion events for them. When any of them
completes, issue another, then wait on all again.
Another solution is to put a buffer in your bulkusb driver, and then
use a system thread to always issue bulk reads to the device (again,
several at a time). Then the IRP_MJ_READ's from your user app would
just deplete the driver's buffer.
Or just convert to KMDF and use a continuous reader, which is by far
the easiest.
Tim Roberts
>
>My device only supports USB 2.0 FullSpeed, bulk-in endpoint.
>he driver is bulkusb.sys from DDk 2600.1106
>I changed the BULKUSB_MAX_TRANSFER_SIZE in bulkusb.h to 8192 bytes
>
>my application does an overlapped readfile requesting 4096 or 8192 bytes per
>read.
But it's only overlapped by name, right? You aren't actually overlapping
anything.
Here's the problem. USB is a scheduled bus. If you do not have a request
queued up and ready to read when the host controller driver is scheduling
the next frame, you will miss the ENTIRE frame, and will keep on missing
frames until the frame AFTER your request gets back to the host controller
driver.
>the throughput i get was around
>6~7Mbps
>
>I need more than this.. at least 8Mbps
Even with maximum overlapping, there's no guarantee you can get 8 Mbps.
That's close to the maximum achievable at full-speed.