On Mon, May 18, 2009 at 08:30:18PM -0400, Alan Stern wrote: > On Mon, 18 May 2009, julien de ROSNY wrote: > > > When I plug a dvb-t usb stick and a memory usb stick and I copy a > > large file from the memory stick to the hard drive, the dvb-t > > reception is bad. > > The same behaviour occurs when I plug a wifi usb stick and the dvb-t > > stick. > > > > The lsusb command gives : > > > > Bus 001 Device 007: ID 148f:2573 Ralink Technology, Corp. RT2501USB Wireless Adapter > > Bus 001 Device 002: ID 0413:6026 Leadtek Research, Inc. WinFast DTV Dongle (warm state) > > ings > > > > Is it normal that the two isb2 devices shares the same bus? > > Yes. > > > Is a bus equivalent to a usb hub.? > > No, it's more like a USB host controller. You can have many hubs all > on the same bus, if they are attached to the same controller. > > > If yes, the problem looks like a same hub share the two usb2 devices. > > So due to the limited bandwidth, dvb-t data are lost during the > > coping of the data from the memeory stick. > > No. Realtime devices like your dvb-t stick are guaranteed a certain > amount of bandwith on the USB bus, and bulk-data devices like your > memory stick get whatever bandwidth is left over. However, this particular DVB-T device does not use isochronous endpoints - it has only bulk endpoints; see the lsusb output from the first message: > lsusb -v -s 1:2 > Bus 001 Device 002: ID 0413:6026 Leadtek Research, Inc. WinFast DTV Dongle (warm state) > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x0413 Leadtek Research, Inc. > idProduct 0x6026 WinFast DTV Dongle (warm state) > bcdDevice 0.01 > iManufacturer 1 > iProduct 2 > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 46 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > (Bus Powered) > MaxPower 500mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 4 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x01 EP 1 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x86 EP 6 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > can't get device qualifier: Operation not permitted > can't get debug descriptor: Operation not permitted > cannot read device status, Operation not permitted (1) > ---------- This is surely a bad design for a device with realtime data transfer requirements. The only workaround currently is to put this device on a separate USB bus.
Attachment:
signature.asc
Description: Digital signature
