On Sun, 21 Nov 2010, vichy wrote: > Dear all: > I know an usb packet transaction is 125 micro second and I see the No. A USB microframe is 125 us. Packet transmissions are much shorter. > USB_CTRL_GET_TIMEOUT is 5000 ms. > If I try to send vendor specific command to control pipe for get > status of my dongle, which is 4 byes data long, can I shorten the > timeout value as 75 ms? Certainly. You can set the timeout value to whatever you want. But if you set it too short, the transfer will time out instead of completing normally. > I try to set this value but I get timeout error in usb_start_wait_urb. > But 75ms seems longer enough for 125 micro second per transaction. Transaction != transmission. However, it is true that every high-speed transaction must end within 125 us. Every full-speed or low-speed transaction must end within 1000 us. A control transfer contains at least 2 transaction stages (Setup and Status), and the time interval between them can be much longer than 1000 us. > why I still get the time out error? > ( I have monitored the bus and the found duration from setup token to > ACK of in toke from device is 22ms. You haven't said, but I'll assume your control transfer doesn't have a Data stage. The IN token is sent by the host (not the device) during the Status stage; in response the device sends a 0-length DATA1 packet, and then the host (not the device) sends the final ACK. In other words, neither the ACK nor the IN token comes from the device. > I know there might be some sw effort but 75-22= 53ms seems too long > for bringing back the data from QTD.) Assuming the ACK packet you saw really did mark the end of the transfer then you are right; the URB should complete a few ms later. Did you monitor the bus while running a test with a 10-second timeout? Maybe comparing the results of the two tests will explain why the timeout occurs. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html