Ok I've done abit of research/testing
If I only unlink the URB used for sending data.. Then sending stops. And recieve also.. sicne the device first wants to send data before
it can recieve data.
But when I also unlink the URB used for recieving data.. Then all of a sudden everything comes back one.
And then My logs end up looking like this:
Dec 3 09:39:44 debian kernel: <SABUS>unlink recieve_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink send_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink recieve_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink send_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink recieve_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink send_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink recieve_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink send_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink recieve_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink send_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink recieve_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink send_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink recieve_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink send_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink recieve_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink send_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink recieve_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink send_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink recieve_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink send_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink recieve_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink send_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink recieve_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink send_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink recieve_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink send_data
Dec 3 09:39:44 debian kernel: <SABUS>unlink recieve_data
I decided to give you only 1 screen of this :-)
So for now I'm only going to unlink the send URB.
David Brownell wrote:
Heinrich du Toit wrote:
Anyways from what I can find out the max bandwidth of my USB is 12Mbit/s
And each device communicates at 1.6Mbit/s
This means after I plugged in the 7th device (theoritcally) the bandwidth are full.
And from then on things start to slow down or seomthing like that.
Hmm, no ... have a look at the usb 2.0 spec again and see what it says about reserved bandwidth. Typically low speed devices (1.5 Mbit/sec) use interrupt transfers to transfer data. At low speed those max out at 8 bytes, and you can get at most about seven per frame ... but the transfers for a given device are usually not scheduled every frame. If they're scheduled every 8 frames, that'd be about 7*8 = 56 devices. What's _supposed_ to happen is that if you can't reserve its bandwidth, submitting that interrupt URB will fail. Actually that's a config option that's usually disabled, and when it's enabled none of the UHCI drivers will get you to 56 devices. The "slow down" option is only available for bulk or control transfers. Interrupt (and isochronous) transfers are supposed to either have their full transfer speeds, or not be queued.Now these devices communicate using interrupt transfer.
Meaning it does a never ending send/recieve loop.
But there aren't always data to be send.
So what I like todo is to stop the transfer when there is nothing to send to the device.. giving the bandwidth to the other devices.
On 2.4 kernels, "interrupt out" is problematic. Unlink the urb after the transfer is done (maybe more than one frame). It's a lot cleaner on 2.5 kernels.Ok so I've treid this:
I've put a usb_unlink_urb command in my send_complete function.
send_complete is called each time the sending was done and copy new data from the ring_send_buffer into the urb's buffer.
But this doesn't work.
The urb gets resceduled after the send_complete function exists.
Making my usb_unlink_urb useless.
Sounds like a bug in whatever host controller driver you're using. Unlinking an interrupt urb in its completion function is supposed to work just fine. Does it still happen on 2.4.20? If this is with UHCI hardware, did you try the other driver? - Dave
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
