On Friday 12 May 2006 12:22 pm, Christopher Montgomery wrote: > I'm looking at things from the view of the FS/LB bus and the frame on > that bus. In the use cases I'm currently concerned about, the high > speed bus (and any one uFrame) is never going to run out of bandwidth.
I'm more concerned with the big picture, which absolutely includes use cass where bandwidth is an issue. For example, the high bandwidth periodic transfer modes can run at up to 24 KB/frame ... bandwidth does start getting scarce. Especially when folk want to run more than one such high bandwidth transfer at a time, e.g. multiple high speed webcams (and folk are starting to use those with Linux). Regardless, the FS/LS scheduling does need to account for cases where e.g. a given uframe may be fully scheduled with highspeed transfers, and thus can't be used for any FS/LS transfers at all. And vice versa; scheduing an FS/LS transfer in some uframe may make it impossible to put a given highspeed transfer there. Let me repeat that: TT scheduling and highspeed scheduling interfere with each other. You can't perform one in ignorance of the other. > However, if I schedule a split in uFrame Y0 that uses only a fraction > of of that uFrame's worth of the full-speed frame, idle the full speed > bus, then schedule another split that runs in the next uFrame's (and > thus in the Y1 section of the FS frame), there ends up being a hole in > the FS frame that I'll likely not be able to schedule anything into, > and places additional pressure on the scheduler being able to fit > large isos. That's an entirely different issue though, one that's at least partially addressed by Dan's patches (which I'll repost soon). That issue is how fully the TT schedule will be packed ... not the one we were discussing, which is the bandwidth scheduling policy. > > The scheduling reduces how much shifting is going on. Plus, don't > > forget that high speed scheduling concurrently uses many of the same > > resources, and that never gets shifted. > > Correct, but the reason we need to shift in the FS/LS case is a > consequence of how the TTs are designed; ie, the FS frame is segmented > when viewed through the TT, a situation that's not true in uhci or > ohci or any 1.1 HC I know of. They just run their full-frame queues > in order and don't worry about resource contention. They're not > trying to expilictly schedule large multipart transfers into a > segmented frame. Right, which makes them an inadequate model to use with drivers that DO need to worry about such resource contention ... like all high speed host controller drivers. - Dave ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
