A USB device which transfers data using the USB Bulk transfer type (Bulk Endpoint) may lose data due to a buffer overflow on the device. This may occur if the device has data that must be transferred to the host computer in a timely manner (such as streaming video/audio data, or continuously-generated serial or telemetry data), and will experience a buffer overflow and loss of some data if the USB Bulk transfers do not occur within a specific time.
This symptom may occur when the USB device is connected to a computer running Windows Vista or Windows Server 2008, even if no similar buffer overflows and loss of data occur when the USB device is connected to a computer running Windows XP or Windows Server 2003. This symptom may be more readily observed on portable systems with more aggressive power-management settings than on desktop or server systems with little power management.
This problem occurs due to the inherent limitations of using USB Bulk transfers to transfer time-sensitive data. The USB 2.0 specification specifically states that no assumptions can be made about the rate of service of USB Bulk transfers, which occur on a bandwidth-available basis at the discretion of the USB system software (i.e., the USB driver stack running on the host computer). If a particular USB has large amounts of free bandwidth, bulk transfers may happen relatively quickly; for a USB with little bandwidth available, bulk transfers may trickle out over a relatively long period of time.
Therefore, if a USB device uses the Bulk transfer method to transfer data, there is no guarantee possible regarding the timeliness of the data transfer.
Changes in the way USB Bulk transfers are scheduled on Windows Vista and Windows Server 2008 result in occasional pauses between USB Bulk transfers, even on a USB with large amounts of free bandwidth. USB devices which transfer time-sensitive data using Bulk transfers will experience buffer overflows and loss of data if the devices internal buffers are not large enough to hold all the data that might otherwise be transferred during such pauses.
Increasing the size of the USB device's on-device buffer would reduce its vulnerability to the lack of predictability in USB Bulk transfer scheduling. However, to guarantee absolutely against data loss would require a buffer large enough to hold one entire "session" worth of captured data.
Implementing data transfer via Isochronous endpoints instead of Bulk endpoints will provided a guaranteed transfer rate (bandwidth), but no mechanism for ensuring reliable delivery of data.
Implementing data transfer via Interrupt endpoints instead of Bulk or Isochronous endpoints may provide an acceptable combination of periodic bandwidth and reliable delivery of data. Disabling CPU power-management on affected systems may reduce delays in USB Bulk transfers to acceptable levels.
The USB 2.0 specification states:
5.8 Bulk Transfers
The bulk transfer type is designed to support devices that need to communicate relatively large amounts of data at highly variable times where the transfer can use any available bandwidth. Requesting a pipe with a bulk transfer type provides the requester with the following:
· Access to the USB on a bandwidth-available basis
· Retry of transfers, in the case of occasional delivery failure due to errors on the bus
· Guaranteed delivery of data but no guarantee of bandwidth or latency
Bulk transfers occur only on a bandwidth-available basis. For a USB with large amounts of free bandwidth, bulk transfers may happen relatively quickly; for a USB with little bandwidth available, bulk transfers may trickle out over a relatively long period of time.
5.8.4 Bulk Transfer Bus Access Constraints
There is no time guaranteed to be available for bulk transfers as there is for control transfers. Bulk transfers are moved over the bus only on a bandwidth-available basis. If there is bus time that is not being used for other purposes, bulk transfers will be moved over the bus. If there are bulk transfers pending for multiple endpoints, bulk transfers for the different endpoints are selected according to a fair access policy that is Host Controller implementation-dependent.
All bulk transfers pending in a system contend for the same available bus time. Because of this, the USB System Software at its discretion can vary the bus time made available for bulk transfers to a particular endpoint. An endpoint and its client software cannot assume a specific rate of service for bulk transfers. Bus time made available to a software client and its endpoint can be changed as other devices are inserted into and removed from the system or also as bulk transfers are requested for other device endpoints. Client software cannot assume ordering between bulk and control transfers; i.e., in some situations, bulk transfers can be delivered ahead of control transfers.
The USB 2.0 specification is available for download from http://www.usb.org/developers/docs.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND/OR ITS SUPPLIERS DISCLAIM AND EXCLUDE ALL REPRESENTATIONS, WARRANTIES, AND CONDITIONS WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO REPRESENTATIONS, WARRANTIES, OR CONDITIONS OF TITLE, NON INFRINGEMENT, SATISFACTORY CONDITION OR QUALITY, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE MATERIALS.
Artikel-id: 968201 - Laatst bijgewerkt: 20 feb. 2009 - Revisie: 1