Le Lundi 03 Mars 2003 17:43, David Brownell a �crit : > Since those are USB 1.1 devices they can't be "high bandwidth". > That term has a specific meaning, for USB 2.0 high speed periodic > transfers (lets them get up to 24 Mbyte/second each).
Ok, didn't know that. > > I'm using 6 hubs, 2 of them plugged directly on the PC, and the fours > > others on the first hubs. Every hub has in turn 4 devices plugged in. > > The trouble is that all the bandwidth is soon taken up, in ISO mode I get > > "usb check bandwidth would have failed" messages, and in bulk mode, > > thousands of "ENXIO" messages. > ENXIO sounds like a UHCI driver saying "you need to be > using USB_QUEUE_BULK in urb->transfer_flags". Which > would be bug in the modem driver: if it's queueing, it > should set that flag, even if it's only queueing when > latencies climb. (Personally, on 2.4 I avoid using > bulk queuing, there've been too many hc-specific bugs.) I'll look into this, but I do know the driver has at least one instance of USB_QUEUE_BULK in the code, so... (if you wanna have a look it's there : http://sl33p3r.free.fr/eagle/eagle-1.0.3.tar.gz in "Pipes.c") > You _should_ be able to hook up all those modems into a > single full speed controller, and the only result in > "bulk mode" should be slower-than-wanted transfers > (assuming the protocol to the modem isn't broken). The > fact that you don't get that means a bug. I think the trouble here is that the device expects some precise protocol timing that just can't be achieved in bulk mode under heavy load. It's poorly documented so I don't know for sure, but that's the most likely reason (the modem keeps looking for DSL sync for way too long, and drops it as soon as it gets it). But given the behavior observed when the number of modems is increased, it looks a lot like network collapse. > With ISO transfers, you shouldn't be able to connect > that many, since there's only about 10 Mbit/sec of > reserved bandwidth (for iso and interrupt transfers). I don't know for sure how much bandwidth the modem needs when no user traffic goes through it, but I'm sure it's not zero. Anyway, I had to use the "don't enforce bandwidth" kernel option since the driver seems to allocate the fastest possible pipe it can. > > Can anyone confirm that I'll have indeed 3x12Mbps, and can > > usb-uhci/usb-ohci/uhci handle this setup ? > That approach is pretty common for USB 1.1 controllers, > which is part of why so many motherboards come with > lots of USB connectors nowadays. Yes it works, though > it seems to me those ENXIO problems mean you have at > least one driver bug that could still interfere. It looked to me that the ENXIO messages were simply an information that the URB really could not be sent right away, and that the driver needed to queue it itself and try again later. In other words, no URB queueing is done in the usb-uhci part. But I can be wrong... > Or instead use USB 2.0 hubs connected to a USB 2.0 root hub, > where ((480 Mbit/sec net)/24 devices) == 20 Mbit/sec per > device means there's plenty of bulk bandwidth (since no > DSL technology I've heard of goes above around 6 Mbit/sec) hmm, I should've known this earlier. I thought that only USB2 devices could take advantage of the increased bandwidth, and USB1 devices ran in a backward compatibility mode. :( Anyway, In the setup you describe do you use "ehci" ? ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
