Does anyone know the rationale for the BULKUSB and OSRFX2 drivers breaking
up large bulk transfers in the read and write operations into stages of
MaximumPacketSize? For the OSRFX2 driver, the accompanying comments
include:
//
// the transfer request is for totalLength. We can perform a maximum of
// the BulkOut pipe’s PipeInformation.MaximumPacketSize in each stage.
//
pFx2Context->MaxmimumStageSize =
devExt->BulkInPipe->PipeInformation.MaximumPacketSize;
But I’m finding that I can ignore this limitation and set the stage length
to much larger values (at least up to 128 kBytes when the MaximumPacketSize
is 512 bytes–I haven’t yet tried a USB 1.1 port, however). In fact, I’m
seeing significant performance improvements by bumping up the stageLength by
integer multiples of the MaximumPacketSize.
Is there an earlier version the for usb port driver that didn’t handle
larger transfer sizes?
Thanks,
Larry
Hi,
The comment is misleading. As long as the transfers are a multiple of
MaximumPacketSize and < MaximumTransferSize you’ll be OK. What number you
pick and what sort of performance that gives you is device specific and has
been discussed on this list before. See this thread for good insight on the
issues: http://www.osronline.com/showThread.cfm?link=80186
I’ll make a note to get the sample updated by at least changing the comment.
Regards,
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Larry Bovie” wrote in message
news:xxxxx@ntdev…
> Does anyone know the rationale for the BULKUSB and OSRFX2 drivers breaking
> up large bulk transfers in the read and write operations into stages of
> MaximumPacketSize? For the OSRFX2 driver, the accompanying comments
> include:
> //
> // the transfer request is for totalLength. We can perform a maximum of
> // the BulkOut pipe’s PipeInformation.MaximumPacketSize in each stage.
> //
> pFx2Context->MaxmimumStageSize =
> devExt->BulkInPipe->PipeInformation.MaximumPacketSize;
>
>
> But I’m finding that I can ignore this limitation and set the stage length
> to much larger values (at least up to 128 kBytes when the
> MaximumPacketSize is 512 bytes–I haven’t yet tried a USB 1.1 port,
> however). In fact, I’m seeing significant performance improvements by
> bumping up the stageLength by integer multiples of the MaximumPacketSize.
>
> Is there an earlier version the for usb port driver that didn’t handle
> larger transfer sizes?
>
> Thanks,
> Larry
>
>
I ended up limiting the max stage length to 4K, though supposedly it doesn’t matter. I had also tried 1 MB transfer sizes for USB 1.1 (bulk out), and it worked fine.
If you put on a USB analyzer on the line, you can see at what point you are bombarding the device with too much data (bulk out) because you will see a bunch of NAKs and retries, which reduces your overall throughput. So, it depends on how fast the device can pull the data out of the fifos, etc.
Here’s a link from Microsoft about what they tested.
http://support.microsoft.com/default.aspx?scid=kb;en-us;832430http:
On Windows XP and Windows Server 2003, when the maximum size of a transfer for a bulk endpoint is either less than 4 kilobytes (KB) or equal to 4 KB, the port driver splits the transaction into multiple transfers. Theoretically, this behavior makes the maximum size of a USB transfer unlimited for these endpoints. However, Microsoft has not tested very large transfers, and Microsoft does not recommend very large transfers.
Sharon
----- Original Message -----
From: Scott Noonemailto:xxxxx
Newsgroups: ntdev
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: Monday, November 28, 2005 7:53 AM
Subject: Re:[ntdev] USB Bulk transfer sizes
Hi,
The comment is misleading. As long as the transfers are a multiple of
MaximumPacketSize and < MaximumTransferSize you’ll be OK. What number you
pick and what sort of performance that gives you is device specific and has
been discussed on this list before. See this thread for good insight on the
issues: http://www.osronline.com/showThread.cfm?link=80186http:
I’ll make a note to get the sample updated by at least changing the comment.
Regards,
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.comhttp:</http:>
“Larry Bovie” > wrote in message
news:xxxxx@ntdevnews:xxxxx…
> Does anyone know the rationale for the BULKUSB and OSRFX2 drivers breaking
> up large bulk transfers in the read and write operations into stages of
> MaximumPacketSize? For the OSRFX2 driver, the accompanying comments
> include:
> //
> // the transfer request is for totalLength. We can perform a maximum of
> // the BulkOut pipe’s PipeInformation.MaximumPacketSize in each stage.
> //
> pFx2Context->MaxmimumStageSize =
> devExt->BulkInPipe->PipeInformation.MaximumPacketSize;
>
>
> But I’m finding that I can ignore this limitation and set the stage length
> to much larger values (at least up to 128 kBytes when the
> MaximumPacketSize is 512 bytes–I haven’t yet tried a USB 1.1 port,
> however). In fact, I’m seeing significant performance improvements by
> bumping up the stageLength by integer multiples of the MaximumPacketSize.
>
> Is there an earlier version the for usb port driver that didn’t handle
> larger transfer sizes?
>
> Thanks,
> Larry
>
>
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:
You are currently subscribed to ntdev as: xxxxx@msn.commailto:xxxxx
To unsubscribe send a blank email to xxxxx@lists.osr.commailto:xxxxx</mailto:xxxxx></mailto:xxxxx></http:></news:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:>