Right now, scheduling of periodic USB transactions (isochronous & interrupt) is maximally pessimistic: bandwidth is allocated on the assumption that all the transactions will sometimes occur in the same frame. (For low- and full-speed, that is; I don't know about high-speed.)
Is there any interest in improving this? Has anyone seen the scheduler get saturated in actual use with requests that it ought to be able to accomodate? Although solving the full scheduling problem is very difficult (probably NP-complete), there is one simple improvement that could be made to the interrupt scheduling in uhci. (Maybe in ohci also -- I haven't looked at that). The current arrangment has interrupt transactions scheduled in such a way that they do sometimes all occur in the same frame. Using a frame list of length 16 just to illustrate, it looks like this: frame: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 period 1: * * * * * * * * * * * * * * * * period 2: * * * * * * * * period 4: * * * * period 8: * * period 16: * Not much can be done about the period-1 transactions; they have to occur in every frame. But there's no reason for the others to pile up like that. They could be distributed this way: frame: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 period 1: * * * * * * * * * * * * * * * * period 2: * * * * * * * * period 4: * * * * period 8: * * period 16: * This has no more than 2 interrupt periods in a single frame, so the transactions are distributed more evenly. Of course this doesn't affect the total available bandwidth, but done this way there is more bandwidth available in each frame. With a straightforward change to let the allocator understand how this works, it would be possible to schedule more interrupt transactions than currently. Is there any point in me pursuing this? Alan Stern ------------------------------------------------------- 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
